Bug 4398 - Cannot access [Homes]-Share of mapped users
Cannot access [Homes]-Share of mapped users
Status: RESOLVED WONTFIX
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.24
x86 All
: P3 major
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-14 12:39 UTC by Matthias Schuendehuette
Modified: 2016-01-19 15:57 UTC (History)
0 users

See Also:


Attachments
Archive of /var/log/samba for access to \\Server\homes (65.94 KB, application/octet-stream)
2007-02-14 12:43 UTC, Matthias Schuendehuette
no flags Details
Archive of /var/log/samba for access to \\Server\matthias (66.57 KB, application/octet-stream)
2007-02-14 12:46 UTC, Matthias Schuendehuette
no flags Details
Archive of /var/log/samba for access to \\Server\homes (116.29 KB, application/octet-stream)
2007-02-15 02:10 UTC, Matthias Schuendehuette
no flags Details
Archive of /var/log/samba for access to \\Server\matthias (117.24 KB, application/octet-stream)
2007-02-15 02:12 UTC, Matthias Schuendehuette
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Schuendehuette 2007-02-14 12:39:31 UTC
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.
Comment 1 Matthias Schuendehuette 2007-02-14 12:43:46 UTC
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"
Comment 2 Matthias Schuendehuette 2007-02-14 12:46:58 UTC
Created attachment 2290 [details]
Archive of /var/log/samba for access to \\Server\matthias
Comment 3 Matthias Schuendehuette 2007-02-14 12:49:41 UTC
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"
Comment 4 Volker Lendecke 2007-02-14 13:11:06 UTC
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
Comment 5 Matthias Schuendehuette 2007-02-14 13:30:03 UTC
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...
Comment 6 Matthias Schuendehuette 2007-02-15 02:10:45 UTC
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"
Comment 7 Matthias Schuendehuette 2007-02-15 02:12:57 UTC
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"
Comment 8 Matthias Schuendehuette 2007-02-15 02:16:08 UTC
(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 
Comment 9 Volker Lendecke 2007-02-15 09:00:06 UTC
Can you try to set 'msdfs root = no' in the [homes] section?

Volker
Comment 10 Matthias Schuendehuette 2007-02-15 09:38:47 UTC
Did that already - then neither \\blnn719x\homes nor \\blnn719x\matthias is accessible any more.

"Things tend from bad to worse" :-}

- Matthew
Comment 11 Volker Lendecke 2007-02-15 10:20:15 UTC
Next try: 'netbios aliases = blnn719x'

Volker
Comment 12 Matthias Schuendehuette 2007-02-16 03:13:31 UTC
No difference:
'\\blnn719x\homes' does NOT work
'\\blnn719x\matthias' works
Comment 13 Volker Lendecke 2007-02-16 09:48:42 UTC
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
Comment 14 Matthias Schuendehuette 2007-02-16 12:47:26 UTC
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!
Comment 15 Björn Jacke 2016-01-19 15:57:13 UTC
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.