Can't See Parts of DFS CIFS Share

[Larry Reid]

Binary package hint: gvfs

When connecting to a DFS share using Nautilus on Ubuntu 10.04, I can only see part of the directory tree. Take the example of a share with a DFS root at X, and sub directories A, B, and C all on different servers. I can connect to X, and see A, B, and C, but directories A, B, and C are all shown as empty. If I directly connect to X/A, then I can see the files and directories in and below A.

Using smbclient directly from the command line gives the same behaviour.

I found this from several years ago: http://lists.samba.org/archive/samba-technical/2007-April/052725.html. It seems to exactly describe my issue, and suggests that it's because when you cross to another server in the DFS hierarchy, smbclient re-authenticates (as it's supposed to) but with the wrong credentials.

I can't find any responses to the above post.

The may be related to bug: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/475679.

[Sebastien Bacher (seb128)]

thank you for your bug report, if smbclient has the same issue it's likely a samba bug

[Larry Reid (lcreid)]

Does Nautilus use smbclient (or the client library) for sure? Is it possible that the issue is in the way Nautilus uses smbclient? I'm prepared to work with someone to find a solution e.g. testing, providing more info on my situation. We can work bottom up or top down, whichever you prefer. Just let me know what you what me to try.

[James Page (james-page)]

Hi Larry

Please could you follow the debugging procedure located at [0] and attach any output to this bug report.

Thanks

[0] https://wiki.ubuntu.com/DebuggingSamba#samba-client

[Larry Reid (lcreid)]

James, will do. I may get to it tonight Pacific Time or at the latest over the weekend.

I've traced the code enough to feel confident that my problem is NOT related to the authentication issue I mentioned in my original bug description. I'm currently looking at a path that seems to lose a \ somewhere along the way.

[Larry Reid (lcreid)]

Is it a regression ?
Did this use to work properly with a previous release ?

    Not as far as I know.

What version of samba packages are used ?
Please give the output of:

dpkg-query -W -f='${Package} ${Version} ${Source} ${Status}\n' | grep samba

libsmbclient 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
libwbclient0 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
samba-common 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
samba-common-bin 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
smbclient 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
smbfs 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed
winbind 2:3.4.7~dfsg-1ubuntu3.5 samba install ok installed

How is the remote share accessed from the Ubuntu system?
nautilus (or other GUI client) YES
smbclient (from the command line) YES
cifs filesystem mount (from /etc/fstab or a mount command) YES
If nautilus (or another GUI client) is used to access the remote share, can the share be accessed with the smbclient command line utility ? NO

To test:

install the samba-client package
try to connect to the remote system from the command line:

smbclient //remote_system/share_name

    Connection works, but crossing to another server through DFS doesn't

If the share requires a specific username/password, try using the "-U" parameter (for example, use "-U ntdomain\\user").

smbclient doesn't work either. I have tried all combinations of ways to authenticate. With -d 10 I'm seeing messages that make me reasonably confident it's not an authentication problem (but it could be, I suppose).

If a cifs mount is used
In that case please also provide:

the content of the file /etc/fstab, or the command line used to mount the remote share if the share is manually mounted.

    sudo mount -t cifs --verbose -o user=my-domain/my-username //my-server/my-share /mnt

    mount works. Nautilus, gvfs-mount and smbclient don't.

the content of the file /proc/fs/cifs/DebugData

What is the remote server ?
In all cases, please include the output of the following smbclient command:

smbclient -L //remote_system
This should give us the remote server version. Also include on what kind of machine the share is located (Windows 2003 Server, Ubuntu 8.04, NAS box model...)

    It's an EMC Celerra NAS NSG-8 with NAS version 5.6.50

    I can't get the command output right now because the VPN is down. (Problem occurs with or without VPN.)

[Larry Reid (lcreid)]

Sorry for the extra post. VPN's working again. Here's the output of the smbclient -L command:

Domain=[my-domain] OS=[EMC-SNAS:T5.6.50.2] Server=[my-server]

 Sharename Type Comment
 --------- ---- -------
 my-share Disk DFS01 root share
 C$ Disk Root Service
 IPC$ IPC IPC Service
Domain=[my-domain] OS=[EMC-SNAS:T5.6.50.2] Server=[my-server]

 Server Comment
 --------- -------

 Workgroup Master
 --------- -------

[James Page (james-page)]

Hi Larry

Thanks for all of the additional information that you provided.

I've setup a basic DFS on Samba configuration across two Samba servers (Natty release). I've tried accessing the DFS based paths from both Maverick and Lucid installations using smbclient and as long as I have exactly the same username/password on both Samba servers it works just fine.

Is it possible that the server providing the share linked from the DFS root is expecting different credentials? Please could you try to confirm this by directly accessing the server/share that the DFS link refers to using smbclient.

Thanks

[Larry Reid (lcreid)]

James: I downloaded the source for Samba 3.5.8, built it, and confirmed that it had the same problem. So I've been tracing the code. What I see is that in the function cli_dfs_get_referal in libsmb/clidfs.c two components of the path are returned: one that doesn't end in a \, and the other that doesn't start with a \. When the two paths are put together in the function cli_resolve_path (in the same source file), no \ is put between the components, which leads to smbclient not finding the directory.

I haven't had time to trace below cli_dfs_get_referral, but I believe that the path components are being returned by the server. I'm guessing (stress guessing) that there may be a difference in the EMC CIFS or DFS implementation, and EMC is returning a string without a trailing \ when other implementations return a trailing \.

Give me the weekend to see if I confirm my guesses. I'm pretty sure I have a patch that would work for me, but I have no resources to be able to test other cases to make sure my patch doesn't break anything else. Also, I think we have a case that this is indeed a case that Samba should handle. My limited experience upstreaming bugs from Ubuntu is that they never get addressed. My gut says the Samba team will be more responsive. What do you think the chances are that we can get the Samba team's attention for this?

[Larry Reid (lcreid)]

My fix for my issue works. As I said, I can't test it against other servers. Let me know how we should guide this through the Samba team. Thanks for your help so far!

[Chuck Short (zulcss)]

Please attach a patch and we can do the appropriate actions.

[Larry Reid (lcreid)]

Here's the patch. I made it on the v3-4-test branch of the Samba git repository. It seems to also patch the current stable 3.5.8 version. I hope this helps.

[Larry Reid (lcreid)]

I submitted the bug and patch to Samba at: https://bugzilla.samba.org/show_bug.cgi?id=8055.

[Launchpad Janitor (janitor)]

This bug was fixed in the package samba - 2:3.5.8~dfsg-1ubuntu2

---------------
samba (2:3.5.8~dfsg-1ubuntu2) natty; urgency=low

  * debian/patches/fix-upstream-lp-738968.patch: Fix connection
    to EMC Celerra NAS version 5.6.50. (LP: #738968)
 -- Chuck Short <email address hidden> Wed, 06 Apr 2011 12:56:42 -0400

[Julian Alarcon (julian-alarcon)]

Hi

I have the same problem but I'm on Ubuntu 14.04, our DFS is on Windows 2008 R2. Do you still have this problem like me?

[Larry Reid (lcreid)]

Julian: The patch I submitted fixed my problem (see #13 above). Unfortunately I don't have time tonight to try to reproduce the situation, and indeed I may not be able to (I'm not sure I have access to the server anymore). But I can definitely confirm that it was still fixed in LinuxMint 13 (Ubuntu 12.04), because I connected to the same share before I upgraded to LinuxMint 17.