-   Linux - Newbie (
-   -   file permissions and other info ok when root, but not ok with other user (

benobi 10-16-2005 08:42 PM

file permissions and other info ok when root, but not ok with other user
I have a bunch of video files stored on my secondary hd. The partition type is ext3. Anyway, when I log in as super user with 'su' at the console and type 'ls -l' all the permissions are ok. I see the correct permissions, user, group, file size, etc. But then when I log out of super user by typing 'exit' and do a 'ls -l' with my normal user, for each file listed I get a question mark '?' for directory, the permissions are all hyphens, the user, group, and file size is a '?' as well. The file name is red background, white foreground.

Same thing is wrong when I look at the files using nautilus. When I start nautilus with super user access. The files, permissions and stuff are all ok. However when I use nautilus in normal user mode, it's all screwed up. The file type is unknown, the file size is '...'. And in the permissions tab it say's "The permissions of "file name" could not be determined.

I have a few other hd's and they're all ext3 I believe and they all seem to be fine, they work as root or as a normal user. It's just this one hd.

kilgoretrout 10-16-2005 09:57 PM

Mount the affected partition , su to root and run:

# chmod 1777 -R <mount point>

where "mount point" corresponds to the mount point of the troubled ext3 partition. That will give all users read/write access to all files on the partition. The "R" recursively makes the change in ownership. See if that corrects the problem.

benobi 10-17-2005 03:22 AM

Wow thanks, that did the trick. What happened there? How come the permissions and stuff looked ok as root but not as the owner?

Also, what's the 1 in front of the 777 mean? I know 7 sets rwx permissions, not sure what the 1 does.

kilgoretrout 10-17-2005 01:28 PM

The "1" sets the "sticky bit". When the sticky bit on a directory is set, the files in that directory can only be renamed or removed by the owner of the directory, the owner of the file or root, regardless of the fact that the file permissions on the file would otherwise allow other users to rename or delete the file. It's typically used with mount points to linux filesystems, especailly in a multiuser environments It allows all users to store files on the partition and all others to access those files but only the owner and root to delete or rename the files created.
I'm not sure why it was originally screwed up, but I suspected the files may have been created on another system which set some weird permissions/file ownerships or your system had improperly set mount point permissions. I thought resetting it to a sensible default would probably fix it which apparrently it did.
With linux filesystems, you change permissions on a partition by changing the permissions on the mount point with the partition mounted. If the partition is not mounted when the chmod command is made, it won't work. This doesn't work for windows filesystems by the way(FAT and FAT32). Those don't have a native permission structure, unlike linux filesystems. One is grafted on to FAT and FAT32 partitions in linux by the options passed through the fstab entry.

All times are GMT -5. The time now is 03:39 PM.