Member of group root, but root group permissions don't apply?
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Member of group root, but root group permissions don't apply?
A bit of an oddity that I've recently run into with my storage folder in my system; it's a newly installed drive that I've set to mount at /storage. When I first tried to use it, programs that I used that attempted to write to it tossed Access Denied errors at me in their own way.
Checking the permissions (at the Terminal, ls -l / | grep storage) showed that /storage was set to 'rwxrwxr--'--Owner and Group were given full read/write/execute, but Others could only read. However, my logon to my system is a member of group root. Why, then, with the above bits set, would I not be able to write to it? Changing Others permissions to rwx (and presumably rw would have worked out for me since I don't leave anything executable there) allowed me to write to it, but I don't understand why that would have been necessary. So far as I'm aware, the prior drive that was in my system--mounted at the same location--did not need this treatment.
The drive is mounted by /etc/fstab; when I changed the physical drive out, I simply changed the UUID to it's current value, everything else is the same as it had been:
Code:
# /storage was on /dev/sdb1 during installation
UUID=f3f00e48-17bc-45ac-8568-14c5cd4df273 /storage ext3 relatime 0 2
On a side note, I'd ended up having to change the permissions of my /tmp folder to be able to log in to my system, about a day later (symptoms matched this bug at Ubuntu's Launchpad (#269215), and changing the permissions is one pretty consistently mentioned fix). The permission change used and prior permissions were the same as the above hard drive (drwxrwxr-- prior, changed to drwxrwxrwx to allow /tmp to be written to)--also owned by user root with group root.
A bit of an oddity that I've recently run into with my storage folder in my system; it's a newly installed drive that I've set to mount at /storage. When I first tried to use it, programs that I used that attempted to write to it tossed Access Denied errors at me in their own way.
Checking the permissions (at the Terminal, ls -l / | grep storage) showed that /storage was set to 'rwxrwxr--'--Owner and Group were given full read/write/execute, but Others could only read. However, my logon to my system is a member of group root. Why, then, with the above bits set, would I not be able to write to it? Changing Others permissions to rwx (and presumably rw would have worked out for me since I don't leave anything executable there) allowed me to write to it, but I don't understand why that would have been necessary. So far as I'm aware, the prior drive that was in my system--mounted at the same location--did not need this treatment.
can you please post the outputs of the following commands:
ACL's: Access Control Lists, they allow for finer grained control over file permissions, think of them as UNIX permissions on steroids. Interestingly, MS use ACL's in their NTFS file system, and they form the basis of the 'New Technology' aspect of NTFS vs FAT32.
PS, the previous post illustrates how to check for this with the getfacl command.
This may be a recurrence of the bug you describe here:
Quote:
(symptoms matched this bug at Ubuntu's Launchpad (#269215), and changing the permissions is one pretty consistently mentioned fix)
might be worth opening a launchpad query about it.
Last edited by irishbitte; 04-21-2010 at 08:55 AM.
@irishbitte: I'm beginning to think that's the most likely case, although I wouldn't really call it a recurrence since it doesn't seem to have been really 'fixed', so to speak--just worked around sufficiently. I'll probably weigh in over there in a bit, see what other thoughts might be out there. Just seems rather odd that out of nowhere a permissions change would be needed, doesn't seem quite right to me...but I'm not much of an expert, to tell the truth
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.