Neglected my server for a while; looks like someone was able to hack in via the ftp? Was running vsftp, would have a lot of upload traffic but couldn't figure out what was being done. Chalked it up to some kind of back door and decided to rebuild/start over.

Fresh load of Fedora Core 5, now Core 6.

Left the mirror of data alone (mp3s and website stuff).

Now when I look at my 20G mirror that I use for storing mp3s:

df shows: /dev/md0 19243708 18177412 88744 100% /home2

but if I pull up the drive locally or via samba share it says 15G.

Basically there is about 3 Gig un accounted for. If someone hid files on the server; how could I tell?

?,
John

You could try looking at the partition table, or running testdisk to see if there is a hidden partition. Another possibility is that you are running df as root, and then checking via samba as non-root. In *BSD (although I get the impression it is not generally true in Linux), 5% is reserved for the super user, so df as a normal user shows less free space than df as root.

You could try looking at the partition table, or running testdisk to see if there is a hidden partition.

Checked, no partitions other than what I created. Don't have a testdisk command. ?

Another possibility is that you are running df as root, and then checking via samba as non-root. In *BSD (although I get the impression it is not generally true in Linux), 5% is reserved for the super user, so df as a normal user shows less free space than df as root.

Nope, checked... reports the same whether I am SU or not.

If you think that your system might be compromised and there could be hidden files, you should examine the drive after booting up using a live CD so that you know a rootkit isn't manipulating the filesystem to hide files or processes from being detected.

Some files with holes in them will report different sizes depending on which utility you examine the file with. Also, if you have links, and they are being dereferenced, the du value will show up higher. Very short files will occupy an entire block, which will be accounted for in space missing using df but not in the du total. Also, the journal will take up space and not be counted in a du summary. The ext3 file system will reserve a portion of space for root only.

A rootkit wouldn't be active on a new installation.

I either don't understand how the file system is created or showing on my mirror array - or there are hidden files somehow on the drive.

Reference my earlier post on size showing. Then think of...

In windows accessing the drives using samba - I select all and it says that the total size of files is 15G.

Also, consider the fact that it is a mirror array - by itself; using ext3; and only houses data.. literally mp3s.

Is it possible that the os uses that much headroom? or that a non-active rootkit could manipulate the os?

You might try running chkconfig on the partition. For ext3 there is a certain amount of space reserved for root.
Run "sudo /sbin/tune2fs -l /dev/<device>" to examine the contents of the superblock. This will include information such as how many blocks are reserved and which user and group is allowed to reserve blocks. You can also change the percentage of reserved blocks using the tune2fs program.

/dev/md0 - the raid:

tune2fs 1.39 (29-May-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 94bc51ff-fcd9-4f4f-b37e-362378245944
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr filetype sparse_super
Default mount options: (none)
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 2448000
Block count: 4887760
Reserved block count: 244388
Free blocks: 266574
Free inodes: 2444263
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16320
Inode blocks per group: 510
Filesystem created: Sat Oct 23 21:18:59 2004
Last mount time: Fri Nov 26 23:47:30 2004
Last write time: Wed Nov 8 19:12:21 2006
Mount count: 70
Maximum mount count: 26
Last checked: Sat Oct 23 21:18:59 2004
Check interval: 15552000 (6 months)
Next check after: Thu Apr 21 21:18:59 2005
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Default directory hash: tea
Directory Hash Seed: b573c1a0-1d21-44cf-9562-0ba70e797010

-----

/dev/hdh1 - the drive itself:

tune2fs 1.39 (29-May-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 94bc51ff-fcd9-4f4f-b37e-362378245944
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr filetype sparse_super
Default mount options: (none)
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 2448000
Block count: 4887760
Reserved block count: 244388
Free blocks: 266574
Free inodes: 2444263
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16320
Inode blocks per group: 510
Filesystem created: Sat Oct 23 21:18:59 2004
Last mount time: Fri Nov 26 23:47:30 2004
Last write time: Wed Nov 8 19:12:21 2006
Mount count: 70
Maximum mount count: 26
Last checked: Sat Oct 23 21:18:59 2004
Check interval: 15552000 (6 months)
Next check after: Thu Apr 21 21:18:59 2005
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Default directory hash: tea
Directory Hash Seed: b573c1a0-1d21-44cf-9562-0ba70e797010

-----

doesn't make since to me... what about you?

I also noticed this (when looking at the array):

RAID device options
Device file /dev/md0
RAID level Mirrored (RAID1)
Filesystem status Mounted on /home2
Usable size 19551040 blocks (19 GB)
Persistent superblock? Yes
Chunk size Default
RAID status clean
Partitions in RAID IDE device G partition 1
/dev/rtc (Down)

-----

/dev/rtc??? - it should be /dev/hdh1 - the drive that I posted... it won't let me add it.. I can only assume that the drive has crapped out... That is why I run the RAID array... although it does me no good if one of the drives is dead and I don't know it.

Will be looking into that as well here soon... - Could the dead drive in the array cause the missing available space??? I wouldn't think so.......

Interesting new finding -

Checked LogWatch under root -

got this on Nov 8 (logged Nov 7):

--------------------- Disk Space Begin ------------------------

Filesystem Size Used Avail Use% Mounted on
/dev/md1 6.0G 5.6G 74M 99% /home
/dev/md0 19G 16G 1.8G 90% /home2
/dev/mapper/VolGroup00-LogVol00 17G 3.9G 13G 24% /
/dev/hda1 99M 19M 75M 21% /boot
/dev/md2 8.4G 148M 7.8G 2% /download


---------------------- Disk Space End -------------------------

Note Md0 - the home2 mount - that's the one I've been talking about.

Now on Nov 9 (log Nov 8):

--------------------- Disk Space Begin ------------------------

Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
17G 3.5G 13G 22% /
/dev/hda1 99M 11M 83M 12% /boot
/dev/md0 19G 18G 87M 100% /home2
/dev/md1 6.0G 1.1G 4.6G 19% /home
/dev/md2 8.4G 148M 7.8G 2% /download


---------------------- Disk Space End -------------------------

The next day it's at 100% - in one day??? I havn't even used it.

Ideas?

You have a reserved block count of 244388 with a block size of 4096 bytes. Thats 10GB.

As an aside, testdisk is a utility that should be downloadable as a package for your distro - I've not used Fedora in a while, but 'yum install testdisk' should do the trick.