Jeff Boyce wrote:
Greetings -
I am hoping someone may be able to educate me on how to diagnose what
happened to my system. I have a Dell PE2600, running RHES 3 completely
up2date, PERC 4/di, Raid5 with 3x36G drives, functioning primarily as a
Samba file server to 8 window desktops. I was notified yesterday
morning that it appeared that a directory under our primary Samba share
was missing. This directory contained our active projects files, approx.
11G and 16,500 files. It was there one moment, then gone about a half
hour later; I am presuming an accidental deletion at this point. I
looked through some of the log files (samba logs, and others I don't
recall) and found no indication of what might have happened. So I
restored the directory and all its files from tape to a new directory
with success. The logwatch summary of disk space for before the
deletion event and after the restoration of the directory are shown
below. The deleted directory was under the /ecosystem share mount. The
current disk usage puzzles me because it appears that the increase in
disk space used on /sda10 is equal to the size of the directory restored
from tape.
Questions:
1. Is it possible that the directory was not deleted, but instead
hidden in some way?
Possible. Look to see if the directory has been renamed beginning with a ".", or
simply moved elsewhere. Also, it's possible the directory inode has become
corrupted. I'm not sure of the effects of a corrupt directory inode, the files
might still be there but effectively orphaned. Run fsck to see what it throws up.
2. Where would I look to find evidence of what might have happened to
the directory initially?
I don't think there will be any, unless you have software which provides an
audit trail.
3. Why is my disk usage significantly increased following restoration
of the directory?
Are you comparing the disk usage to before the directory disappeared, or after
it disappeared?
4. How should I assign permissions to a primary directory to prevent
accidental deletion, yet still allow subdirectories under this directory
to be created, deleted, and otherwise be used by all employees?
The directory itself can have full write permission but with the sticky bit set.
This allows anyone to create files/directories within the directory, but they
can only write/delete their own files (cf. /tmp). The parent of the directory in
question should not have write permission to prevent users from modifying any
aspect of the directory.
Make sure that each Windows user has a unique user id to access the share.
Thanks for any and all suggestions. I can provide additional
information if needed to understand this issue.
Jeff Boyce
Meridian Environmental
www.meridianenv.com
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@xxxxxxxxxxxx
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
