Samba ошибка подключения

Ошибки сетевого доступа в Windows — вещь довольно неприятная, тем более что не все умеют их правильно диагностировать и исправлять. При том, что интернет кишит различными способами самой разной степени сомнительности. Поэтому мы решили подробно разобрать одну из типовых ситуаций, показав как процесс диагностики, так и различные способы решения проблемы, каждое из которых имеет свои особенности, в частности влияние на безопасность. Такой подход позволит не только выяснить причины ошибки и устранить ее, но и поможет подойти к этому вопросу осознанно, полностью представляя последствия своих действий.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

С ситуацией, когда компьютер под ОС Windows не хочет подключаться или перестает подключаться к общим ресурсам на сервере Samba под управлением Linux встретиться можно довольно часто и тому есть объективные причины, которые мы рассмотрим ниже, ну а пока посмотрим на ее внешние симптомы. Система неожиданно сообщает, что она не может получить доступ к указанному ресурсу и выдает абсолютно неинформативную ошибку:

Код ошибки: 0x80004005 
Неопознанная ошибка

Если попробовать подключиться в консоли, например, командой:

net view \192.168.233.182

Где 192.168.233.182 — адрес искомого сервера, то получим немного другую ошибку:

Системная ошибка 53.
Не найден сетевой путь.

При этом указанный узел нормально пингуется, а проверка доступности 445 порта говорит, что все нормально:

После этого обычно начинается сетование на кривизну какого-либо из решений (в зависимости от личных предпочтений) и поиск решения в интернете, где можно найти как условно рабочие, так и полную дичь, вроде включения SMB1 и бездумного изменения различных политик и ключей реестра.

Но не будем спешить, вы же не глотаете все подряд из домашней аптечки только почувствовав недомогание? Так и здесь, поэтому будем разбираться.

Но сперва поясним ситуацию по протоколу SMB1:

Протокол SMB1 устарел и небезопасен, в настоящее время отключен на всех современных системах.

Кроме того, даже если вы включите его поддержку, то начиная с Windows 1709 она автоматически отключится после 15 дней неиспользования. В общем: включать SMB1 не нужно, разве что только вам действительно нужна поддержка устаревших клиентов.

В современных версиях Samba протокол SMB1 также отключен и минимальной поддерживаемой версией является SMB2_02, а максимальной SMB3. Это параметры по умолчанию и проверить их можно командами:

testparm --parameter-name="min protocol"
testparm --parameter-name="max protocol"

Настройки по умолчанию достаточно актуальны, и мы не советуем отдельно задавать версии протоколов без особой на то нужды. SMB2_02 — обозначает младшую версию протокола SMB2, а SMB3 указывает на старшую доступную версию, таким образом поддерживаются все системы начиная с Windows Vista и Server 2008. Причиной ошибки SMB1 быть не может.

Поэтому не занимаемся ерундой, а ищем истинную причину, в этом нам поможет Журнал событий. Раскрываем последовательно Журналы приложений и служб — Microsoft — Windows — SMBClient и в журнале Security находим ошибку 31017:

Небезопасный гостевой вход отклонен.Рекомендации.
Это событие указывает на попытку сервера разрешить вход пользователя как непроверенного гостя, которая была отклонена клиентом. 
Для гостевого входа не поддерживаются стандартные функции обеспечения безопасности, например подписывание и шифрование. 
Вследствие этого гостевой вход уязвим для атак "злоумышленник в середине", которые могут привести к попаданию конфиденциальных данных в сеть. 
По умолчанию небезопасный гостевой вход отключен в Windows. Корпорация Майкрософт не рекомендует включать его.

После чего все становится на свои места. Нет никаких чудес, просто политики безопасности Windwos не позволяют подключаться к серверу с анонимным гостевым доступом. Кстати, это относится не только к Samba.

Теперь, когда есть понимание происходящего мы можем выбрать одно из двух решений указанной проблемы.

Решение №1. Отключаем гостевой доступ на сервере Samba

С точки зрения безопасности это наиболее правильное решение, которое позволит получать доступ к общим ресурсам не снижая уровень безопасности сети. Для этого внесем некоторые изменения в конфигурационный файл Samba, обычно он располагается в /etc/samba/smb.conf. Прежде всего найдем и приведем к следующему виду директиву:

