Root can't chgrp or set permissions on directory?

gregorian · 05-26-2008, 12:42 PM

I wanted to have write permissions for the the drives that listed as C: D: E: F: under windows. I mounted these on C D E F directories respectively under /mnt.

I created a group called "mygroup", added my account to it; and I tried to change the group it belonged to "mygroup" and set read, write and execute permissions for that group. It worked for folder C, but not for D E and F. Also what's up with the date of creation of D E and F?! I was not even born then... and there are some differences in the other dates too.. some 2006, some 2002. I installed Slackware a few days back..

Code:

root@foo:/mnt# chgrp mygroup C D E F
chgrp: changing group of `D': Operation not permitted
chgrp: changing group of `E': Operation not permitted
chgrp: changing group of `F': Operation not permitted
root@foo:/mnt# chmod 775 C D E F
root@foo:/mnt# ls -l
total 84
drwxrwxr-x 1 root mygroup  4096 2008-05-26 15:18 C
drwxr-xr-x 9 root root    16384 1970-01-01 05:30 D
drwxr-xr-x 9 root root    16384 1970-01-01 05:30 E
drwxr-xr-x 4 root root     8192 1970-01-01 05:30 F
-rw-r--r-- 1 root root      376 2006-09-26 08:39 README
drwxr-xr-x 2 root root     4096 2006-09-26 06:32 cdrecorder
drwxr-xr-x 2 root root     4096 2002-03-16 13:04 cdrom
drwxr-xr-x 2 root root     4096 2006-09-26 06:32 dvd
drwxr-xr-x 2 root root     4096 2008-05-24 14:22 flash
drwxr-xr-x 2 root root     4096 2002-03-16 13:04 floppy
drwxr-xr-x 2 root root     4096 2002-03-16 13:04 hd
drwxr-xr-x 2 root root     4096 2006-09-26 06:32 memory
drwxr-xr-x 2 root root     4096 2006-09-26 06:33 tmp
drwxr-xr-x 2 root root     4096 2006-09-26 06:32 zip
root@foo:/mnt#

seraphim172 · 05-26-2008, 05:12 PM

Drive C is certainly a hard disk, so changing permissions and ownership makes sense and is possible.

Drive D is most likely a CD/DVD drive - an empty CD/DVD drive doesn't have ownership, and with each inserted media contents and ownership will be different.

I assume that E and F are also some external removable devices. You can not change ownership of device, only of it's current contents, if any.

Linux Archive

gilead · 05-26-2008, 06:06 PM

Since you access them under windows I'm assuming there are fat32 or ntfs file systems on those partitions. Non-linux file systems don't support the same permissions as linux file systems. Have a look at man mount and search for vfat and ntfs. You can use options like umask, uid and gid to specifiy permissions and ownership.

eggixyz · 05-26-2008, 08:40 PM

Hey There,

This might work. Umount D E and F and chmod the directories 777, then remount them and see if the chgrp will work then. I've seen that happen before.

Best wishes,

Mike

gregorian · 05-26-2008, 10:50 PM

seraphim172 - They're ntfs and vfat drives.
eggixyz - I'm still getting the same errors.

gilead, Your method works. I set gid to be that of my group and the umask to be 002. Could you tell me why my date of creation is in 1970? If I'm not mistaken isn't that the beginning of the epoch which Slackware uses?

Thank you all for your help!

eggixyz · 05-26-2008, 10:58 PM

Cool,

Glad you got it to work

The epoch is January 1st 1970

Best wishes,

Mike

gregorian · 05-26-2008, 11:00 PM

Why do D E and F have epoch times?! Their contents show correct times of creation!

eggixyz · 05-26-2008, 11:15 PM

Sorry, just have to ask,

Are D E and F mounted with the filesystem type specified in the mount command? I've seen this before if you choose default and/or don't specify vfat or ntfs. I've also seen this happen on mounted filesystems when a Linux distro doesn't fully support ntfs.

Best wishes,

Mike

gregorian · 05-27-2008, 12:32 AM

When I first installed Slackware, I specified the mount types for D, E and F as auto. But I didn't like the boot messages as it mentioned something along the lines of filesystem not mentioned, trying vfat.. Later on I replaced auto with vfat. Is this a bug?

eggixyz · 05-27-2008, 12:57 AM

Hey,

I wondering that myself. Check this link from another thread. It basically says that since vfat doesn't have a c_time stamp, so the date on the filesystem get's set to 1/1/1970, which, depending on what time zone you're in can sometimes also be 12/31/69, which (in most cases) means that Linux can't figure out the time (that makes sense though if vfat doesn't carry a c_time (inode creation time) for the OS to read.

http://unixresources.org/linux/lf/47...67/126787.html

Hope that helps

, Mike

gregorian · 05-27-2008, 03:17 AM

It's related to the time zone alright. I live in India which is 5 and a half hours ahead of GMT and that's the file creation time. I know that c_time is a structure in C but that's it. Sorry if I sound noobish.. but can't Linux read timestamps other than c_time? The contents inside the fat partitions have correct timestamps.. why does the problem exist only with the mounted directory? With reference to your previous post, does putting auto instead of 'vfat' make a difference?

Omer Fadul · 05-27-2008, 05:17 AM

i think the problem is more simpler than that, it is related to the account u use to access the system.
in other words, you logged to the system like a normal user and then you do su without - option on that way you will use the current user profile rather than full root user profile.

gregorian · 05-27-2008, 08:10 AM

I'm positive you get complete root privileges when you use su. I logged in as root too. I faced the same problem, but now that's fixed. Now I'm just interested in the date of creation issue I'm facing.

chrism01 · 05-27-2008, 07:18 PM

Actually,

su

gets you in as root, BUT you retain the original user's env.

su -

gets you in as root WITH root's env settings.

HTH

Incidentally,

"Three fields in the inode structure contain the last access, change, and modification times: atime, ctime, and mtime. The atime field is updated each time the pointer to the file's data blocks is followed and the file's data is read. The mtime field is updated each time the file's data changes. The ctime field is updated each time the file's inode changes. The ctime is not creation time; there is no way under standard Unix to find a file's creation time."

Perl Cookbook, Chap 9, Directories.

eggixyz · 05-27-2008, 09:35 PM

Yes,

My mistake - ctime does refer to the inode "change" time and not inode "creation" time. The point I was trying to make originally was that vfat doesn't have that, which is what can cause the incorrect timestamp on mounted vfat resources.

Apologies for any confusion I created. The other discussion I linked to addresses why the vfat problem exists.

Also, I think there's a bit of confusion between privilege and environment. Su'ing to root, with or without sourcing the profile, does give the user root privilege, but they keep the original user's environment settings, for the most part.

Is the issue still just that the timestamps are not correct? As far as I know and have been able to research, it may be impossible to mount a vfat partition and fake the date easily, but, as long as the mount works I would say "problem solved"

I could be missing something. I've obviously missed a few back-and-forths here.

In any event, best wishes,

Mike