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

Задача была решена за счёт следующих настроек 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,noserverino '\\HOSTCOMPNAME\share' /home/user/share
3) Если владельцем папки сделать пользователя user, то проблема сохраняется

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

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

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

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

Сравните разделы на старом и новом:

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

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

Добавил параметр AllowInsecureGuestAuth = 1 (отсутствовал и на старом, и на новом), перезагрузил Windows 10 - то же самое (permission denied).
Т.е. это для SMB-клиента, как указал Petya V4sechkin.

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

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

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


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


Попробовал изменить имя текущего пользователя на новом компьютере, перезагрузился. Далее выполняю команду из гостевой машины (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 изменение имени пользователя меняет только отображаемое имя, а внутреннее имя (для удалённого доступа) остаётся прежним.

Запустите lusrmgr.msc

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

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

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

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

У этой ветки различий нет:

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