Сбой DFS-Link при монтировании DFS-ресурса через CIFS

Я пытаюсь смонтировать DFS-шару через cifs. Шара выглядит следующим образом:

\\mydomain.local\Files — это DFS-шара.
Я могу успешно смонтировать эту шару следующим образом:

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

После этого я могу перемещаться по каталогам в ~/fileserver, как и ожидалось.

# ls ~/fileserver
folder1 folder2

Однако, когда я пытаюсь перейти в folder1, я получаю ошибку:

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

Проходит секунда или две перед появлением ошибки.
Я думаю, это потому, что folder1 является DFS-ссылкой на другой файловый сервер, он ссылается на: \\fileserver2.mydomain.local\Fileshare$\somedirectory\folder1

Теперь я посмотрел на dmesg прямо после этого:

# 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

Я считаю, что проблема в “cannot query dirs between root and final path”, так как у меня нет разрешения напрямую монтировать ни шару Fileshare$, ни somedirectory, а только folder1. Я также мог бы монтировать эту шару непосредственно на fileserver2, но так как в DFS есть много ссылок на другой сервер, мне пришлось бы монтировать много чего.

Я в счастливом положении, так как могу попробовать монтировать с помощью привилегированной учетной записи, которая может получить доступ как к Fileshare$, так и к somedirectory, и когда я монтирую с таким пользователем вместо “myuser”, я могу получить доступ к folder1:

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

Но я не могу использовать эту привилегированную учетную запись для повседневной работы – также, я не в той позиции, чтобы изменить разрешения на DFS-шаре или файловом сервере.

Интересная часть в том, что smbclient может выполнять перемещение с myuser:

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

Я попробовал множество различных параметров для монтирования (в основном от отчаяния):

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

У кого-нибудь есть идеи, что еще я мог бы попробовать?

Кстати, DFS-шара находится на сервере Windows.

Я наблюдаю аналогичный эффект, когда пытаюсь подключиться к шаре, путь к которой отличается от основной шары, распределяемой DFS.

Это заставляет меня предположить, что “target hint” не будет распознан ядром при монтировании.

Пример: Шара, предоставляемая как \\ad.example.com\dir1, указывает на реальную шару на другом сервере \\server1.ad.example.com\dir1.

Команда монтирования

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

приводит к доступному содержимому в /mnt

С другой стороны, существует шара \\ad.example.com\upperdir с подкаталогом “dir2”, которая также указывает на реальную шару на другом сервере \\server2.ad.example.com\dir2

Если теперь использовать команду

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

я могу видеть подкаталог “dir2” в “/mnt”, но при попытке получить к нему доступ получаю ту же ошибку, что и jaffex (такой файл или каталог не существует).

Это происходит только на моей машине с ubuntu 20.04 с ядром версии 5.4.0. Такая же комбинация на ubuntu 18.04 с ядром 4.15.0 даже позволяет второй части работать. Заглянув в “/proc/fs/cifs/dfscache”, я вижу, что сервер может предоставить правильную шару для использования:

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)

Поэтому я предполагаю, что что-то в модуле ядра cifs работает иначе в новом ядре