I have the following problem since Samba 3.0.23: I cannot access the [Homes]-Share with the UNC-Address "\\Server\homes" whereas I *can* access (in fact) the same share with the UNC-address "\\Server\<username>". This problem persists for Samba 3.0.24 as well. \\Server is member of an ActiveDirectory-Domain. I have no problems under Samba 3.0.22, which remains on our production server until the bug is fixed. Of course I made no configuration changes at all between 3.0.22 and 3.0.24. I have these problems with MIT-kerberos as well as with Heimdal-Kerberos (0.6x, FreeBSD 6.2 Base-System). I classify this problem as "major" because some process critical skripts rely on accessing the user's home-directory under a constant UNC-address. As I've learned from previous PRs, I attach two tar-archives with Level9-Logs (including 'smb.conf' and 'krb5.conf') of a session which accesses \\Server\Homes (samba-homes.tgz) and one session which accesses \\Server\matthias (samba-matthias.tgz) - which is in both cases my home-directory '/home/matthias' on \\Server.
Created attachment 2289 [details] Archive of /var/log/samba for access to \\Server\homes Complete Level-9 Logs including 'smb.conf' and 'krb5.conf' for a session accessing my home-directory Server:/home/matthias as "\\Server\homes"
Created attachment 2290 [details] Archive of /var/log/samba for access to \\Server\matthias
Comment on attachment 2290 [details] Archive of /var/log/samba for access to \\Server\matthias Complete Level-9 Logs including 'smb.conf' and 'krb5.conf' for a session accessing my home-directory Server:/home/matthias as "\\Server\matthias"
The connect to [homes] as such seems to work, but later on we try to access Blnn719x/homes instead of /home/matthias Whether this is client driven or not is not obvious from your log file, a debug level 10 log along with a sniff would help. http://wiki.samba.org/index.php/Capture_Packets shows you how to take them. Volker Volker
Hi Volker, It seems *not* to be client driven, because (I nearly don't have the heart to say) I have a Samba 3.0.24 on my FreeBSD 6-STABLE Workstation, where the access to \\Workstation\homes does indeed work... with exactly(!, exept for the many shares on the server) the same smb.conf and krb5.conf. I do these tests always from the same Windoze-Machine. I have not the slightest idea where's the difference between the Samba-machines - at least I never got a working machine again, every new installation I try doesn't work. Anyway - tomorrow I'll catch the Level-10 Logs and try to fire up tcpdump...
Created attachment 2291 [details] Archive of /var/log/samba for access to \\Server\homes Complete Level-9 Logs including 'smb.conf' and 'krb5.conf' for a session accessing my home-directory Server:/home/matthias as "\\Server\homes" Complete Level-10 Logs including tcpdump-trace 'samba-homes.pcap', 'smb.conf' and 'krb5.conf' for a session accessing my home-directory Server:/home/matthias as "\\Server\homes"
Created attachment 2292 [details] Archive of /var/log/samba for access to \\Server\matthias Complete Level-10 Logs including tcpdump-trace 'samba-matthias.pcap', 'smb.conf' and 'krb5.conf' for a session accessing my home-directory Server:/home/matthias as "\\Server\matthias"
(In reply to comment #4) > Whether this is client driven or not is not obvious from your log file, a debug > level 10 log along with a sniff would help. Uploaded! Hope that helps... Ciao - Matthew
Can you try to set 'msdfs root = no' in the [homes] section? Volker
Did that already - then neither \\blnn719x\homes nor \\blnn719x\matthias is accessible any more. "Things tend from bad to worse" :-} - Matthew
Next try: 'netbios aliases = blnn719x' Volker
No difference: '\\blnn719x\homes' does NOT work '\\blnn719x\matthias' works
Ok, I know what it is. The username map conflicts with the DFS. [2007/02/15 08:31:44, 3] smbd/map_username.c:map_username(155) Mapped user WW004\SchuendeMa to matthias So in the check whether \\Blnn719x\homes a valid \\host\sharename prefix we check "matthias" against WW004\SchuendeMa which certainly fails. I am *VERY* surprised that 'msdfs root = no' in [homes] did not help with this. Can you double-check this? Please restart smbd just to make sure it really gets caught. Volker
Oh Lord.... You're right! I don't know what I did yesterday, but it was obviously wrong. I stopped samba now, set "msdfs root = No" using swat, double checked smb.conf and started all daemons again - and it works! I'm very sorry for that - 3 of your gray hairs are on my bill :-) But this is a "workaround" and no fix, isn't it? At least it's sufficient for us, so this bug is not critical anymore. That does not mean that I won't test patches for this PR :-) Thank you very much so far!
in don't think that a username mapping should also modify the path of a homeshare that the user connects to. username mappings are a thing, that should be avoided whenever possible anyway.