Сетевой smb-доступ к общей папке Windows 10: permission denied (error 13)

[CyraxZ]

2017 год, http://forum.oszone.net/showthread.php?t=328349&page=all

1) Есть хост-машина Windows 10 с общей папкой share. Её сетевой путь: \\HOSTCOMPNAME\share.
Windows-пользователю user предоставлены полные права на эту папку (пароль пользователю не задан). В "Мой компьютер - Сеть" папка видна.

2) На гостевой машине Debian, развёрнутой с помощью Virtual Box, установлен пакет утилит Samba:
apt-get install cifs-utils samba smbclient winbind

3) В гостевой системе выполняется монтирование папки share, обеспечивающей доступ к сетевой Windows-папке share (расположенной на хост-машине) без пароля:
mount -t cifs -o username=user,password=,iocharset=utf8,uid=root,gid=root,dir_mode=0777,file_mode=0777,noserverino '\\HOSTCOMPNAME\share' /home/user/share


Задача была решена за счёт следующих настроек Windows 10 (доступ без пароля):

1) В сетевых настройках ВКЛЮЧЕН общий доступ с парольной защитой:
Параметры - Сеть и Интернет - Ethernet - Изменение расширенных параметров общего доступа - Все сети - Включить общий доступ с парольной защитой

2) Выполнить - "gpedit.msc" - "Конфигурация компьютера - Конфигурация Windows - Параметры безопасности - Локальные политики - Параметры безопасности":
ОТКЛЮЧЕНА политика "Учетные записи: разрешить использование пустых паролей только при консольном входе" (LimitBlankPasswordUse)

3) Владелец папки share: Администраторы

4) В свойствах папки добавлена группа "Все":
а) Доступ - Расширенная настройка - Разрешения - Группы или пользователи = Все (полный доступ), user (полный доступ), Администраторы (полный доступ)
б) Безопасность - Изменить = Все (полный доступ), СИСТЕМА (полный доступ), user (полный доступ) и Администраторы (полный доступ)

С тех пор и по текущий момент этот компьютер (Windows 10 с последними обновлениями) нормально работает с указанными настройками (специально перепроверил), доступ корректно осуществляется без пароля.

Одновременно с этим, на новом компьютере установил ту же самую ОС Windows 10 (с последними обновлениями), Virtual Box той же самой версии, записал на флешку ту же самую виртуальную машину (которая корректно работает на старом компьютере), подключил её в Virtual Box, выполнил те же самые (вышеуказанные) настройки Windows 10 и... mount error (13): permission denied. В логах "/var/log/kern.log": CIFS VFS: cifs_mount failed w/return code = -13 и CIFS: Status code returned 0x0000006d STATUS LOGON FAILURE. Сто раз перепроверил эти настройки на старом компьютере и на новом: на старом всё работает, на новом - permission denied.

Что ещё проверено:
1) Пинг к компьютеру хост-машины выполняется корректно: ping -nq -c3 \\HOSTCOMPNAME
2) Если в гостевой машине монтировать папку с указанием пароля, то папка монтируется успешно (причём при любых значениях настроек 1 и 2):
mount -t cifs -o username=user,password=PASS,iocharset=utf8,uid=root,gid=root,dir_mode=0777,file_mode=0777,noserverin o '\\HOSTCOMPNAME\share' /home/user/share
3) Если владельцем папки сделать пользователя user, то проблема сохраняется

Выводы:
1) проблема не связана с флешкой (т.к. с указанием пароля доступ предоставляется без ошибок).
2) проблема не на стороне гостевой машины, а на стороне хост-машины (Windows 10).

Получается, что в Windows 10 есть ещё какие-то настройки, препятствующие предоставлению доступа без пароля ?

[Avatar-Lion]

С некоторых пор нужно еще один параметр в реестре подправить, чтобы хост пускал к себе без пароля:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"AllowInsecureGuestAuth"=dword:00000001

[Petya V4sechkin]

Avatar-Lion, этот параметр для клиента, а у него там Debian.

на новом компьютере установил ту же самую ОС Windows 10
Сравните разделы на старом и новом:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

[CyraxZ]

Сравните разделы на старом и новом:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters »

Различия по этим двум веткам прикрепил во вложении.
Слева - на старом компьютере (где всё работает), справа - на новом компьютере (permission denied).

[CyraxZ]

С некоторых пор нужно еще один параметр в реестре подправить, чтобы хост пускал к себе без пароля:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"AllowInsecureGuestAuth"=dword:00000001 »
Добавил параметр AllowInsecureGuestAuth = 1 (отсутствовал и на старом, и на новом), перезагрузил Windows 10 - то же самое (permission denied).
Т.е. это для SMB-клиента, как указал Petya V4sechkin.

[CyraxZ]

