why can't I chown a hard drive?
 

Linux (I'm using MEPIS 7) wouldn't let me rename a folder on one of my HDs. I looked at the permissions and saw that the owner was root. (I think an error changed it, because I copied something to this drive recently, and didn't have a permissions problem.) So I logged into the root account and, both in the GUI and then in a console, tried to chown not just the folder but the entire drive to my account. (I'm the only user.) When I tried this in the GUI, the drive just ignored my changes (I know that because after clicking OK, I checked the permissions again, and root was the owner again.) So I opened a console and went through this:

root@mepis1:~# chown users '/mnt/sdb1'
chown: `users': invalid user
root@mepis1:~# chown josh '/mnt/sdb1'
chown: changing ownership of `/mnt/sdb1': Operation not permitted
root@mepis1:~#

Not permitted? Why not?

In case it was because one can't chown an entire drive at once, I then tried to chown the three folders one at a time (although that's not good enough, because I don't want any future folders I make to be owned by root). That produced the same result. So why can't I change the permissions or ownership from the root account?

Could you please provide 'ls -al' output for the directory you're trying to chown.

Now I have more information. I went back to my account, and unmounted and then mounted it. Now the owner is me. Why would that happen?

(Something possibly related to this is that after I bring it out of hibernation (I use Suspend to Disk often), the drives are unreadable and unwriteable. I can solve the problem by unmounting and mounting them.

You posted that while I was adding another post. But I performed that command. It says:

root@mepis1:~# ls -al '/mnt/sdb1'
total 68
drwxr-xr-x 5 josh users 16384 1969-12-31 17:00 .
drwxr-xr-x 8 root root 4096 2008-08-15 20:04 ..
drwxr-xr-x 16 josh users 16384 2008-08-15 20:34 data
drwxr-xr-x 2 josh users 16384 2000-02-10 17:49 My Documents
drwxr-xr-x 6 josh users 16384 2008-08-14 20:40 Program Files
root@mepis1:~#

However, that is after I unmounted and then mounted the drive, because I didn't wait for a response to my first post before posting more information (sorry!) I can't ls -al the folder when it claims the owner is root. (I should get a chance to, because this will probably happen again. This type of screwup has been happening a lot for me in MEPIS 7. I'm annoyed enough by it to change distros.)

My guess would be that the disk in question is formatted as Windows FAT32 or NTFS.

If that's the case (and seeing "My Documents" and "Program Files" there leads me to believe it is) then all you need to do is to change system' default behaviour.

FAT32 partitions are mounted by default under ownership root:root with 770 permission. Change /etc/fstab entry for the disk in question by adding (or changing) 'umask=0' then remount.

If anything still doesn't work just post here and I'm sure we'll work it out.

Thank you, Klearview. It's formatted to FAT32, yes, because I was sharing it between Windows and Linux until my Windows installation permanently stopped working recently. So I'll try that.

Is this the proper format? Sda4 is the drive.

_________________________________
# Pluggable devices are handled by uDev, they are not in fstab
/dev/sda1 /mnt/sda1 vfat,ext3,ext2,reiserfs auto,users,exec,rw 0 0
/dev/sda2 / ext3 defaults,noatime 1 1
/dev/sda4 /mnt/sda4 auto auto,users,exec,rw,umask=0 0 0
/dev/sda5 /mnt/sda5 auto auto,users,exec,rw 0 0
/dev/sda6 swap swap sw,pri=1 0 0
/dev/sdb1 /mnt/sdb1 vfat,ext3,ext2,reiserfs auto,users,exec 0 0
none /proc proc defaults 0 0
none /proc/bus/usb usbfs devmode=0666 0 0
none /dev/pts devpts mode=0622 0 0
none /sys sysfs defaults 0 0
# Dynamic entries below
/dev/sdc1 /mnt/sdc1 vfat,ext3,ext2,reiserfs noauto,users,exec 0 0
/dev/cdrom /media/cdrom udf,iso9660 noauto,users,exec,ro 0 0
/dev/scd0 /media/cdrom udf,iso9660 noauto,users,exec,ro 0 0

seems right - don't forget to remount.

What do "noatime," "umask" and "pri" mean?

For that, use

Your original problem was that fat32 simply doesn't accept the linux permissions/ownership scheme, in other words: it's *invulnerable* to chmod/chown. That's where umask gets into scene: it sets the default permissions for a fat32 fs via the correspondent driver, and not in the linux userland (where fat32 simply doesn't understand them).