map to guest = never

А в настройках каждого общего ресурса укажем:

guest ok = no

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

Настройка файлового сервера Samba на платформе Debian / Ubuntu

Сохраняем все изменения и проверяем конфигурацию на ошибки:

testparm

Затем перезапускаем службу:

systemctl restart smbd

После чего повторно пробуем подключиться и сразу видим окно для ввода учетных данных:

Проблема решена, ресурсы файлового сервера Samba снова доступны.

Решение №2. Разрешаем небезопасный гостевой вход в Windows

Если Решение №1 вас по каким-либо причинам не устраивает, и вы осознанно хотите понизить уровень безопасности вашей сети, то можно пойти другим путем и разрешить небезопасный гостевой вход.

Запустим редактор групповой политики (gpedit.msc) и перейдем в Конфигурация компьютера — Административные шаблоны — Сеть — Рабочая станция Lanman и переводим политику Включить небезопасные гостевые входы в положение Включено.

После чего вам потребуется перезапустить службу Рабочая станция или перезагрузить компьютер.

Альтернативой этому способу будет внесение изменений через реестр:

reg add "HKLMSYSTEMCurrentControlSetServicesLanmanWorkstationParameters" /v AllowInsecureGuestAuth /t REG_DWORD /d 1

Затем перезапустим службу:

net stop LanmanWorkstation && net start LanmanWorkstation

После чего можем продолжать привычно использовать общие сетевые ресурсы с гостевой моделью доступа.

Какой вывод можно сделать после прочтения данного материала? Прежде всего понять, что любые сетевые ошибки имеют под собой вполне определенную причину, а не являются воздействием некой неведомой силы. И эти причины имеют свойство отображаться в журналах и логах.

Решений таких проблем также может быть несколько, каждое из которых может иметь свои достоинства и недостатки. Поэтому не нужно хватать первый попавшийся рецепт из интернета, а следует разобраться в причинах и выбрать из доступных вариантов тот, который будет вас наиболее устраивать.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Время на прочтение
13 мин

Количество просмотров 118K

Эта статья по сути будет подборкой «Best practiсe» для системных администраторов Samba. Основой статьи является глава Troubleshooting Techniques из книги Sam’s Teach Yourself Samba in 24 Hours. Мы постараемся рассмотреть наиболее распространенные ошибки при настройке Samba.

Согласитесь, ужасно поменять двигатель в машине, а потом выяснить, что не ехала она из-за отсутствия бензина! Может, это и не лучшая метафора, но многие системные администраторы тратят время зря, не проверив в первую очередь самые очевидные вещи. Посмотрите, как примерно должен выстраиваться процесс поиска и решения проблем с Samba:

Проблемы, представленные на нижних уровнях этой «пирамиды», являются «фундаментом» для более высоких уровней. Не удивительно, что Windows-клиент не может получить доступ к файловому северу на Samba, если сервер отключен от сети. Конечно, не стоит воспринимать этот рисунок буквально, как руководство к действию (скажем, лог-файлы можно посмотреть всегда), но начинать стоит все-таки с проблем нижних уровней. Чем выше мы поднимаемся, тем больше углубляемся в принципы работы Samba.
В поисках решения проблемы с Samba стоит в первую очередь обратиться к следующим ресурсам:
•HOWTO, опубликованные на сайте;
•тематические сайты и форумы, например: http://samba-doc.ru/, http://citforum.ru/operating_systems/linux/samba/;
•разделы документации по Samba для того или иного дистрибутива (например, http://help.ubuntu.ru/wiki/samba, http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-samba.html или http://wiki.russianfedora.ru/index.php?title=Samba);
•http://stackoverflow.com/ — не забывайте про этот сайт, если у вас есть конкретный вопрос или проблема;
•вспомогательные утилиты, входящие в состав Samba, а также различные программы-анализаторы трафика (например, Wireshark).
Мы в первую очередь рассмотрим самостоятельное решение возникающих проблем, но не стоит забывать про возможную помощь сообщества. Это может серьезно сэкономить вам время и силы.

Описание тестовой среды
Для начала — несколько слов о тестовой среде. Условия следующие:
•Samba-сервер называется TROUBLE и имеет IP-адрес 192.168.7.75 и маску 255.255.255.0.
•smbd и nmbd запускаются как демоны.
•Windows-клиент называется win-client.
•Windows-клиент использует адрес 192.168.7.135 с сетевой маской 255.255.255.0.
•И win-client, и TROUBLE находятся в одной подсети, так что широковещательный запрос дойдет с одного хоста на другой.
•И win-client, и TROUBLE являются членами рабочей группы LAB.
•Samba-сервер использует следуюший smb.conf:

[global] netbios name = TROUBLE 
workgroup = LAB security = user encrypt passwords = yes 
[public] path = /tmp 
read only = no 

УРОВЕНЬ 1

Работоспособность сетевого соединения и файла конфигурации

Основание нашей «пирамиды» составляют три основных проблемы:
•корректно работающее TCP/IP подключение;
•соответствие маски и широковещательных адресов на серверах и клиентах;
•работоспособность файла smb.conf.

TCP/IP
Для проверки TCP/IP в первую очередь используется команда ping. Если описать протокол ICMP очень упрощенно, то хост отправляет запрос на сервер и спрашивает «Ты жив?». Если сервер не отвечает, хост приходит к выводу, что тот не подключен к сети и, следовательно, недоступен.

$ ping win-client
PING win-client (192.168.7.135) from 192.168.1.74 : 56(84) bytes of data. 
64 bytes from win-client (192.168.7.135): icmp_seq=0 ttl=255 time=2.138 msec 
64 bytes from win-client (192.168.7.135): icmp_seq=1 ttl=255 time=2.181 msec 
64 bytes from win-client (192.168.7.135): icmp_seq=2 ttl=255 time=2.263 msec 
--- ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/mdev = 2.138/2.194/2.263/0.051 ms 

Также очень важным является правильное функционирование DNS. Если не удастся разрешить имя, появится сообщение вроде этого:

$ ping win-client
ping: unknown host win-client

Если такое происходит, первое, что стоит сделать — это повторить команду ping, но используя уже не имя, а адрес:

$ ping 192.168.7.135

Если команда выполнится успешно, то стоит обратить внимание на конфигурацию DNS. Наиболее распространенные причины ошибки:
•неверное содержание файла конфигурации DNS /etc/resolv.conf;
•на сервере DNS нет записи, связанной с win-client;
•сервер DNS недоступен в данный момент.
Если же ping по IP-адресу успешно не выполняется, то стоит проверить работоспособность сетевого оборудования на сервере, клиенте и между ними.

Широковещательный адрес на сервере и клиенте
Возможно, ping выполнится и успешно, но при этом сетевая маска (netmask) и широковещательный адрес (broadcast address) будут сконфигурированы неверно.
В NetBIOS крайне важно для правильного разрешения имени и поиска машин в сетевом окружении, чтобы сервер и клиент находились в одной подсети, т.е. использовали одну маску подсети и широковещательный адрес.
В нашем случае сетевая маска должна быть 255.255.255.0, а широковещательный адрес — 192.168.7.255.
Если вы используете Linux, то можно проверить, какие используются широковещательный адрес и маска, при помощи команды ifconfig с именем интерфейса в качестве аргумента:

$ /sbin/ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:04:5A:0C:1C:19 
inet addr:192.168.7.75 Bcast:192.168.255.255 Mask:255.255.255.0 
inet6 addr: fe80::204:5aff:fe0c:1c19/10 Scope:Link 
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 
RX packets:68006 errors:0 dropped:0 overruns:0 frame:0 
TX packets:100783 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:100 
RX bytes:12186135 (11.6 Mb) TX bytes:121642120 (116.0 Mb) 
Interrupt:3 Base address:0x100 
1

Если в выводе этой команды вы увидите, что широковещательный адрес или сетевая маска заданы неверно, следует зайти под учетной записью root и установить верные значения, используя команду ifconfig:

root# ifconfig eth0 192.168.7.75 netmask 255.255.255.0 broadcast 192.168.7.255

В Windows аналогичную информацию можно получить информацию, выполнив команду ipconfig /all.

Проверка корректности файла smb.conf
Так как Samba использует огромное количество параметров из файла smb.conf, разработчики создали утилиту командной строки, которая проверяет синтаксис этого файла. Утилита называется testparm, она очень полезна при поиске ошибок в конфигурационном файле.
Можно использовать утилиту testparm с параметром -s для анализа конкретного конфигурационного файла. Эта опция очень хорошо подходит для проверки файла конфигурации перед его «боевым» использованием.

$ testparm -s /usr/local/samba/lib/smb.conf.new 
Load smb config files from /usr/local/samba/lib/smb.conf.new 
Processing section “[public]” 
Loaded services file OK. 
# Global parameters 
[global] 
coding system = 
client code page = 850 
code page directory = /usr/local/samba/lib/codepages 
<...остальной вывод опущен...>

После анализа заданного конфигурационного файла testparm выводит все значения файла smb.conf, включая значения по умолчанию. Это помогает убедиться, что используются ожидаемые значения параметров конфигурации smbd и nmbd.
Стоит отметить, что значения по умолчанию меняются от версии к версии, так что необходимо использовать версию Samba, соответствующую версии testparm.

УРОВЕНЬ 2

Серверное и клиентское ПО

Второй уровень подразумевает проверку конфигурации клиентского и серверного ПО. Наша цель — убедиться, что и клиент, и сервер корректно отвечают на запросы NetBIOS и CIFS. Пока мы рассматриваем изолированно каждый из хостов. (На третьем уровне мы уже начнем рассматривать их взаимодействие.)

smbd
В первую очередь, smbd должен быть запущен. Проверить это можно, используя команду ps. Аргументы этой команды могут отличаться в зависимости от версии Linux.

$ ps -ef | grep smbd
 root 28592 1 0 12:37 ? 00:00:00 /usr/local/samba/bin/smbd -D

Убедившись, что smbd запущен (или, при необходимости, запустив его), используем утилиту smbclient для проверки работоспособности сервера. Параметр -L используется для вывода списка ресурсов сервера. Ключ -N используется для анонимного подключения к серверу, чтобы не создавать лишних проблем с авторизацией. Все эти действия должны выполняться локально на Samba-сервере.

smbclient -L TROUBLE -N added interface ip=192.168.7.75 bcast=192.168.1.255 nmask=255.255.255.0 Anonymous login successful Domain=[LAB] OS=[Unix] Server=[Samba 2.2.2] 
Sharename Type --------- ---- public Disk IPC$ IPC 
Comment ------- 
IPC Service (Samba 2.2.2) 
smbclient -L TROUBLE -N added interface ip=192.168.7.75 bcast=192.168.1.255 nmask=255.255.255.0 Anonymous login successful Domain=[LAB] OS=[Unix] Server=[Samba 2.2.2] 
Sharename Type --------- ---- public Disk IPC$ IPC 
Comment ------- 
IPC Service (Samba 2.2.2) 
ADMIN$ 
Server --------- TROUBLE 
Workgroup --------- LAB 
Disk 
IPC Service (Samba 2.2.2) 
Comment ------- Samba 2.2.2 
Master ------- TROUBLE 

Существуют две распространенные ошибки, которые могут возникнуть при выполнении этой проверки.
Первая ошибка выглядит следующим образом:

error connecting to 192.168.7.75:139 (Connection refused) Connection to <server> failed

Она возникает, если smbd не запущен или не может подключиться к порту 139. Причиной этому могут быть ранее установленные и некорректно удаленные компоненты Samba. Прежде всего следует убедиться, что smbd стартует как демон и не завершается тут же с ошибкой. Особенность в том, что nmbd не выводит ошибки в консольное окно, так что следует посмотреть последние несколько строк log-файла. Позже мы рассмотрим анализ логов более подробно.
Вторая часто встречающаяся ошибка выглядит так:

session request to <server> failed (Not listening for calling name)

Можно подумать, что причиной этой ошибки является неверное NetBIOS-имя, но это не так. Эта ошибка не может быть вызвана «битой» установкой nmbd, nmbd в данном случае даже не обязательно должен быть запущен.
Причиной возникновения этой ошибки при локальном подключении чаще всего являются неверно сконфигурированные параметры hosts allow или hosts deny в файле smb.conf. Сервер разрывает создающуюся NetBIOS-сессию.
Если нам удалось увидеть список общих ресурсов, мы можем проверить возможность Samba авторизовать пользователей. В этом тесте аккаунт с именем пользователя user1 и паролем secret подключается к общему ресурсу [public].

$ smbclient //TROUBLE/public -U user1%secret added interface ip=192.168.7.75 bcast=192.168.1.255 nmask=255.255.255.0 Domain=[LAB] OS=[Unix] Server=[Samba 2.2.2] smb: > 

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

session setup failed: ERRSRV - ERRbadpw (Bad password - name/password pair in a Tree Connect or Session Setup are invalid.) 

Причин этой ошибки может быть много. Это может быть неверное имя или пароль, или отсутствующая запись smbpasswd для пользователя, если задан параметр encrypt password = yes, или недействительная учетная запись guest, если разрешен доступ без аутентификации.
Если пользователь корректно авторизовался, но не смог получить доступ к запрошенной службе, smbclient выведет следующее сообщение:

tree connect failed: ERRDOS - ERRnosuchshare (You specified an invalid share name) 

Это может быть вызвано неверно написанным именем службы, настройками доступа к общему ресурсу или неверным выражением path в описании общего ресурса в файле smb.conf.

nmbd
Чтобы проверить, запущен ли nmbd, мы снова используем команду ps.

$ ps -ef | grep nmbd 
root 29054 1 0 15:53 ? 00:00:00 /usr/local/samba/bin/bin/nmbd -D 

Если ps покажет, что nmbd не запущен, стоит зайти под учетной записью root и запустить его (/usr/local/samba/bin/nmbd -D).
Для теста мы будем использовать утилиту Samba — nmblookup. У каждого Samba-сервера есть особое имя, _Samba_, на которое они откликаются всегда. Послав запрос по этому имени, мы можем проверить работоспособность nmbd. Ключ -U используется для того, чтобы отправить запрос на конкретный адрес.

$ ./nmblookup -U 127.0.0.1 __Samba__ querying __Samba__ on 127.0.0.1 192.168.7.75 __Samba__<00>

Если nmbd при этом не запущен, результатом будет ошибка:

name_query failed to find name __Samba__

Также причиной ошибки может быть тот факт, что loopback-интерфейс не включен в smb.conf при включенном параметре bind interfaces only = yes.
После этого мы проверим, может ли nmbd зарегистрировать имя TROUBLE.

$ nmblookup -U 127.0.0.1 TROUBLE querying TROUBLE on 127.0.0.1 192.168.7.75 TROUBLE<00>

Сообщения об ошибках, например, “name query failed”, скорее всего, вызваны неудачным запросом к имени _Samba_. Другой причиной может быть то, что сервер не может зарегистрировать имя NetBIOS. В этом случае стоит найти сервер, которому принадлежит данное имя, отправив широковещательный запрос.

$ nmblookup -B 192.168.1.255 TROUBLE querying TROUBLE on 192.168.1.255 192.168.1.98 TROUBLE<00> ошибка

Например, в данном случае это имя принадлежит сторонней машине, а не нашему Samba-серверу. Очевидно, решением данной проблемы является переименование этой машины или сервера.

NetBIOS-интерфейс Windows

Утилита, использующаяся в Windows для NetBIOS-запросов — nbtstat.exe — имеет еще несколько опций, которых нет в nmblookup. Одна из них (-n) позволяет «спросить» у NetBIOS-интерфейса, какие имена он успешно зарегистрировал:

C:WINDOWS> nbtstat -n 
Node IpAddress: [192.168.7.135] Scope Id: [] NetBIOS Local Name Table 
Name Type Status --------------------------------------------- 
WIN-CLIENT LAB WIN-CLIENT 
<00> UNIQUE <00> GROUP <03> UNIQUE 
Registered Registered Registered 

Если компонент “Client for Microsoft Networks” не был установлен, nbtstat.exe сообщит следующее:

Failed to access NBT driver 1

Более тонкая ошибка возникает, когда Windows-клиент сообщает что он зарегистрировал имя рабочей группы, хотя это должно быть уникальное имя рабочей станции.

Name Type Status --------------------------------------------- LAB <00> GROUP Registered

Часто причиной этого является наличие машины с таким же NetBIOS-именем. Windows-клиенту необходимо уникальное имя, чтобы установить NetBIOS-сессию с сервером. Пока клиент не сможет зарегистрировать имя рабочей станции, он будет неспособен, скажем, просматривать сетевое окружение или подключать сетевые диски.

УРОВЕНЬ 3

Удаленный доступ к общим ресурсам

Итак, мы уже выяснили, что и клиент, и сервер имеют доступ к сети, и локально ПО на них работает. На данном уровне мы переходим к диагностике работоспособности их взаимодействия.

Разрешение имен
Мы вновь будем использовать утилиты nmblookup и nbstat.exe, чтобы выяснить, может ли клиент разрешить имя сервера и наоборот. Тест будет состоять из двух фаз. В первой мы будем использовать широковещательный запрос, чтобы протестировать отклики сервера и клиента. Это делается путем задания широковещательного адреса (-B 192.168.7.255) в утилите nmblookup при запросе, что задействует сетевое взаимодействие между сервером и клиентом.
Сначала мы попробуем разрешить имя сервера:

$ nmblookup -B 192.168.1.255 TROUBLE querying TROUBLE on 192.168.1.255 192.168.7.75 TROUBLE<00>

После этого мы попробуем разрешить имя клиента, используя тот же широковещательный адрес.

$ nmblookup -B 192.168.1.255 win-client querying win-client on 192.168.1.255 192.168.7.135 win-client<00>

Если до сих пор все шло хорошо, этот тест, скорее всего, отработает корректно. Если же результатом будет ошибка, стоит еще раз поверить соответствие широковещательного адреса на всех машинах.
После этого мы выполним NetBIOS Node Status Lookup, проверим статус узла. На этом шаге делается прямое обращение к IP-адресу, в котором запрашивается список уникальных и групповых NeBIOS имен, зарегистрированных этим хостом. Начнем с запроса к Samba-серверу от Windows-клиента.

C:WINDOWS> nbtstat -A 192.168.7.75 
NetBIOS Remote Machine Name Table 
Name Type Status --------------------------------------------- 
TROUBLE <00> UNIQUE TROUBLE <03> UNIQUE TROUBLE <20> UNIQUE ..__MSBROWSE__.<01> GROUP 
Registered Registered Registered Registered Registered Registered Registered 
LAB LAB LAB 
<00> GROUP <1D> UNIQUE <1E> GROUP 
MAC Address = 00-00-00-00-00-00 

Можно выполнить те же действия на Samba-сервере, чтобы собрать информацию о клиенте. Опции для запроса через утилиту nmblookup, в целом, такие же как и в nbtstat.exe.

$ nmblookup -A 192.168.7.135 Looking up status of 192.168.7.135 
WIN-CLIENT LAB WIN-CLIENT 
<00> - B <ACTIVE> <00> - <GROUP> B <ACTIVE> <03> - B <ACTIVE> 

Если какой-то из этих запросов не выполняется, следует еще раз провести проверки сетевого подключения и NetBIOS-интерфейсов, которые мы рассматривали раньше.

Просмотр общих ресурсов с Windows-клиента
Мы уже использовали smbclient для просмотра списка общих ресурсов. Здесь мы проделаем то же самое, только удаленно с Windows-клиента.
Утилита net.exe — это универсальная утилита для работы с CIFS. Эта утилита является эквивалентом Linux-команды smbclient -L. Опиция view позволяет просмотреть общие ресурсы рабочей группы, или, если указать конкретное имя сервера (например, \TROUBLE), покажет список общих ресурсов на нем.

Удаленное подключение к общим ресурсам
На самом деле, этот шаг является не столько тестом, сколько целью всего процесса. Если мы зашли в консоль с правильным именем и паролем, то следующая команда подключит диск P: локального клиента к общему ресурсу [public] на сервере TROUBLE.

C:WINDOWS> net use p: \TROUBLEpublic
The command completed successfully. 

Чтобы определить, под каким именем подключаться, можно использовать опцию

/user::


C:WINNT>net use \TROUBLEpublic /user:user1
The password or user name is invalid for \TROUBLEpublic. 
Type the password for \TROUBLEpublic:
The command completed successfully. 

root# smbcontrol 1234 debuglevel 
Current debug level of PID 1234 is 0

root# smbcontrol 1234 debug 10 
root# smbcontrol 1234 debuglevel 
Current debug level of PID 1234 is 10

$ smbclient //TROUBLE/public -U testuser%test
session setup failed: ERRSRV - ERRbadpw (Bad password - name/password pair in a Tree Connect or Session Setup are invalid.) 

log level = 10 log file = /usr/local/samba/var/log.%m

pdb_getsampwnam: search by name: testuser startsmbfilepwent_internal: opening file /usr/local/samba/private/smbpasswd getsmbfilepwent: returning passwd entry for user root, uid 0 getsmbfilepwent: returning passwd entry for user jerry, uid 786 getsmbfilepwent: returning passwd entry for user guest1, uid 782 getsmbfilepwent: returning passwd entry for user testuser, uid 791 endsmbfilepwent_internal: closed password file. pdb_getsampwnam: found by name: testuser build_sam_account: smbpasswd database is corrupt! username testuser 
not in unix passwd database! Couldn’t find user ‘testuser’ in passdb. 

#testuser:x:791:100::/dev/null:/bin/false

$ smbclient //TROUBLE/public -U testuser%test Domain=[LAB] OS=[Unix] Server=[Samba 2.2.2] smb: >

Итак, мы разобрали методологию поиска и решения проблем Samba. Проблемы были разнесены по уровням, и каждый уровень зависит от успешной работоспособности более низкого уровня. Еще раз взглянем на них:
•Уровень 1. Сетевое соединение и работоспособный smb.conf.
•Уровень 2. Серверное и клиентское ПО.
•Уровень 3. Удаленный доступ к ресурсам.
•Уровень 4. Сетевое окружение.
•Уровень 5. Логи и анализ трафика.
•Уровень 6. Внутренние проблемы Samba.
Не стоит забывать, что, возможно, с вашей проблемой уже кто-то сталкивался. В этом случае просмотр профильных форумов и других ресурсов может вам сэкономить драгоценное время. Не зацикливайтесь на единственно возможной по вашему мнению причине. Постарайтесь посмотреть на проблему с другой точки зрения. В конце концов решение любой проблемы может быть найдено!

После обновления на домашнем ПК MS Windows до версии 1709 перестал подключаться к сетевой папке. Отваливается с ошибкой 0x80004005. Решение проблемы далее

Имеется домашний сервер на базе FreeBSD, на нем поднят SAMBA сервер, на котором расшарена папка. Безопасность в домашней сети нулевая, на SAMBA настроен гостевой доступ с полными правами к единственной сетевой папке. Все работало до обновления домашнего ПК с MS Windows 10 до версии 1709. После обновления этот комп перестал видеть шару. Остальные устройства видят шару как и раньше, без проблем. После обновления в MS Windows 10 «подкрутили гайки» с безопасностью и гостевой доступ стал недоступен.
Ослабляем гайки и возвращаем доступ

Для этого запускаем редактор групповой политики на ПК

Политика «Локальный компьютер»Конфигурация компьютераАдминистративные шаблоныСетьРабочая станция Lanman
Параметр «Включить небезопасные гостевые входы» — Состояние «Включена»

Перезагружаем ПК и проверяем, что доступ к сетевой папке появился

Где искать в английской версии:

Group Policy settings:
Computer configurationadministrative templatesnetworkLanman Workstation
«Enable insecure guest logons»

Настройки можно произвести и через реестр

Default Registry Value:
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanWorkstationParameters]
«AllowInsecureGuestAuth»=dword:0
Configured Registry Value:
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanWorkstationParameters]
«AllowInsecureGuestAuth»=dword:1