[kwlug-disc] mount changes mount point (dir) permissions to root, root - how to affect?
unsolicited at swiz.ca
Wed Nov 27 11:28:58 EST 2013
[Apologies for the repost - prior posted under the wrong subject /
thread. If not reposted under the original subject, I'll never find it
Looks to be a bug in smb / smbmount / mount.cifs - workaround, use id
numbers in uid and gid instead of names.
search terms that finally got me somewhere useful "root:root", or '"user
root" "group root"'
On 13-11-26 03:03 PM, unsolicited wrote:
> 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
> umask 002
> 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
> discover, yet.
> 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
> mounted filesystem
> /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
>>> 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
>>>> 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
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
More information about the kwlug-disc