2

I'm trying to mount a DFS share via cifs. The share is built up like this:

\\mydomain.local\Files is the DFS share.
I can successfully mount this share as follows:

# mount -t cifs //mydomain.local/Files ~/fileserver -o username=myuser,domain=mydomain.local,password=hunter2

After this I can traverse the directories in ~/fileserver as I'd expect.

# ls ~/fileserver
folder1 folder2

When I try to cd into folder1 however, I get an error:

# cd folder1
cd: folder1: No such file or directory

It takes a second or two before the error appears.
I think this is because folder1 is a DFS-Link to another fileserver, it links to: \\fileserver2.mydomain.local\Fileshare$\somedirectory\folder1

Now I've looked at dmesg right after this:

# dmesg
CIFS: Attempting to mount //fileserver2.mydomain.local/Fileshare/somedirectory/folder1
No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
FS-Cache: Duplicate cookie detected
FS-Cache: O-cookie c=0000000088cf85cb [p=00000000a52bce0c fl=222 nc=0 na=1]
FS-Cache: O-cookie d=00000000ff7a58d3 n=000000005109413d
FS-Cache: O-key=[5] '46696c6573'
FS-Cache: N-cookie c=00000000c39f9d7a [p=00000000a52bce0c fl=2 nc=0 na=1]
FS-Cache: N-cookie d=00000000ff7a58d3 n=00000000930f66cf
FS-Cache: N-key=[5] '46696c6573'
No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
FS-Cache: Duplicate cookie detected
FS-Cache: O-cookie c=0000000088cf85cb [p=00000000a52bce0c fl=222 nc=0 na=1]
FS-Cache: O-cookie d=00000000ff7a58d3 n=000000005109413d
FS-Cache: O-key=[5] '46696c6573'
FS-Cache: N-cookie c=000000007c6a3385 [p=00000000a52bce0c fl=2 nc=0 na=1]
FS-Cache: N-cookie d=00000000ff7a58d3 n=00000000f006535b
FS-Cache: N-key=[5] '46696c6573'
No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
CIFS VFS: \\fileserver2.mydomain.local cannot query dirs between root and final path, enabling CIFS_MOUNT_USE_PREFIX_PATH
CIFS VFS: Autodisabling the use of server inode numbers on new server.
CIFS VFS: The server doesn't seem to support them properly or the files might be on different servers (DFS).
CIFS VFS: Hardlinks will not be recognized on this mount. Consider mounting with the "noserverino" option to silence this message.
CIFS VFS: cifs_read_super: get root inode failed

I believe the "cannot query dirs between root and final path" seems to be the actual problem, as I don't have permission to directly mount either the Share Fileshare$ or somedirectory, but only folder1. I could also directly mount this share on fileserver2, but since on the DFS there are many links to another server, I'd have to mount a whole lot of stuff.

I'm in the lucky position to be able to try the mount with an elevated account that can access both Fileshare$and somedirectory and when I mount it with that user instead of "myuser", I can access folder1:

# mount -t cifs //mydomain.local/Files ~/fileserver -o username=adminuser,domain=mydomain.local,password=hunter2
# ls ~/fileserver/folder1
file1 file2 file3

But I can't use this elevated account for day to day work - also, I'm not in a position to change the permissions on the DFS share or the fileserver.

The interesting part is that smbclient can do the traversal with myuser:

# smbclient '\\mydomain.local\Files' -U '[email protected]'
# smb: \> ls folder1
.
..
file1
file2
file3

I tried a lot of different options to the mount (mostly in desperation):

vers=1.0
vers=3.0
noserverino
sec=ntlmv2
sec=ntlmssp

Has anybody got any idea what else I could try?

The DFS share is on a windows server by the way.

1 Answer 1

0

I see a similar effect when trying to connect to a share which path is different to the main share distributed by DFS.

This makes me guess, that the "target hint" won't be recognized by the kernel mount.

Example: A Share provided as \\ad.example.com\dir1 points to a real share in a different Server \\server1.ad.example.com\dir1.

The mount command

mount -t cifs //ad.example.com/dir1 /mnt

leads to a accessible content in /mnt

On the other hand there is a share \\ad.example.com\upperdir with a subdirectory "dir2" which points also to a real share in a different Server \\server2.ad.example.com\dir2

If now using the command

mount -t cifs //ad.example.com/upperdir /mnt

I can see the subdirectory "dir2" in "/mnt", but when trying to access it I get the same error as described by jaffex (no such file or directory).

This only happens on my ubuntu 20.04 machine unsing a kernel version 5.4.0. The same comination on an ubuntu 18.04 with a kernel 4.15.0 even gets the second part working. Looking into "/proc/fs/cifs/dfscache" I can see that the server might provide the correct share to be used:

cache entry: path=\ad.example.com\upperdir\dir2,type=link,ttl=1800,etime=779521798,interlink=no,path_consumed=31,expired=yes
\server2.ad.example.com\dir2 (target hint)

Therefore I guess that someting in the cifs kernel module works different in the newer kernel

You must log in to answer this question.