Windows 7 не подключается к сетевой папке samba

Эта статья по сути будет подборкой «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.
Не стоит забывать, что, возможно, с вашей проблемой уже кто-то сталкивался. В этом случае просмотр профильных форумов и других ресурсов может вам сэкономить драгоценное время. Не зацикливайтесь на единственно возможной по вашему мнению причине. Постарайтесь посмотреть на проблему с другой точки зрения. В конце концов решение любой проблемы может быть найдено!

Windows 7 не подключает SAMBA ресурс, расположенный на Windows XP

Windows7 Professional или Ultimate

1. Комбинация Win+R пишем gpedit.msc и Enter. Или Пуск->Поиск->gpedit.msc (можно сразу secpol.msc).
2. Открываем локальные групповые политики: Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики
3. Параметры безопасности — Сетевая безопасность: уровень проверки подлинности Lan Manager
4. Выбирете значение Отправлять LM и NTLM — использовать сеансовую безопасность NTLMv2 при согласовании.
5. Перезагрузка и подключаемся к SAMBA.

Windows 7 Home Basic или Home Premium (графической оснастки политик нет(((((

что бы проделать тоже самое но в реестре делаем следующее

1. Комбинация Win+R пишем regedit и Enter. Или Пуск->Поиск->regedit
2. Находим ветку реестра HKLMSystemCurrentControlSetControlLsa
3. в этом разделе создать параметр REG_DWORD (32 бита) ИМЯ: LmCompatibilityLevel значение: 0
4. Перезагрузка и подключаемся к SMB.

Для справки:
Значение данного параметра изменяется элементом СЕТЕВАЯ БЕЗОПАСНОСТЬ: УРОВЕНЬ ПРОВЕРКИ ПОДЛИННОСТИ LAN MANAGER.

Данный параметр может принимать следующие значения.
0. Данное значение устанавливается при помощи положения элемента ОТПРАВЛЯТЬ LM И NTLM ОТВЕТЫ.
1. Данное значение устанавливается при помощи положения элемента ОТПРАВЛЯТЬ LM И NTLM — ИСПОЛЬЗОВАТЬ СЕАНСОВУЮ БЕЗОПАСНОСТЬ NTLMV2 ПРИ СОГЛАСОВАНИИ.
2. Данное значение устанавливается при помощи положения элемента ОТПРАВЛЯТЬ ТОЛЬКО NTLM ОТВЕТ.
3. Данное значение используется по умолчанию и устанавливается при помощи положения элемента ОТПРАВЛЯТЬ ТОЛЬКО NTLMV2 ОТВЕТ.
4. Данное значение устанавливается при помощи положения элемента ОТПРАВЛЯТЬ ТОЛЬКО NTLMV2-ОТВЕТ. ОТКАЗЫВАТЬ LM.
5. Данное значение устанавливается при помощи положения элемента ОТПРАВЛЯТЬ ТОЛЬКО NTLMV2-ОТВЕТ. ОТКАЗЫВАТЬ LM И NTLM.

Источник

Доступ к SAMBA-серверу из Windows 7 Pro SP1 32-бит.

Имеется SAMBA-сервер с файловым хранилищем. Туда время от времени надо закидывать документы. Делают это через FAR. Подключаются командой:

net:\samba-server

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

Есть два момента, из=за чего может происходить подобное:
1. Не работает подключение, поскольку уже имеются незакрытые подключения (источник).

Если после ввода в проводнике Windows названия шары (в данном примере \samba-server) возникает ошибка:

Множественное подключение к серверу или разделяемым ресурсам одним пользователем
с использованием более одного имени пользователя не разрешено.
Отключите все предыдущие подключения к серверу и повторите…

следует из командной строки Windows удалить предыдущие подключения:

net use * /del

2. Начиная с версий Windows 7 и 2008 r2 параметры авторизации у MS поменялись (источник). Скорее всего Samba вскоре это учтёт, а пока подружить системы можно изменив на Win7 свойства сетевой безопасности:
Пуск — Панель управления — Администрирование — Локальная политика безопасности — Локальные политики — Параметры безопасности

Сетевая безопасность: минимальная сеансовая безопасность для клиентов на базе NTLM SSP — убрать галочку с «Требовать 128-битное шифрование».
Таких параметра два — выполнить для обоих
Сетевая безопасность: уровень проверки подлинности LAN Manager — выбрать в списке пункт «Отправлять LM- и NTML-ответы»

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Источник

Windows не может получить доступ к SAMBA серверу, возможные причины

Приведу файл конфига smb.conf, рассматривал далеко не один конфиг, но расшарить папки так и не получилось, подскажите в чем проблема может быть? Где я неправ?

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

В iptables причина, инфа 146%

Хорошо, спасибо. Просто везде где я смотрел про таблицы ни слова, мол, пишите смб.конф и будет вам счастье. Наверное плохо искал.

service iptables stop
chkconfig iptables off

Подозреваю, тебе и так сойдет.

что значит «не получилось»?

тест подключения к самбе на сервере «smbclient -L localhost» проходит?

Вывод этой команды

Да, отключив iptables заработало, спасибо. Но их отключать нежелательно. И «и так сойдет» не тот подход в данном случае. Подскажите, почему не работает как в этом мануале??

-A INPUT -d 192.168.1.0/24 -p tcp -m tcp —dport 3232 -j ACCEPT

Из официального мана же.

netstat -tulpn | egrep «samba|smbd|nmbd|winbind»

Так нельзя понять почему не работает, нужно видеть как минимум всю цепочку INPUT вместе с политикой.

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

и команда эта не прошла, пишет, что не находит smbd && nmbd && winbind, выполнилась только для samba

Вот смотри, по цепочке

Это значит, что второе правило никогда не сработает.
Нужно, чтобы разрешающее правило было выше, чем то которое запрещает.

я исправил, но доступа нет все равно. Не пускает.

Попробуйте подключение по IP адресу вместо имени хоста.

я так и делал всегда. По имени не подключался, только по ip.

Если вы скинули вывод iptables после попыток подключения, то судя по выводу не было даже попыток этих самых подключений. Все подключения были только на 22 порт ssh.

Ну и как вариант может в цепочке output злое правило которое блокирует.

wndows компьютер точно из сети 192.168.1. ?

Не понял по поводу подключения, потому что попытки точно были. Хорошо, спасибо Вам большое за советы. Буду искать.

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

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

Изменил на свою сеть, не работает тоже. В чем проблема теперь вообще непонятно, правила по идее последовательно идут, запрет стоит в конце.

так же нужен ip компьютера с которого происходит подключение.

Источник

После обновления на домашнем ПК 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

При настройке локальной сети на Windows 7,8 и 10 требуется правильно назначать доступы пользователям и настраивать службы. Иначе возникает сетевая ошибка с кодами 0x800070035, 0x80004005 или 0x800704cf и появляется сообщение, что Windows не удается получить доступ к нужной сетевой папке, диску, устройству или файлу.

Сообщение об ошибке, в зависимости от версии ОС, может выглядеть следующим образом:

1. Windows не может получить доступ к компьютеру в локальной сети. Не найден сетевой путь. Код ошибки:
2. Windows не может получить доступ к сетевой папке/диску/иному расположению в локальной сети.
3. Windows не может получить доступ к *Папка или файл*. Разрешение на доступ к *Путь до папки* отсутствует. Обратитесь к сетевому администратору для получения доступа.

[Обновление] Быстро исправить ошибки с кодом 0x80004005 (а иногда и с остальными) удается, веся всего одну запись в реестр:

1. Открыть «Пуск» -> «Выполнить», ввести regedet и нажать Enter.
2. В разделе реестра HKEY_LOCAL_MACHINE перейти по пути Software Policies Microsoft Windows LanmanWorkstation.
3. ПКМ — создать новый параметр имя AllowInsecureGuestAuth тип REG_DWORD Enabled Value 1 (значение 1 — включено). Перезагрузить ПК.

Оглавление статьи:

• Исправление сетевых ошибок 0x800070035 и 0x80004005
• Способ 1: Проверка настроек общего доступа
• Способ 2: Проверка работоспосоности службы Сервер
• Способ 3: Настройка свойств сетевой карты
• Способ 4: Настройка Службы компонентов
• Способ 5: Настройка доступа к сетевой папке

Исправление сетевых ошибок 0x800070035 и 0x80004005

Причины, по которым Windows 7 или 10 может получить доступ к сетевой папке или файлам, практически всегда кроются в неправильно выставленных настройках системы, нежели в каких-либо ошибках. По аналогичным причинам в локальной сети может отсутствовать доступ к другому компьютеру, и система будет выдавать ошибку «Не удалось установить соединение. Не найден сетевой путь.» с аналогичными кодами. Большинство проблем исправляется элементарно, при помощи простых изменений настроек.

Если Windows не может получить доступ к сетевой папке и выдает ошибки 0x800070035 или 0x80004005, нужно:

1. Проверить настройки общего доступа.
2. Убедиться, что включена сетевая служба «Сервер».

Проверка настроек общего доступа

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

Последовательность действий:

1. Выбрать сетевую папку или диск, для которых требуется создать общий доступ.
2. Нажать правой кнопкой мыши, выбрать в контекстном меню «Общий доступ».
3. Перейти по пункту подменю «Конкретные пользователи».
4. В открывшемся окне нажать на треугольную стрелочку, расположенную рядом с кнопкой «Добавить».
5. Выбрать из появившегося списка пользователя, которому требуется предоставить доступ. В случае, если в списке не будет никаких пользователей, следует выбрать вариант «Все».
6. Установить права доступа для пользователя: только чтение (просмотр файлов), либо чтение и запись (возможность изменения, добавления и удаления файлов из сетевой папки).

После этого нужно нажать кнопку «Общий доступ» и, если система не покажет никаких ошибок или предупреждений, нажать на кнопку «Готово».

В Windows 8 и 10 есть более простой способ поделиться содержимым папки или диска с пользователями домашней группы:

1. Нажать правой кнопкой мыши по нужной папке.
2. Выбрать в контекстном меню пункт «Поделиться».
3. Выбрать подпункт «Домашняя группа (просмотр и изменение)».

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

Проверка работоспособности службы Сервер

«Сервер» является встроенной службой в Windows, необходимой для работоспособности локальной сети и подключения к удаленным компьютерам, устройствам или файлам. Если компьютер ранее не использовался в качестве сервера или для подключения к домашней сети, служба может быть отключена. Это часто становится причиной ошибок доступа к сетевым папкам, даже когда права для всех пользователей выставлены корректно и остальные настройки ОС в норме.

Включение и выключение служб в Windows 7 и 10 происходит в Панели управления:

1. Нажать «Пуск» — «Администрирование» — «Службы».
2. Если вкладка «Администрирование» отсутствует в меню «Пуск», перейти в «Панель управления» и найти в списке пункт «Службы» во вкладке «Администрирование».
3. Откроется окно со всеми службами, в котором требуется отыскать «Сервер».
4. Кликнуть по строке «Сервер» правой кнопкой мыши, в появившемся контекстном меню выбрать пункт «Свойства».
5. В открывшемся окне во вкладке «Общее» выбрать «Тип запуска»: автоматически или вручную.

Если служба изначально была выключена, «Тип запуска» будет установлен в положение «Отключена». Запуск вручную вынудит перезапускать службу каждый раз, когда потребуется доступ к сетевой папке, удаленному компьютеру или файлам в домашней группе. В автоматическом режиме служба будет запускаться самостоятельно, и заново проделывать указанные действия не потребуется.

Настройка свойств сетевой карты

Ошибки подключения к сетевым устройствам с кодами 0x800070035 и 0x80004005 могут быть решены путем выставления настроек сетевого подключения. В настройках сетевой карты нужно снять флажок с протокола iPv6, а также выполнить настройку iPv4. Метод одинаково хорошо работает в Windows 7 и 10 всех версией. Сначала следует попробовать только выключить протокол iPv6, а уже потом выполнять остальные действия, если этот простой способ не помог.

Пошаговая инструкция:

1. Зайти в пеню «Пуск», перейти в «Панель управления».
2. В Windows 7: Перейти в раздел «Центр управления сетями и общим доступом», затем «Изменение параметров адаптеров». Для Windows 10: В панели управления выбрать «Сеть и интернет», затем «Центр управления сетями и общим доступом», выбрать в левом меню пункт «Изменение параметров адаптеров».
3. Выбрать подключение по локальной сети, по которому не удается получить доступ. Кликнуть по нему правой кнопкой мыши и выбрать пункт «Свойства».
4. В свойствах сетевой карты убрать значок с протокола iPv6.
5. Открыть свойства протокола iPv4, перейти во вкладку «Дополнительно».
6. Открыть вкладку с названием «WINS», нажать на «Параметры NetBIOS».
7. Поставить отметку, в зависимости от типа ip-адресации: «По умолчанию» для динамической ip-адресации и «Включить NetBIOS через TCP/IP» для статической.
8. Нажать три раза «Ок», «Ок», «Ок».

После этого требуется выполнить несколько простых действий в Диспетчере устройств:

1. Открыть «Пуск» — «Панель управления» — «Оборудование и звук» — «Диспетчер устройств».
2. Перейти на вкладку «Вид», выбрать отметку «Показать скрытые устройства».
3. Нажать «Сетевые адаптеры» и удалить все адаптеры 6to4.

Изменения вступят в силу после перезагрузки компьютера.

Настройка Службы компонентов

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

Инструкция по настройке локального доступа через Службу компонентов:

1. Нажать кнопку «Пуск», ввести в поле поиска «Службы компонентов».
2. Кликнуть по найденному результату правой кнопкой мыши, выбрать в контекстном меню «Запуск от имени администратора».
3. В выскочившем окошке разрешить программе внести изменения на этот компьютер. Должно открыться окно со службой.
4. Раскрыть окно «Службы компонентов», открыть второе окно «Компьютеры».
5. Нажать по надписи «Мой компьютер» правой кнопкой мыши, перейти на вкладку «Свойства», затем «Свойства по умолчанию».
6. Поставить «Уровень проверки подлинности по умолчанию» в положение «По умолчанию».
7. Поставить «Уровень олицетворения по умолчанию» в положение «Олицетворение».
8. Нажать кнопку «Применить».
9. Нажать кнопку «Ок».
10. Закрыть окно со «Службой компонентов».

Желательно сразу перезагрузить компьютер, после чего снова попробовать подключиться. Если ошибка сохраняется, следует проверить настройки доступа к сетевой папке.

Настройки доступа к сетевой папке

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

Просматривать содержимое сетевой папки могут только те пользователи, у которых есть доступ. Это легко проверить:

1. Кликнуть по нужной папке правой кнопкой мыши, открыть «Свойства».
2. Перейти на вкладку «Безопасность».
3. В окне «Группы или пользователи» должна быть выбрана позиция «Все».

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

1. Нажать кнопку «Изменить» под окном «Группы или пользователи».
2. Кликнуть по кнопке «Добавить», перейти во вкладку «Дополнительно…».
3. Нажать «Поиск», выбрать в результатах поиска строку «Все», после чего кликнуть «Ок».
4. Еще раз нажать «Ок».

Осталось выставить права для созданной группы пользователей «Все» — чтение, доступ, изменение и так далее. Аналогичным образом можно устанавливать разные настройки для отдельных групп, но это не обязательно. Одни настройки для всех пользователей снизят риск возникновения повторных ошибок доступа к минимуму.

SMB: необходимо открыть порты для совместного использования файлов и принтеров

применимо к: Windows server 2022, Windows server 2019, Windows Server 2016, Windows Server 2012 r2 и Windows Server 2012, Windows Server 2008 r2

Этот раздел предназначен для устранения определенной проблемы, обнаруженной анализатор соответствия рекомендациям сканированием. Сведения, приведенные в этом разделе, следует применять только к компьютерам, на которых были запущены файловые службы анализатор соответствия рекомендациям и которые столкнулись с проблемой, описанной в этом разделе. Дополнительные сведения о рекомендациях и проверках см. в разделе анализатор соответствия рекомендациям.

Операционная система

Продукт или компонент

Уровень серьезности

Категория

Проблема

Порты брандмауэра, необходимые для общего доступа к файлам и принтерам, не открыты (порты 445 и 139).

Влияние

Компьютеры не смогут получить доступ к общим папкам и другим сетевым службам на основе SMB на этом сервере.

Решение

Включите общий доступ к файлам и принтерам для обмена данными через брандмауэр компьютера.

Для выполнения этой процедуры как минимум необходимо быть участником группы Администраторы (либо аналогичной).

Открытие портов брандмауэра для включения общего доступа к файлам и принтерам

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

В левой области щелкните Дополнительные параметры, а затем в дереве консоли щелкните правила для входящих подключений.

В разделе правила для входящих подключений выберите файлы правил и общий доступ к принтерам (сеансы с расширением NetBIOS) и общий доступ к ФАЙЛАМ и принтерам (SMB-in).

Щелкните правой кнопкой мыши на каждом правиле и нажмите Включить правило.

Источник

Не открываются общие сетевые SMB папки в Windows 10

Если вы из Windows 10 не можете открыть сетевые папки на других сетевых устройствах (NAS, Samba сервера Linux) или на компьютерах со старыми версиями Windows (Windows 7/ XP /2003), скорее всего проблема связана с тем, что в вашей новой версии Windows 10 отключена поддержка устаревших и небезопасных версий протокола SMB (используется в Windows для доступа к общим сетевым папкам и файлам). Так, начиная с Windows 10 1709, был отключен протокол SMBv1 и анонимный (гостевой) доступ к сетевым папкам по протоколу SMBv2.

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

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

Начиная с версии Windows 10 1709 (Fall Creators Update) Enterprise и Education пользователи стали жаловаться, что при попытке открыть сетевую папку на соседнем компьютере стала появляться ошибка:

При это на других компьютерах со старыми версиями Windows 8.1/7 или на Windows 10 с билдом до 1709, эти же сетевые каталоги открываются нормально. Эта проблем связана с тем, что в современных версиях Windows 10 (начиная с 1709) по умолчанию запрещен сетевой доступ к сетевым папкам под гостевой учетной записью по протоколу SMBv2 (и ниже). Гостевой (анонимный) доступ подразумевают доступ к сетевой папке без аутентификации. При доступе под гостевым аккаунтом по протоколу SMBv1/v2 не применяются такие методы защиты трафика, как SMB подписывание и шифрование, что делает вашу сессию уязвимой против MiTM (man-in-the-middle) атак.

При попытке открыть сетевую папку под гостем по протоколу SMB2, в журнале клиента SMB (Microsoft-Windows-SMBClient) фиксируется ошибка:

В большинстве случае с этой проблемой можно столкнуться при использовании старых версий NAS (обычно для простоты настройки на них включают гостевой доступ) или при доступе к сетевым папкам на старых версиях Windows 7/2008 R2 или Windows XP /2003 с настроенным анонимным (гостевым) доступом (см. таблицу поддерживаемых версий SMB в разных версиях Windows).

В этом случае Microsoft рекомендует изменить настройки на удаленном компьютере или NAS устройстве, который раздает сетевые папки. Желательно переключить сетевой ресурс в режим SMBv3. А если поддерживается только протокол SMBv2, настроить доступ с аутентификацией. Это самый правильный и безопасный способ исправить проблему.

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

• NAS устройство – отключите гостевой доступ в настройках вашего NAS устройства (зависит от модели);
• Samba сервер на Linux — если вы раздаете SMB каталог с Linux, в конфигурационном файле smb.conf в секции [global] нужно добавить строку: map to guest = never
  А в секции с описанием сетевой папки запретить анонимный доступ: guest ok = no
• В Windows вы можете включить общий доступ к сетевым папкам и принтерам с парольной защитой в разделе Control PanelAll Control Panel ItemsNetwork and Sharing CenterAdvanced sharing settings. Для All Networks (Все сети) в секции “Общий доступ с парольной защитой” (Password Protected Sharing) имените значение на “Включить общий доступ с парольной защитой” (Turn on password protected sharing). В этом случае анонимный (гостевой) доступ к папкам будет отключен и вам придется создать локальных пользователей, предоставить им доступ к сетевым папкам и принтерам и использовать эти аккаунты для подключения к общим папкам на этом компьютере.

Есть другой способ – изменить настройки вашего SMB клиента и разрешить доступ с него на сетевые папки под гостевой учетной записью.

Чтобы разрешить гостевой доступ с вашего компьютера, откройте редактор групповых политик (gpedit.msc) и перейдите в раздел: Конфигурация компьютера -> Административные шаблоны -> Сеть -> Рабочая станция Lanman (Computer Configuration ->Administrative templates -> Network (Сеть) -> Lanman Workstation). Включите политику Enable insecure guest logons (Включить небезопасные гостевые входы).

В Windows 10 Home, в которой нет редактора локальной GPO, вы можете внести аналогичное изменение через редактор реестра вручную:

Или такой командой:

reg add HKLMSYSTEMCurrentControlSetServicesLanmanWorkstationParameters /v AllowInsecureGuestAuth /t reg_dword /d 00000001 /f

Вашей системе необходимо использовать SMB2 или более позднюю

Другая возможная проблема при доступе к сетевой папке из Windows 10 – поддержка на стороне сервера только протокола SMBv1. Т.к. клиент SMBv1 по умолчанию отключен в Windows 10 1709, при попытке открыть шару вы можете получить ошибку:

При этом соседние устройства SMB могут не отображаться в сетевом окружении и при открытии по UNC пути может появляться ошибка 0x80070035.

Т.е. из сообщения об ошибке четко видно, что сетевая папка поддерживает только SMBv1 протокол доступа. В этом случае нужно попытаться перенастроить удаленное SMB устройство для поддержки как минимум SMBv2 (правильный и безопасный путь).

Если сетевые папки раздает Samba на Linux, вы можете указать минимально поддерживаемую версию SMB в файле smb.conf так:

В Windows 7/Windows Server 2008 R2 вы можете отключить SMBv1 и разрешить SMBv2 так:
Set-ItemProperty -Path «HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters» SMB1 -Type DWORD -Value 0 –Force

Set-ItemProperty -Path «HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters» SMB2 -Type DWORD -Value 1 –Force

В Windows 8.1 отключите SMBv1, разрешите SMBv2 и SMBv3 и проверьте что для вашего сетевого подключения используется частный или доменный профиль:

Disable-WindowsOptionalFeature -Online -FeatureName «SMB1Protocol»
Set-SmbServerConfiguration –EnableSMB2Protocol $true

Если ваше сетевое устройство (NAS, Windows XP, Windows Server 2003), поддерживает только протокол SMB1, в Windows 10 вы можете включить отдельный компонент SMB1Protocol-Client. Но это не рекомендуется.

Запустите консоль PowerShell и проверьте, что SMB1Protocol-Client отключен ( State: Disabled ):

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Client

Включите поддержку протокола SMBv1 (потребуется перезагрузка):

Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Client

Также вы можете включить/отключить дополнительные компоненты Windows 10 (в том числе SMBv1) из меню optionalfeatures.exe -> SMB 1.0/CIFS File Sharing Support

В Windows 10 1709 и выше клиент SMBv1 автоматически удаляется, если он не использовался более 15 дней (за это отвечает компонент SMB 1.0/CIFS Automatic Removal).

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

Источник

Как обнаруживать, включать и отключать SMBv1, SMBv2 и SMBv3 в Windows

применимо к: Windows Server 2022, Windows 10, Windows 8.1, Windows 8, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

В этой статье описывается, как включить и отключить протокол SMB версии 1 (SMBv1), SMB версии 2 (SMB) и SMB версии 3 (SMBv3) на клиентских и серверных компонентах SMB.

Хотя отключение или удаление SMBv1 может вызвать некоторые проблемы совместимости со старыми компьютерами или программами, SMBv1 имеет существенные уязвимости, и мы настоятельно рекомендуем не использовать ее.

Отключение SMB или SMBv3 для устранения неполадок

Мы рекомендуем включить протоколы SMB 2.0 и SMBv3, но может оказаться полезным временно отключить их для устранения неполадок. Дополнительные сведения см. в статье как определить состояние, включить и отключить протоколы SMB на сервере SMB.

в Windows 10, Windows 8.1 и Windows 8 Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 и Windows Server 2012, отключение SMBv3 деактивирует следующие функциональные возможности:

• Прозрачная отработка отказа — клиенты повторно подключаются без прерывания узлов кластера во время обслуживания или отработки отказа
• Scale Out одновременный доступ к общим данным на всех узлах кластеров файлов
• Многоканальное агрегирование пропускной способности сети и отказоустойчивости при наличии нескольких путей между клиентом и сервером
• SMB Direct — добавляет поддержку сети RDMA для обеспечения высокой производительности с низкой задержкой и низким использованием ЦП.
• Шифрование — обеспечивает сквозное шифрование и защищает от перехвата в ненадежных сетях.
• Аренда каталога — улучшает время отклика приложений в филиалах за счет кэширования
• Оптимизация производительности — оптимизация для небольшого случайного чтения и записи ввода-вывода

в Windows 7 и Windows Server 2008 R2 отключение 2.0 отключает следующие функции:

• Составной запрос — позволяет отправлять несколько запросов SMB в виде одного сетевого запроса.
• Большие операции чтения и записи — лучшее использование более быстрых сетей.
• Кэширование свойств папок и файлов — клиенты сохраняют локальные копии папок и файлов
• Устойчивые дескрипторы. разрешение на прозрачное повторное подключение к серверу при наличии временного отключения
• Улучшенная подпись сообщения — HMAC SHA-256 заменяет MD5 как алгоритм хеширования
• Улучшенная масштабируемость общего доступа к файлам — число пользователей, общих папок и открытых файлов на сервере значительно увеличилось.
• Поддержка символьных ссылок
• Модель нежесткой аренды клиента — ограничивает данные, передаваемые между клиентом и сервером, повышая производительность в сетях с высокой задержкой и повышая масштабируемость сервера SMB.
• Поддержка большого MTU — для полного использования 10 Gigabit Ethernet (GbE)
• Повышение эффективности энергопотребления — клиенты, которые имеют открытые файлы на сервере, могут перейти в спящий режим

протокол smb был впервые появился в Windows Vista и Windows Server 2008, а протокол SMBv3 появился в Windows 8 и Windows Server 2012. Дополнительные сведения о функциях SMB и SMBv3 см. в следующих статьях:

Удаление SMBv1

вот как можно удалить SMBv1 в Windows 10, Windows 8.1, Windows Server 2019, Windows Server 2016 и Windows 2012 R2.

Источник

Протокол SMB: определить, включить или отключить определенную версию SMB в Windows

Сетевой протокол SMB (Server Message Block) используется для предоставления совместного удаленного доступа к файлам, принтерам и другим устройствам через порт TCP 445. В этой статье мы рассмотрим: какие версии (диалекты) протокола SMB доступны в различных версиях Windows (и как они соотносятся с версиями samba в Linux); как определить версию SMB на вашем компьютере; и как включить/отключить клиент и сервер SMBv1, SMBv2 и SMBv3.

Версии протокола SMB в Windows

Есть несколько версии протокола SMB (диалектов), которые последовательно появлялись в новых версиях Windows:

• CIFS — Windows NT 4.0;
• SMB 1.0 — Windows 2000;
• SMB 2.0 — Windows Server 2008 и Windows Vista SP1 (поддерживается в Samba 3.6);
• SMB 2.1 — Windows Server 2008 R2 и Windows 7 (поддерживается в Samba 4.0);
• SMB 3.0 — Windows Server 2012 и Windows 8 (поддерживается в Samba 4.2);
• SMB 3.02 — Windows Server 2012 R2 и Windows 8. 1 (не поддерживается в Samba);
• SMB 3.1.1 – Windows Server 2016 и Windows 10 (не поддерживается в Samba).

При сетевом взаимодействии по протоколу SMB между клиентом и сервером используется максимальная версия протокола, поддерживаемая одновременно и клиентом, и сервером.

Ниже представлена сводная таблица, по которой можно определить версию протокола SMB, которая выбирается при взаимодействии разных версий Windows:

К примеру, при подключении клиентского компьютера с Windows 8.1 к файловому серверу с Windows Server 2016 будет использоваться протокол SMB 3.0.2.

Согласно таблице Windows XP, Windows Server 2003 для доступа к общим файлам и папкам на сервере могут использовать только SMB 1.0, который в новых версиях Windows Server (2012 R2 / 2016) может быть отключен. Таким образом, если в вашей инфраструктуре одновременно используются компьютеры с Windows XP (снятой с поддержки), Windows Server 2003/R2 и сервера с Windows Server 2012 R2/2016/2019, устаревшие клиенты не смогут получить доступ к файлам и папкам на файловом сервере с новой ОС.

Если Windows Server 2016/2012 R2 с отключенным SMB v1.0 используется в качестве контроллера домена, значить клиенты на Windows XP/Server 2003 не смогут получить доступ к каталогам SYSVOL и NETLOGON на контроллерах домена и авторизоваться в AD.

На старых клиентах при попытке подключиться к ресурсу на файловом сервере с отключенным SMB v1 появляется ошибка:

Как проверить поддерживаемые версии SMB в Windows?

Рассмотрим, как определить, какие версии протокола SMB поддерживаются на вашем компьютере Windows.

В Windows 10, 8.1 и Windows Server 2019/2016/2012R2 вы можете проверить состояние различных диалектов SMB протокола с помощью PowerShell:

Get-SmbServerConfiguration | select EnableSMB1Protocol,EnableSMB2Protocol

Данная команда вернула, что протокол SMB1 отключен ( EnableSMB1Protocol=False ), а протоколы SMB2 и SMB3 включены ( EnableSMB1Protocol=True ).

В Windows 7, Vista, Windows Server 2008 R2/2008:

Get-Item HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters | ForEach-Object

Если в данной ветке реестра нет параметров с именами SMB1 или SMB2, значить протоколы SMB1 и SMB2 по умолчанию включены.

Также в этих версиях Windows вы можете проверить, какие диалекты SMB разрешено использовать в качестве клиентов с помощью команд:

sc.exe query mrxsmb10

sc.exe query mrxsmb20

В обоих случаях службы запущены ( STATE=4 Running ). Значит Windows может подключаться как к SMBv1, так и к SMBv2 серверам.

Вывести используемые версии SMB с помощью Get-SMBConnection

Как мы говорили раньше, компьютеры при взаимодействии по протоколу SMB используют максимальную версию, поддерживаемую как клиентом, так и сервером. Для определения версии SMB, используемой для доступа к удаленному компьютеру можно использовать командлет PowerShell Get-SMBConnection :

Версия SMB, используемая для подключения к удаленному серверу (ServerName) указана в столбце Dialect.

Можно вывести информацию о версиях SMB, используемых для доступа к конкретному серверу:

Get-SmbConnection -ServerName servername

Если нужно отобразить, используется ли SMB шифрование (появилось в SMB 3.0), выполните:

Get-SmbConnection | ft ServerName,ShareName,Dialect,Encrypted,UserName

Чтобы на стороне сервера вывести список используемых клиентами версий протокола SMB и количество клиентов, используемых ту или иную версию протокола SMB, выполните команду:

Get-SmbSession | Select-Object -ExpandProperty Dialect | Sort-Object -Unique

В нашем примере имеется 825 клиентов, подключенных к серверу с помощью SMB 2.1 (Windows 7/Windows Server 2008 R2) и 12 клиентов SMB 3.02.

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

Set-SmbServerConfiguration –AuditSmb1Access $true

События подключения затем можно извлечь из журналов Event Viewer:

Get-WinEvent -LogName Microsoft-Windows-SMBServer/Audit

Об опасности использования SMBv1

Последние несколько лет Microsoft из соображений безопасности планомерно отключает устаревший протокол SMB 1.0. Связано это с большим количеством критических уязвимостей в этом протоколе (вспомните историю с эпидемиями вирусов-шифровальщиков wannacrypt и petya, которые использовали уязвимость именно в протоколе SMBv1). Microsoft и другие IT компании настоятельно рекомендуют отказаться от его использования.

Однако отключение SMBv1 может вызвать проблемы с доступом к общий файлам и папкам на новых версиях Windows 10 (Windows Server 2016/2019) с устаревших версий клиентов (Windows XP, Server 2003), сторонних ОС (Mac OSX 10.8 Mountain Lion, Snow Leopard, Mavericks, старые версии Linux), различных старых NAS устройствах.

Если в вашей сети не осталось legacy устройств с поддержкой только SMBv1, обязательно отключайте эту версию диалекта в Windows.

В том случае, если в вашей сети остались клиенты с Windows XP, Windows Server 2003 или другие устройства, которые поддерживают только SMBv1, их нужно как можно скорее обновить или тщательно изолировать.

Включение и отключение SMBv1, SMBv2 и SMBv3 в Windows

Рассмотрим способы включения, отключения различных версий SMB в Windows. Мы рассматриваем отдельно включение клиента и сервера SMB (это разные компоненты).

Windows 10, 8.1, Windows Server 2019/2016/2012R2:

Отключить клиент и сервер SMBv1:
Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol

Отключить только SMBv1 сервер:
Set-SmbServerConfiguration -EnableSMB1Protocol $false

Включить клиент и сервер SMBv1:
Enable-WindowsOptionalFeature -Online -FeatureName smb1protocol

Включить только SMBv1 сервер:
Set-SmbServerConfiguration -EnableSMB1Protocol $true

Отключить сервер SMBv2 и SMBv3:
Set-SmbServerConfiguration -EnableSMB2Protocol $false

Включить сервер SMBv2 и SMBv3:
Set-SmbServerConfiguration -EnableSMB2Protocol $true

Windows 7, Vista, Windows Server 2008 R2/2008:

Отключить SMBv1 сервер:

Set-ItemProperty -Path «HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters» SMB1 -Type DWORD -Value 0 –Force

Включить SMBv1 сервер:
Set-ItemProperty -Path «HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters» SMB1 -Type DWORD -Value 1 –Force

Отключить SMBv1 клиент:

sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi
sc.exe config mrxsmb10 start= disabled

Включить SMBv1 клиент:

sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc.exe config mrxsmb10 start= auto

Отключить SMBv2 сервер:

Set-ItemProperty -Path «HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters» SMB2 -Type DWORD -Value 0 -Force

Включить SMBv2 сервер

Set-ItemProperty -Path «HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters» SMB2 -Type DWORD -Value 1 –Force

Отключить SMBv2 клиент:

sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc.exe config mrxsmb20 start= disabled

Включить SMBv2 клиент:

sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc.exe config mrxsmb20 start= auto

Для отключения SMBv2 нужно в этой же ветке установить параметр SMB2=0.

Для отключения SMBv1 клиента нужно распространить такой параметр реестра:

• Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesmrxsmb10
• Name: Start
• Type: REG_DWORD
• Value: 4

При отключении SMB 1.0/CIFS File Sharing Support в Windows вы можете столкнуться с ошибкой “0x80070035, не найден сетевой путь”, ошибкой при доступе к общим папкам, и проблемами обнаружения компьютеров в сетевом окружении. В этом случае вместо служба обозревателя компьютеров (Computer Browser) нужно использовать службы обнаружения (линк).

Источник

I am sharing (to mostly Windows 7 clients) a folder on my Ubuntu PC via SAMBA. To keep things simple, I created a new user named «shared_user» with a shared password «xxxxxxx», whose sole purpose is just to access this specific shared folder.

So, I disseminated this login credential to all the Windows 7 users and asked each one of them to create a mapped network drive (reconnect at logon, remember my credentials) to the new share I created.

Now, the problem is this: although everyone could successfully map and log in to the network share using the given credentials initially, after logging off (or a reboot) and logging back in, Windows would report that it «could not reconnect all network drives». And everyone had to re-enter the username and password again.

I read somewhere that it helps to make the Windows username and password the same as the one on SAMBA/Linux. So I created a new Windows user named «shared_user» with the same «xxxxxxx» password. And only then did Windows succeed in automatically connecting to the network share upon startup.

I really want to be able to use this simple scheme of a shared username and password, since I really just want to manage the accessibility through a manual/arbitrary dissemination of the username and password.

Is there any way to get this scheme to work?

I am sharing (to mostly Windows 7 clients) a folder on my Ubuntu PC via SAMBA. To keep things simple, I created a new user named «shared_user» with a shared password «xxxxxxx», whose sole purpose is just to access this specific shared folder.

So, I disseminated this login credential to all the Windows 7 users and asked each one of them to create a mapped network drive (reconnect at logon, remember my credentials) to the new share I created.

Now, the problem is this: although everyone could successfully map and log in to the network share using the given credentials initially, after logging off (or a reboot) and logging back in, Windows would report that it «could not reconnect all network drives». And everyone had to re-enter the username and password again.

I read somewhere that it helps to make the Windows username and password the same as the one on SAMBA/Linux. So I created a new Windows user named «shared_user» with the same «xxxxxxx» password. And only then did Windows succeed in automatically connecting to the network share upon startup.

I really want to be able to use this simple scheme of a shared username and password, since I really just want to manage the accessibility through a manual/arbitrary dissemination of the username and password.

Is there any way to get this scheme to work?