Bug 10868 - Cannot open DFS share
Summary: Cannot open DFS share
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: libsmbclient (show other bugs)
Version: unspecified
Hardware: All All
: P5 major (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
Depends on:
Reported: 2014-10-10 17:48 UTC by Nils
Modified: 2014-11-01 19:02 UTC (History)
2 users (show)

See Also:

Log file of the failed access attempt. (109.99 KB, text/plain)
2014-10-10 17:48 UTC, Nils
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nils 2014-10-10 17:48:16 UTC
Created attachment 10345 [details]
Log file of the failed access attempt.

Trying to fetching a file from an DFS share using smbget results in NT_STATUS_UNSUCCESSFUL. 

The same happens when using Nautilus. I filed a bug with gnome https://bugzilla.gnome.org/show_bug.cgi?id=738180 where it was speculated that it might be a bug in libsmbclient since smbclient works without any problem. Thus I was ask to file a bug here.

I attached a log file from an unsuccessful access attempt using nautilus. Since it still worked with Ubuntu 12.04 I speculate that it is an regression happened after samba 4.0.

I am happy to provide more information if you tell me how to generate the relevant log files.
Comment 1 Jeremy Allison 2014-10-28 21:30:34 UTC
Hmmm. Looking at this log file shows a login failure to the server being referred to in the DFS link. Are you sure this is a Samba problem ?
Comment 2 Nils 2014-10-29 07:44:31 UTC

All I'm sure about that some regression occurred in gnome-vfs between Ubuntu 12.04 (don't remember if Mint 16 worked) and now. It is not a Debian-Problem because F2x does not work either.

The funny thing is that it is sometimes working:

Not working: smbget + gnome-vfs
Working: smbclient + mount.cifs

Because of this I was redirected here.
Comment 3 Nils 2014-10-29 10:24:31 UTC
Maybe it is not a smb problem after all I must apologize. First I could not reproduce the issue with smbget.

    smbget -uDomain\\User smb://server/share/file

worked. Then I played with the parameters

    smbget -wDomain -uUser smb://server/share/file

gives NT_STATUS_LOGON_FAILURE just like nautilus. Note that I don't get NT_STATUS_LOGON_FAILURE if I use

     smbget -uUser smb://server/share/file

Maybe the domain is passed wrongly from nautilus to libsmbclient?
Comment 4 Björn Jacke 2014-10-29 14:20:24 UTC
assuming this as invalid for now. If you think it is a libsmbclient issue, please reopen the bug and also give detailled information about the version you use on client and on server side and steps to reproduce.
Comment 5 Nils 2014-10-31 10:47:54 UTC
I did some more investigations and the behavior of smbclient changed somewhere between 4.1 and 3.6.

According to an old email [1] on the samba mailing list there should be no fundamental difference between domains and workgroups. Nevertheless with libsmbclient 3.6 I can indeed access my DFS share using

    smbget -wDomain -uUser smb://server/share/file

When using libsmbclient 4.1 on the other hand this fails and I have to use 

    smbget -uDomain\\User smb://server/share/file

it seems that this change is the cause of my problems with nautilus. If the statement in the referred email is true this seems to be a bug.

On the server side a Windows 2008 server is used but I'm not aware of the exact structure.

[1] https://lists.samba.org/archive/samba/2005-July/108302.html
Comment 6 Jeremy Allison 2014-10-31 18:14:23 UTC
Actually this is expected and is more correct behavior.

User is not the same UNIX user as DOMAIN\\User.

smbget -WDomain -uDomain\\User smb://server/share/file

would also probably work. It's a matter of getting the
correct username placed in the NTLM auth field.
Comment 7 Nils 2014-11-01 19:02:03 UTC
So you're saying that the current behavior is the correct one and previously it just worked "by accident"? If so, is there any point in accepting a separate workgroup parameter? Why is it needed, it does apparently not work as naïvely expected.