Problems with dfs and Samba 3.0.24-5/3.0.25-7 - please help

[Jeremy Allison]

On Wed, May 16, 2007 at 05:59:41PM -0700, Jeff Coffler wrote:
> Hi,
> 
> I'm running Fedora Core 6, and I'm having a heck of a problem with 
> Samba.  I'm pretty sure it's related to the dfs code.  I noticed this 
> code change from Jeremy:
> 
>    http://lists.samba.org/archive/samba-cvs/2007-March/075343.html
> 
> It seemed like this was related based on my level 3 logs.  But I 
> verified that 3.0.25-7 has that fix, and yet my problem continues.
> 
> My server is just a simple standalone server with user authentication.  
> When I connect from Windows XP, I get:
> 
>    % net use x: \\miffy\jeff
>    System error 3 has occurred.
> 
>    The system cannot find the path specified.
> 
> Samba 3.0.24-1 (downloaded as part of FC6) works perfectly.  The above 
> works without an issue.
> Samba 3.0.24-5 (downloaded as an update of FC6) is broken.
> If I download 3.0.25-7 from Samba.org for FC6, it's broken.
> 
> In the logs for the broken cases (log level 3), the point where I 
> *think* things go sour is here:
> 
> [2007/05/16 14:27:29, 3] smbd/msdfs.c:get_referred_path(624)
>  get_referred_path: |jeff| in dfs path \miffy\jeff is not a dfs root.
> [2007/05/16 14:27:29, 3] smbd/error.c:error_packet_set(106)
>  error packet at smbd/trans2.c(6184) cmd=50 (SMBtrans2) NT_STATUS_NOT_FOUND
> 
> It goes downhill from there.  But I'm not certain, as I don't have a lot 
> of experience looking at Samba logs.
> 
> I have log level 3's of the working case (3.0.24-1) and the broken cases:
> 
> The working case:
>    https://webdav.taltos.com/jcoffler-lap.log.good
> 
> The broken case (3.0.24-5):
>    https://webdav.taltos.com/jcoffler-lap.log.bad.24-5
> 
> And the broken case (3.0.25-7):
>    https://webdav.taltos.com/jcoffler-lap.log.bad
> 
> I'm at a loss of where to go from here.  Can anyone offer any advice?  
> It seems like there was some sort of code change here that broke things, 
> but my usage case seems so simple, I just don't get it.

Ah - this explains a lot. The default for the "msdfs root"
parameter changed between 3.0.24 from True to False.

Has this client been restarted since the new Samba
load was added and restarted ?

If not - try rebooting the client. The clients remember
if a server was a dfs root and act accordingly until a
restart.

The decision was made to change "msdfs root = no"
due to problems detecting that the initial name given in
a dfs root path belonged to this server (as I recall).

Jeremy.