[kwlug-disc] mount changes mount point (dir) permissions to root, root - how to affect?
unsolicited at swiz.ca
Tue Nov 26 15:03:21 EST 2013
OK, this is puzzling.
If I mount (mount /dev/sdd1 /mnt/sdd1) an external eSata drive (btrfs),
it does not go to root/root, it stays with the user/group on the file
pre-mount, as desired. It mounted dr-xr-x--x, but let me chmod ug+w
successfully post mount. (drwxrwsr-x, pre-mount) As non-sudo, I can
list/read files successfully.
I I mount an (xp) smb mount (./mysmbmount //there/share
/mnt/there/share), I get the behaviour noted earlier: root/root,
drwxrwx--x. If I try to go to that directory, permission denied.
./mysmbmount == smbmount $1 $2 -o
At sudo umask was becoming 022 - discovered visudo: Defaults umask =
0002, Defaults umask_override
- which fixed that.
Not that umask is playing a role here. So far as I have been able to
So, it's an smbmount issue. man smbmount (mount.cifs) shows:
- user=arg (== username=) specifies the username to connect as.
= appears to be taking value from uid - or, at least, that's how the
files appear, just not the mountpoint itself.
- uid=arg sets the uid that will own all files or directories on the
/usr/bin/smbmount -> /sbin/mount.smbfs, which calls mount.cifs.
So, OP reported that an smb mount goes to root/root - although group
write permissions, which is fine per pre-mount user/group, change means
no write access.
Could someone give me a sanity check, and try an smb mount and report if
the dir's (== mountpoint post-mount) user/group stays not root/root?
On 13-11-26 05:39 AM, unsolicited wrote:
> Such options affect the ownership of the files under the mount point,
> not the mount point itself - or so is my experience / understanding.
> oid and gid are set in my mount, and the files under the mount point are
> certainly affected, but the mount point itself is still root/root, o=x,
> and the same user cannot list the files in the file system.
> I assume my experience is normal (I'm missing some salient point), if
> your experience is different or that's not normal, I would sure
> appreciate a heads up.
> On 13-11-25 09:17 PM, Chris Craig wrote:
>> Maybe something like this would work:
>> mount ... -o gid=users
>> The mount options specified with "-o" certainly affect the mount point...
>> It's generally the permissions of the device being mounted that take
>> effect, not the mount point. Umask does take effect, but if it's more
>> permissive than the device permissions then it won't be noticed. You
>> can add ",umask=000" to the mount "-o" option if you find it does
>> cause a problem.
>> On 25 November 2013 16:22, unsolicited <unsolicited at swiz.ca> wrote:
>>> If I mount something from the command line (win share at this point),
>>> owner/group on the dir, e.g. /mnt/here, change from what was set, to
>>> root/root, and a non-root user can't get past it (I think), to the files
>>> below it. (I say I think because I can set owner/group however I
>>> want, but
>>> since it goes to root/root, and I'm not root at use point, "a
>>> non-root user
>>> can't get past it (I think)"
>>> What (prep) do I need to set before mounting so instead of root/root it
>>> stays something useful, like root/users. (Yes, that assumes users and
>>> permission are set up reasonably.)
>>> Also, chown after mounting is ineffective - permission denied, even
>>> as root.
>>> I'm missing some element, and Google fu not working for me here -
>>> Before: drwxrwsr-x 2 me users ... x
>>> After: drwxrwx--x 1 root root ... x
>>> I'd be ok with this, if but the group were still users.
>>> To contrast, mkdir and touch (as root) result in:
>>> drwxrwsr-x 2 root users ... newdir/
>>> -rw-rw-r-- 1 root users ... newfile
>>> Note: Sorry, don't mean to be rude, but a lot of non-answers searching
>>> google, burying what I'm looking for.
>>> - there is no fstab entry, nor do I wish there to be, for this one off.
>>> Therefore I have to be root to mount anything.
>>> - the mount options are not germane, they apply to the files under the
>>> mountpoint (which are fine), not to the mountpoint itself.
>>> - not interested in alternate solutions, e.g. gvfs, nor mounting
>>> other than under /mnt. Looking to find out what basic fact I'm
>>> missing about
>>> mounting this way.
>>> umask doesn't seem to be in play. (Correct me if I'm wrong, please.)
>>> There is no umask equivalent for directories - such stem from umask.
>>> that that is even germane, here.] (Correct me if I'm wrong, please.)
>>> Setting 777 on the directory, before mount, is ok? (Not that it gets me
>>> anywhere.) Since mount options set file permissions for stuff under the
>>> mountpoint? [Except, I would have thought o+x would let me traverse
>>> it to
>>> the point where those mount option file permissions would take effect
>>> - at
>>> this point, I can't even get (read) to the mount point in konqueror
>>> as the
>>> kwlug-disc mailing list
>>> kwlug-disc at kwlug.org
>> kwlug-disc mailing list
>> kwlug-disc at kwlug.org
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
More information about the kwlug-disc