Update 2
The path should look like so:
[homes]
comment = Home Directories
browseable = no
writable = yes
path = /tank/Users/%S
Note the capital %S.
Update
I found the answer to why the [home] share definition seemed to be screwed up. Basically, according to the smb.conf man page, %u maps to username, while %s maps to “service”. So, when I tried to access \\server\Public, the [home] directive gets matched because Public is a valid Samba user on the server. Samba then tries to figure out what directory this share should map to, and finds its definition is /tank/Users/%u. Well, %u gets expanded as Poojan, so it says that \\server\Public maps to /tank/Users/Poojan (as does \\server\Poojan). Instead, if I define the path as /tank/Users/%s, the directory gets expanded to /tank/Users/Public, because Public is the share being requested. And that’s what I want.
Original Post
I wanted to create per-user Samba shares on my file server. In addition (similar to Vista/Windows 7 setup), I wanted to create a Public directory. I thought (rather naively) that I could just add Public as another user. I did so with the following entry in smb.conf:
[homes]
comment = Home Directories
browseable = no
writable = yes
path = /tank/Users/%u
What’s weird is that I could log in and access \\server\Public\Documents (for example), but what I’d see was identical to \\server\Poojan\Documents[cci] ([cci]Poojan being my username). I found a few references that said the correct incantation is:
[homes]
comment = Home Directories
browseable = no
writable = yes
path = /tank/Users/%S
valid users = %S
This seemed to work–except I still couldn’t access the share. Apparently, the %S maps to the current user, not just any user (I still haven’t exactly figured this out).
Unfortunately, Windows CIFS/SMB protocol doesn’t allow one to log in to another machine under two different credentials. So, I couldn’t (for example) connect to the server under the credentials Poojan and then access a share with the username Public. I had a few options here: I could remove the valid users = %S directive, which meant that anyone could access the shares. Or, I could rely on UNIX group permissions. I decided to go the latter route. I didn’t want (for example) my kids to delete files in this share, as it contains some important stuff that both my wife and I should have access to. (I say should, because my wife has better things to do than to look up our 2004 tax return.)
So, I created the following entry:
[Public]
comment = Public (user-wide) directories
browseable = yes
writeable = no
path = /tank/Users/Public
write list = Poojan, Wife
create mask = 0770
directory mask = 0770
What’s weird is that I still couldn’t access the share. As it turned out, the [home] section took precedence. In order to stop the [home] directive from mapping a share to /tank/Users/%S, I had to delete the Samba user Public:
smbpasswd -x Public
It wasn’t enough to disable (smbpasswd -d) the Public user. Another thing I found (on FreeBSD at least) is that if you delete the UNIX user, you can’t then delete the Samba user; smbpasswd complains that the user database is corrupt because the Samba user exists but the UNIX user does not.
As far as the UNIX groups, etc., I created a UNIX group called Users to house the entire family. The UNIX directory /tank/Users/Public has the group set to Users. So, only members of the group can read/write (at the UNIX) level, and only the wife and I can write at the Samba level.
Post a Comment