[kwlug-disc] mount changes mount point (dir) permissions to root, root - how to affect?

[unsolicited]

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 
_netdev,directio,rsize=130048,wsize=130048,nobrl,nocase,sec=ntlmv2,credentials=/root/.smb.creds,uid=me,gid=users,file_mode=0771,dir_mode=0771

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 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),
>>> the
>>> 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 -
>>> suggestions?
>>>
>>> e.g.
>>>
>>> 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
>>> anywhere
>>> 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.
>>> [Not
>>> 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
>>> user.]
>>>
>>>
>>> _______________________________________________
>>> kwlug-disc mailing list
>>> kwlug-disc at kwlug.org
>>> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>>
>>
>> _______________________________________________
>> kwlug-disc mailing list
>> kwlug-disc at kwlug.org
>> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>>
>
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org