1) Из виртуальной машины, работающей на новом компьютере, успешно примонтировал общую папку старого компьютера. Без пароля (указал имя пользователя старого компьютера). Вывод: проблема не в виртуальной машине, а в Windows 10 на новом компьютере.

2) Из Debian (гостевая машина) выполнил команду (команда не связана с конкретной общей папкой):
smbclient -L //WINCOMPNAME U user%
Результат: NT_STATUS_LOGON_FAILURE

Если выполнить эту же команду к старому компьютеру, получаем список общих папок, доступных пользователю.
Вывод: проблема не в свойствах общей папки, а в общих настройках Windows 10 на новом компьютере.


3) Сейчас на новом компьютере имя пользователя совпадает с именем компьютера и с именем пользователя в гостевой машине (Debian). Может ли этот факт быть причиной permission denied ? В то же время, с паролем доступ имеется.

> I’m running smbclient on Ubuntu, trying to connect to a Windows box, and I’m getting «session setup failed: NT_STATUS_LOGON_FAILURE».
this error means that the user is wrong, it may be that the user does not exist, it may also be that the password is wrong, or the user exists in one of the users of samba and the system.[/QUOTE]


Попробовал изменить имя текущего пользователя на новом компьютере, перезагрузился. Далее выполняю команду из гостевой машины (Debian):
smbclient -L //WINCOMPNAME -U newuser%
Результат: NT_STATUS_LOGON_FAILURE

smbclient -L //WINCOMPNAME -U newuser%pass
Результат: NT_STATUS_LOGON_FAILURE

smbclient -L //WINCOMPNAME -U user%pass (указал изначальное имя пользователя + пароль)
Результат: отображён список доступных папок на новом компьютере (в т.ч. share)

Вывод: в Windows изменение имени пользователя меняет только отображаемое имя, а внутреннее имя (для удалённого доступа) остаётся прежним.

[Petya V4sechkin]

в Windows изменение имени пользователя меняет только отображаемое имя
Запустите lusrmgr.msc

P.S. Дополнительно сравните ветки
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

[CyraxZ]

Сейчас на новом компьютере имя пользователя совпадает с именем компьютера и с именем пользователя в гостевой машине (Debian). Может ли этот факт быть причиной permission denied ? В то же время, с паролем доступ имеется.
Запустите lusrmgr.msc

В lusrmgr.msc создал нового пользователя (с группами Пользователь и Администратор), имя которого отличается от имени хост-компьютера и имени пользователя в гостевой системе (Debian). Зашёл под ним, затем проверил монтирование. Результат тот же самый: без пароля - permission denied, с паролем монтируется нормально (в команде mount указал имя нового пользователя).

Т.е. проблема не в имени пользователя. Остаётся только реестр ?
Выше я привёл различия в двух указанных вами ветках реестра. Различающихся "говорящих" параметров нет (по крайней мере, для меня). Что мне сечас делать с этими ветками ? Попробовать заменить их ветками от старого компьютера ? Не "сломается" ли Windows ? Или по одному параметру вручную корректировать, перезагружаться и проверять ?

Можно ли ещё каким-нибудь образом выявить причины недопуска без пароля ? Какие-нибудь более подробные логи Windows 10 или какой-нибудь отладочный режим ?...

[CyraxZ]

P.S. Дополнительно сравните ветки
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
У этой ветки различий нет:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ConsentPromptBehaviorAdmin"=dword:00000005
"ConsentPromptBehaviorUser"=dword:00000003
"DSCAutomationHostEnabled"=dword:00000002
"EnableCursorSuppression"=dword:00000001
"EnableFullTrustStartupTasks"=dword:00000002
"EnableInstallerDetection"=dword:00000001
"EnableLUA"=dword:00000001
"EnableSecureUIAPaths"=dword:00000001
"EnableUIADesktopToggle"=dword:00000000
"EnableUwpStartupTasks"=dword:00000002
"EnableVirtualization"=dword:00000001
"PromptOnSecureDesktop"=dword:00000001
"SupportFullTrustStartupTasks"=dword:00000001
"SupportUwpStartupTasks"=dword:00000001
"ValidateAdminCodeSignatures"=dword:00000000
"dontdisplaylastusername"=dword:00000000
"legalnoticecaption"=""
"legalnoticetext"=""
"scforceoption"=dword:00000000
"shutdownwithoutlogon"=dword:00000001
"undockwithoutlogon"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\UIPI]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\UIPI\Clipboard]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\UIPI\Clipboard\Exceptio nFormats]
"CF_BITMAP"=dword:00000002
"CF_DIB"=dword:00000008
"CF_DIBV5"=dword:00000011
"CF_OEMTEXT"=dword:00000007
"CF_PALETTE"=dword:00000009
"CF_TEXT"=dword:00000001
"CF_UNICODETEXT"=dword:0000000d

Различия имеются только у тех двух веток (см. выше).