GNOME Bugzilla – Bug 738180
Cannot access DFS shares
Last modified: 2018-09-21 17:43:23 UTC
DFS shares cannot be accessed when mounted via nautilus. Steps to reproduce: 1. Mount smb share using nautilus (note: the share is in a windows domain in my case). 2. Try to open a DFS share in Nautilus/terminal Actual result: DFS shares are not listed in Nautilus The situation is more funny in the terminal. The shares are listed by `ls` but for every share an error message stating, that the file or directory could not be found, is issued. `cd` into gives the same error message. Expected result: DFS shares are listed in Nautilus. Versions affected: I don't know exactly. It works in Ubuntu 12.04. It definitively does not work in Fedora 20+, Mint 17, Ubuntu 14.04 i.e. Gnome 3.14 does not work either. Comments: I shall note that manual mounting with `mount -t cifs -o user=username,domain=domain //server/share /mount_point` does indeed work. I.e. the DFS shares can be accessed. I am happy to supply more information if you tell me how to obtain them. More specifically I did not see any error message popping up in dmesg.
Thanks for the report. I think it is more likely that this is a configuration problem or something in the Samba code. Nevertheless, please run the following in a terminal: pkill gvfs; GVFS_DEBUG=all GVFS_SMB_DEBUG=10 `find /usr/lib* -name 'gvfsd'` &> ~/log.txt Reproduce the problem, and then upload log.txt in your home directory so we can see a log of what is happening. Also, see if you can retrieve a file from a DFS share using smbget (which uses the same library as gvfs), list shares using smbtree and connect to shares using smbclient. It is quite common for the cifs module to behave differently than userspace applications using the Samba library.
Created attachment 288103 [details] Log file as requested
Thanks for the promt reply. The command was exactly what I was looking for, I attached the log file. If it is just a configuration problem that would be great then I will file it downstream. I just assumed it is a gnome thing since it does not work both on Fedora and Ubuntu. `smbget` fails as well with NT_STATUS_LOGON_FAILURE. `smbclient` on the other hand works like a charm.
Here is the relevant stuff: """ Queued new job 0x17718d0 (GVfsJobQueryInfo) smbc_stat(smb://data.ad.nfit.example.com/nfdfs/IFA/SHARE) SMBC_getatr: sending qpathinfo internal_resolve_name: looking up DFS2.AD.NFIT.example.com#20 (sitename (null)) no entry for DFS2.AD.NFIT.example.com#20 found. resolve_lmhosts: Attempting lmhosts lookup for name DFS2.AD.NFIT.example.com<0x20> resolve_lmhosts: Attempting lmhosts lookup for name DFS2.AD.NFIT.example.com<0x20> startlmhosts: Can't open lmhosts file /etc/samba/lmhosts. Error was Datei oder Verzeichnis nicht gefunden resolve_wins: WINS server resolution selected and no WINS servers listed. resolve_hosts: Attempting host lookup for name DFS2.AD.NFIT.example.com<0x20> remove_duplicate_addrs2: looking for duplicate address/port pairs namecache_store: storing 1 address for DFS2.AD.NFIT.example.com#20: 10.19.28.13 Adding cache entry with key=[NBT/DFS2.AD.NFIT.example.com#20] and timeout=[Do Okt 9 09:36:52 2014 CEST] (660 seconds ahead) internal_resolve_name: returning 1 addresses: 10.19.28.13:0 Connecting to 10.19.28.13 at port 445 ... SPNEGO login failed: Logon failure map_errno_from_nt_status: 32 bit codes: code=c0000257 smbc errno NT_STATUS_PATH_NOT_COVERED -> 2 session setup failed: NT_STATUS_LOGON_FAILURE Couldn't resolve \IFA\SHARE send_reply(0x17718d0), failed=1 (Datei oder Verzeichnis nicht gefunden) """ gvfs makes a call to libsmbclient: smbc_stat(smb://data.ad.nfit.example.com/nfdfs/IFA/SHARE) The call results in a lookup to another host which fails. Given that smbget fails for you, it looks like a libsmbclient issue. Please create an issue on https://bugzilla.samba.org/ (and post a link back here...). Thanks
Ok I filed a bug at samba https://bugzilla.samba.org/show_bug.cgi?id=10868
Maybe it is not a smb problem after all I must apologize. Unfortunately these tools have slightly different options such that I got confused. First I could not reproduce the issue with smbget today as 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? I also tested it with Mint 16 (Mate) in a VM. There I can access the share. Maybe this helps to narrow down the cause of this regression.
Well the main difference between Mint 16 and Mint 17 is Samba 3.6 to Samba 4. There is little difference in gvfs. Anyway, I'll have another look soon and see if I can spot anything. If you can, please attach logs running smbget -d 10 with the 3 different ways of logging in on both Mint 16 and Mint 17. Also, gvfs debug logs on Mint 16 would also be helpful. Thanks
This is maybe not necessary. The incident with smbget gave me the crucial hint. The domain name nautilus asks for apparently used as a workgroup name not as the domain name. So if I log in with my user name and my domain name I get this error (in gnome newer than Mint 16). If I log in with domain\username as the user name and use some random thing (WORKGROUP for example) as the domain name it works! I suspect there was a change in samba how the workgroup name is treated. So either it is a bug in Nautilus because the field has the wrong label or it is a bug in gvfs which did not adjust for some apparent change between Samba 3.6 and Samba 4 or it is a bug how our DFS it set up which only affects newer versions of Samba. What do you thing?
It looks like the same thing applies to smbget, i.e. if you pass the domain as the workgroup (-w), it fails. Try "smbget -w Domain -u User smb://server/share/file" on Mint 16. If it works, then the change would appear to be in how new Samba is interpreting the workgroup/domain; in that case, I suggest you reopen the Samba bug with these new findings or post to the Samba mailing list. Afaik, the libsmbclient API has not changed between Samba 3.6 and Samba 4.x. Thanks
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/238.