Назад | Перейти на главную страницу

cifs mount поочередно отправляет неправильный пароль

укороченная версия:

журналы NETAPP показывают это от нашего клиента (debian 8.7, cifs=2:6.4-1) в качестве альтернативы вход в систему не выполняется. Т.е. это похоже на то, что один раз он отправляет хороший пароль, затем какой-то неправильный пароль, затем снова хороший, затем снова неправильный и т. д. (см. журналы в конце подробного описания).

Может ли это быть связано с тем, что на нашу долю разрешаются 2 IP?

длинная версия:

Наши ИТ-специалисты установили общий ресурс CIFS netapp, который использует аутентификацию AD passwd (скажем, //storage.example.domain/share/sub/directory.

Чтобы смонтировать его на машине debian 8, мы должны использовать nodfs вариант, чтобы он распознал общий ресурс в подкаталоге, это обходной путь, который я нашел Вот

так что варианты монтирования в /etc/fstab такие:

//storage.example.domain/share/sub/directory /local/path cifs auto,username=user,password=pass,domain=EXAMPLE.DOMAIN,uid=localUserId,gid=localUserGid,nodfs,rw

мы должны установить uid и gid локальной группе / пользователю, потому что мы хотим предоставить пользователям Linux (которые не совпадают с пользователями AD) групповой доступ RW к ресурсу (следует ли делать это по-другому?).

Теперь общий ресурс работает на 2 машинах (так storage.example.domain разрешается до 2 ips, например 10.0.0.x и 10.0.0.y).

При монтировании общего ресурса с использованием полного доменного имени, как в нашем /etc/fstab config уже возникла проблема:

если циклический DNS переключает IP во время монтирования, это вызовет no such file or directory вопрос. Я заметил, что cifs сначала разрешает IP, затем устанавливает его в качестве дополнительной опции монтирования, а затем пытается смонтировать его, снова используя полное доменное имя. На этом этапе, если rr-dns переключился, он выйдет из строя, потому что он пытается, например, получить доступ с опцией -o addr=10.0.0.x но fqdn storage.example.domain указывает на addr=10.0.0.y.

Поэтому на практике, чтобы установить его, мы должны надежда что DNS не переключается во время монтирования. Если этого не происходит, он работает, и общий ресурс монтируется.

Теперь новая проблема заключается в том, что когда мы пытаемся записать большие файлы в общую папку (> 1 ГБ), точка монтирования вылетает со следующими ошибками:

root@client.example.domain kernel~# cat /var/log/syslog    
[...]
Apr 13 06:39:42 client.example.domain kernel: [85341.844209] Status code returned 0xc000006d NT_STATUS_LOGON_FAILURE
Apr 13 06:39:42 client.example.domain kernel: [85341.844219] CIFS VFS: Send error in SessSetup = -13
Apr 13 06:39:42 client.example.domain kernel: [85341.844728] CIFS VFS: cifs_mount failed w/return code = -13
Apr 13 07:09:42 client.example.domain kernel: [87140.888509] Status code returned 0xc000006d NT_STATUS_LOGON_FAILURE
Apr 13 07:09:42 client.example.domain kernel: [87140.888515] CIFS VFS: Send error in SessSetup = -13
Apr 13 07:09:42 client.example.domain kernel: [87140.888833] CIFS VFS: cifs_mount failed w/return code = -13
Apr 13 07:17:52 client.example.domain kernel: [87629.897198] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:52 client.example.domain kernel: [87629.897583] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:52 client.example.domain kernel: [87629.897887] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:52 client.example.domain kernel: [87629.898176] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:52 client.example.domain kernel: [87629.898881] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:52 client.example.domain kernel: [87629.899642] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:52 client.example.domain kernel: [87629.899945] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:52 client.example.domain kernel: [87629.900294] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:52 client.example.domain kernel: [87629.901437] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:52 client.example.domain kernel: [87629.901962] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:57 client.example.domain kernel: [87634.897772] cifs_vfs_err: 19718 callbacks suppressed
Apr 13 07:17:57 client.example.domain kernel: [87634.897776] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:57 client.example.domain kernel: [87634.898019] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:57 client.example.domain kernel: [87634.898201] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:57 client.example.domain kernel: [87634.898414] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:57 client.example.domain kernel: [87634.898597] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:57 client.example.domain kernel: [87634.898762] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:57 client.example.domain kernel: [87634.898929] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:57 client.example.domain kernel: [87634.899115] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:57 client.example.domain kernel: [87634.899309] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:17:57 client.example.domain kernel: [87634.899474] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:18:03 client.example.domain kernel: [87641.528425] cifs_vfs_err: 15111 callbacks suppressed
Apr 13 07:18:03 client.example.domain kernel: [87641.528428] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:18:03 client.example.domain kernel: [87641.529016] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:18:03 client.example.domain kernel: [87641.529310] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:18:03 client.example.domain kernel: [87641.529591] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:18:03 client.example.domain kernel: [87641.529926] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:18:03 client.example.domain kernel: [87641.530197] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:18:03 client.example.domain kernel: [87641.530469] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:18:03 client.example.domain kernel: [87641.530741] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:18:03 client.example.domain kernel: [87641.531038] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:18:03 client.example.domain kernel: [87641.531295] CIFS VFS: SMB signature verification returned error = -13
Apr 13 07:18:09 client.example.domain kernel: [87646.632693] cifs_vfs_err: 128 callbacks suppressed
[...]

журналы на стороне netapp:

10:53:00               Login successful
10:51:02               Login failed (user name correct but the password is wrong)
10:50:31               Login successful
10:50:12               Login failed (user name correct but the password is wrong)
10:49:34               Login successful
10:48:15               Login failed (user name correct but the password is wrong)

Я действительно не могу понять, как это решить, и поскольку у меня нет доступа к AD или NetApp, это действительно черный ящик. Есть ли у кого-нибудь представление о том, что я могу сделать или что я могу попросить сделать наш ИТ?

В моем случае мой Ubuntu использует SMB1 по умолчанию, но мой Netapp работает с SMB2. Я добавил в fstab: vers = 2.0 (или 2.1)

Я наконец нашел проблему.

Дело в том, что в конфигурации ontap было следующее:option cifs.smb2.signing.required on. Нам пришлось превратить это в option cifs.smb2.signing.required off.

Как мы обнаружили на официальная документация ontap.