Confused about samba4 & s3fs

Rowland Penny repenny at f2s.com
Mon Aug 20 04:48:20 MDT 2012


On 20/08/12 10:52, steve wrote:
> On 20/08/12 11:13, Marc Muehlfeld wrote:
>> Am 20.08.2012 10:04, schrieb Gémes Géza:
>>> I would suggest to set up a separate server running samba3 (or smbd,
>>> nmbd,
>>> winbind from samba4) for sharing home directories. Reasons:
>>> 1. samba/s3fs doesn't support the [homes] share which (in case of smbd)
>>> automatically maps to the users home folder
>>
>> If it's recommended or good to have the homes on an s4 server, I don't
>> know, but you can have [homes] on a s4 server (i tried it with s3fs on
>> beta4). Simply add
>>     [homes]
>>        read only = No
>> (nothing else is required) to your s4 smb.conf and restart samba.
>>
>> BUT: The users need to have a value in their "homeDirectory" attribute,
>> pointing to the path (like "/home/muehlfeld"). I had to fill this
>> manually, because on migration, the attribute is not transferred from
>> LDAP. But for new users you have to add this anyway manually.
>>
>
> Hi Marc
> The problem is that on S4/s3fs, winbind expects _all_ home directories 
> to be in /home/DOMAIN/user format. It cannot pull the actual home 
> directory from AD as can S3 winbind. The workaround (which I see as a 
> solution and real alternative to winbind) is to use nss-pam-ldapd 
> which just works. S3 or S4.
> Cheers and thanks for the input,
> Steve
>
>
>
>

Hi Steve, yes you are right but wrong, here is a list of users from my 
test server:

HOME\Administrator:*:0:100::/home/HOME/Administrator:/bin/bash
HOME\Guest:*:3000001:3000002::/home/HOME/Guest:/bin/bash
HOME\krbtgt:*:3000006:100::/home/HOME/krbtgt:/bin/bash
HOME\dns-adserver:*:3000007:100::/home/HOME/dns-adserver:/bin/bash
HOME\rowland:*:3000013:3000012::/home/HOME/rowland:/bin/bash
HOME\fred:*:3000022:3000012::/home/HOME/fred:/bin/bash
HOME\george:*:3000023:3000012::/home/HOME/george:/bin/bash
HOME\staff1:*:3000038:3000035::/home/HOME/staff1:/bin/bash
HOME\student1:*:3000039:3000036::/home/HOME/student1:/bin/bash
HOME\student2:*:3000040:3000037::/home/HOME/student2:/bin/bash
HOME\dhcpduser:*:3000041:100::/home/HOME/dhcpduser:/bin/bash

compare it with this from my test client (Xubuntu 12.04, Samba 3.6.3):

getent passwd
root:x:0:0:root:/root:/bin/bash
............
student1:*:3000039:3000036:student1:/home2/students/7a/student1:/bin/bash
student2:*:3000040:3000037:student2:/home2/students/7b/student2:/bin/bash
rowland:*:3000013:3000012:rowland:/home/HOME/rowland:/bin/bash
george:*:3000023:3000012:george:/home/HOME/users/george:/bin/bash
staff1:*:3000038:3000035:staff1:/home2/staff/staff1:/bin/bash
fred:*:3000022:3000012:fred:/home/HOME/fred:/bin/bash

Now if your users were to log into the server directly they would get a 
home directory in /home/HOME but I am sure that you would never let them 
log into the server only into a client.
So when they log into the client they use the unixhomedirectory as below

rowland at Notebook ~ $ ssh rowland at 192.168.0.162
rowland at 192.168.0.162's password:
rowland at vmclient:~$ pwd
/home/HOME/rowland
rowland at vmclient:~$ echo $HOME
/home/HOME/rowland
rowland at vmclient:~$ exit
rowland at Notebook ~ $ ssh student1 at 192.168.0.162
student1 at 192.168.0.162's password:
student1 at vmclient:~$ pwd
/home2/students/7a/student1
student1 at vmclient:~$ echo $HOME
/home2/students/7a/student1

If you examine an ldif of student1 you find:

unixHomeDirectory: /home2/students/7a/student1
profilePath: \\adserver\profiles\student1
homeDirectory: \\adserver\home\student1

I think that what is happening is that S4 winbind is taking the 
homeDirectory setting, loosing the first part, taking the second part, 
adding the domain name, taking the username (last part) and coming up 
with: /home/HOME/student1.
This may be what you want if you are using the [homes] directive, but 
can be ignored if you export the home directories as normal shares i.e. 
export /home2/students/7a as [7a]

Rowland

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



More information about the samba-technical mailing list