Operation (by root) not permitted
ChasM Marshall
chasm750 at hotmail.com
Tue Aug 31 16:13:13 MST 2010
Thank you Joeseph,
I have some comments here, and will post another (different) solution too.
> Because vfat has no permissions of it's own,
> but the POSIX filesystem layer needs to see permissions,
> the vfat filesystem driver "makes it up".
> Fortunately, you can control the permissions it sets,
> from the machine that's mounting the drive.
Uhh, yeah, finding those controls was not easy.
> In your fstab, change the line that reads (I assume the UUID is truncated here):
> UUID=45F2-140B /Meta vfat utf8,users,noauto 0 1
That UUID is exactly what mkdosfs created. It's so cool, it looks just like MSDOS did the format...
> to read (replace the gid with the Group ID for the "users" group on your system):
> UUID=45F2-140B /Meta vfat utf8,users,noauto,gid=100,uid=0,fmask=117,dmask=007 0 1
This looks like a good solution for Ubuntu. But gid, uid, fmask, and dmask
are not in my SuSE 10.3 documentation. So, I found a work-around that doesn't use them.
I assume these are used to override system umask, group and owner during startup auto-mount?
> The noexec is not part of your issue, it's a flag that's set by default
> (unless you explicitly reverse the option in the mount command)
> for removable drives to reduce the probability that malicious software will
> be able to access your system.
I sorta thought so. But when Kevin mentioned it I really focused on the file permissions.
I'm gonna try out these newfangled /etc/fstab options pretty soon.
My next post is how I came to another solution. The painful way.
(-: Chas.M. :-)
-----
Date: Mon, 30 Aug 2010 21:27:11 -0700
From: plug-discussion at stcaz.net
To: plug-discuss at lists.plug.phoenix.az.us
Subject: Re: Operation (by root) not permitted
ChasM,
Because vfat has no permissions of it's own, but the POSIX filesystem layer needs to see permissions, the vfat filesystem driver "makes it up".
Fortunately, you can control the permissions it sets, from the machine that's mounting the drive.
In your fstab, change the line that reads (I assume the UUID is truncated here):
UUID=45F2-140B /Meta vfat utf8,users,noauto 0 1
to read (replace the gid with the Group ID for the "users" group on your system):
UUID=45F2-140B /Meta vfat utf8,users,noauto,gid=100,uid=0,fmask=117,dmask=007 0 1
The noexec is not part of your issue, it's a flag that's set by default (unless you explicitly reverse the option in the mount command) for removable drives to reduce the probability that malicious software will be able to access your system.
ChasM Marshall wrote:
> Thanks for the input, I'm still stuck.
>
> @Kevin:
>> Your problem is right there.
>> You have noexec as a mount option.
>> Remove it and everything should work.
> "noexec" ? Huh? Where?
> Where does "noexec" in /etc/mtab come from?
> Since this is primarily for data storage, execution was never a concern.
> My /etc/fstab lists "users", and (for mount, umount) that works okay.
> Originally it included "UID=49" which is "plg-dev", an unlisted system user.
> ls listings originally showed plg-dev as owner, but only in an Ubuntu boot.
> I have yet to see ls display "users" for group ownership.
>
> @Alan:
> Totally correct. I understand the vfat permission limitations.
> The chgrp operation seems not very appropriate in a vfat system.
> So, why does ls show LIMITED permissions (and root ownership)?
> I don't even know how Linux can keep track.
> So, for vfat filesystem:
> Is it NOT possible for Linux to set group ownership to users?
>
> My basic problem still is:
> No one but root can create or copy files/directories onto that partition.
>
> (-: Chas.M. :-)
>
>> Date: Sun, 29 Aug 2010 22:41:58 -0700
>> Subject: Re: Operation (by root) not permitted
>> From: adayley at gmail.com
>> To: plug-discuss at lists.plug.phoenix.az.us
>>
>> You are attempting to change "Linux style" group settings on files in
>> a vfat file system. That will not work. The vfat file system does
>> not have a way to set or change group ownership.
>>
>> The error message is not worded very well. It should say something
>> like "Cannot set group ownership in vfat (FAT32) file system"
>>
>> Alan
>>
>> On Sun, Aug 29, 2010 at 9:52 PM, ChasM Marshall <chasm750 at hotmail.com> wrote:
>>> Hiya,
>>>
>>> Okay, I'm baffled. What in the Ubuntu 9.07 is going on here?
>>>
>>> # uname -a
>>> Linux BlueBeast.localhost 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17
>>> 01:57:59 UTC 2009 i686 GNU/Linux
>>>
>>> Logged in as root I've edited /etc/fstab.
>>> I want the /Meta vfat partition completely open (unlocked).
>>>
>>> # cat /etc/fstab
>>> # /Meta was /dev/sda5
>>> UUID=45F2-140B /Meta vfat utf8,users,noauto 0 1
>>>
>>> # mount
>>> /dev/sda5 on /Meta type vfat (rw,noexec,nosuid,nodev,utf8)
>>>
>>> # cat /etc/mtab
>>> /dev/sda5 /Meta vfat rw,noexec,nosuid,nodev,utf8 0 0
>>>
>>> # ls -al
>>> drwxr-xr-x 3 root root 4096 1969-12-31 17:00 Meta
>>>
>>> # chgrp -hR users /Meta
>>> chgrp: changing group of `/Meta/Linux/TextTest.txt': Operation not
>>> permitted
>>> chgrp: changing group of `/Meta/Linux': Operation not permitted
>>> chgrp: changing group of `/Meta/TextTest.txt': Operation not permitted
>>> chgrp: changing group of `/Meta/FireFoxMint.jpg': Operation not permitted
>>> chgrp: changing group of `/Meta/FireFoxFedora.jpeg': Operation not
>>> permitted
>>> chgrp: changing group of `/Meta/FireFoxSuSE.jpg': Operation not permitted
>>> chgrp: changing group of `/Meta/NVIDIA-Linux-x86-190.53-pkg1.run':
>>> Operation not permitted
>>> chgrp: changing group of `/Meta': Operation not permitted
>>>
>>> I can not figure out what in Ubuntu (Mint 7) stops root (#) from assigning
>>> permissions here.
>>> Can you?
>>> This vfat partition was created in SuSE 9.3 and used mkdosfs to create the
>>> file system.
>>> /Meta is a common mount point (folder?) for multiple of my Linux distros.
>>> But it's getting harder to use.
>>> As root, it functions okay (mostly) as a common data folder. I want to give
>>> access to all users
>>> of any current-booted Linux. In SuSE 10.3 the process required a new
>>> /etc/fstab entry followed
>>> by the chgrp command as above. But in Ubuntu, I'm a bit lost.
>>> Here I can see a disagreement between /etc/fstab and /etc/mtab that I can't
>>> reconcile.
>>>
>>> It may be a while before I can return to the PLUG mail list. So be
>>> patient with me.
>>>
>>> (-: Chas.M. :-)
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20100831/29533c30/attachment.html>
More information about the PLUG-discuss
mailing list