Apparently there's been changes in OSX Mavericks smb mount client
that allows multiple users to access SMB mounts to remote servers.
This didn't used to be the case; see:
http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-viewthread+1013+1014+1015+1019+1020+1021+1024+1595
I just tried creating a mount with Mavericks, and it seems to now
allow multiuser access, e.g.
# mkdir /var/tmp/testmount
# chmod 777 /var/tmp/testmount
# mount -t smbfs //guest:@eagle/net /var/tmp/testmount
In this case host "eagle" is a Mac running 10.6.8 with the built-in
Samba 3.0.29a-apple server with guest account access enabled:
------------------------------
[net]
comment = net
path = /net
available = yes
guest ok = yes
public = yes
create mask = 666
directory mask = 777
read only = no
hide dot files = no
------------------------------
Anyway, I tried accessing a file on /var/tmp/testmount
as two different users ('render' and 'erco') to see if there'd be
the usual trouble with permissions. Turned out to work OK:
# su - render
maver:~ render$ ls -la /var/tmp/testmount/tmp/foo
-r-xr-xr-x@ 1 render staff 7074 Jan 22 04:32 /var/tmp/testmount/tmp/foo
# su - erco
[erco@maver] 1 : ls -la /var/tmp/testmount/tmp/foo
-r-xr-xr-x@ 1 erco staff 7074 Jan 22 04:32 /var/tmp/testmount/tmp/foo
^^^^^^^^^^ ^^^^
This is great; both users can access the mount that was created
by root with 777 perms on the mount point.
The owner of the file is showing under smb as whomever the
current user is that is logged in.
Also of interest, when a user creates a file on the smb mounted
volume, other smb users can read/write it too, which is also useful:
# su - erco
[erco@maver] 2 : echo > /var/tmp/testmount/tmp/foo-erco -- create a new file
[erco@maver] 3 : ls -la /var/tmp/testmount/tmp/foo-erco -- view perms
-rw-r--r--@ 1 erco staff 1 Mar 6 11:46 /var/tmp/testmount/tmp/foo-erco
^^^^^^^^^^ ^^^^
Then, when I become the 'render' user, it now appears 'render'
owns the file, and thus has write permission to it:
# su - render
maver:~ render$ ls -la /var/tmp/testmount/tmp/foo-erco
-rw-r--r--@ 1 render staff 1 Mar 6 11:46 /var/tmp/testmount/tmp/foo-erco -- perms open to us
^^^^^^^^^^ ^^^^^^
maver:~ render$ echo overwrite >> /var/tmp/testmount/tmp/foo-erco -- writing works
maver:~ render$ ls -la /var/tmp/testmount/tmp/foo-erco -- view perms and size
-rw-r--r--@ 1 render staff 11 Mar 6 11:48 /var/tmp/testmount/tmp/foo-erco
So that all looks pretty good actually; no permission errors
at all between the two users over the same mount.
The ownership of the files taking on whomever is logged in is
a little weird; you can't tell who created the file.
But if you don't care about that, and primarily don't want to run
into permission issues, this might be a good thing.
I found the following interesting though: if I change the unix umask,
it actually affects the unix perms shown over the SMB mounted volume:
# cd /var/tmp/testmount/tmp
# umask 000 ; echo > umask-000
# umask 002 ; echo > umask-002
# umask 022 ; echo > umask-022
# umask 222 ; echo > umask-222
# ls -la umask-???
-rw-rw-rw-@ 1 _unknown _unknown 1 Mar 6 17:04 umask-000
-rw-r--r--@ 1 _unknown _unknown 1 Mar 6 17:04 umask-002
-rw-r--r--@ 1 _unknown _unknown 1 Mar 6 17:04 umask-022
-r--r--r--@ 1 _unknown _unknown 1 Mar 6 17:05 umask-222
..which is a little odd; the umask 0 gives rw-rw-rw,
whereas 002 and 022 both give rw-r--r--, and a umask of 222
gives r--r--r--.
Also, the /actual/ unix perms on the server reflect the umask
values we used.
If I connect over to the server and do an 'ls -la' on the unix
file system to look at the files we created above over smbfs,
the perms reflect the umask values we used:
# rsh eagle ls -la /net/tmp/umask-???
-rw-rw-rw- 1 nobody wheel 1 Mar 6 17:04 /net/tmp/umask-000
-rw-rw-r-- 1 nobody wheel 1 Mar 6 17:04 /net/tmp/umask-002
-rw-r--r-- 1 nobody wheel 1 Mar 6 17:04 /net/tmp/umask-022
-r--r--r-- 1 nobody wheel 1 Mar 6 17:05 /net/tmp/umask-222
I find this surprising, as I didn't think smbfs understood
things like umasks and unix permissions, Looks like it kinda does,
enough to set the perms, but not able to display them properly.
Anyway, some interesting stuff; looks like there's now hope
of using smbfs in multiuser environments again.
|