Windows 7 не видит самба диск

Обновлено: 04.07.2024

Привет! Для тех кто не в теме, начну из далека. На компьютерах и ноутбуках с установленной Windows в проводнике есть отдельная вкладка "Сеть". На этой вкладке отображаются устройства из сетевого окружения. То есть, открыв вкладку "Сеть" мы там можем наблюдать компьютеры, сетевые хранилища (NAS), устройства мультимедиа (DLNA), флешки и внешние диски, которые подключены к роутеру и к которым настроен общий доступ. Проще говоря, те устройства, которые подключены через один роутер (находятся в одной сети) и на которых включена функция сетевого обнаружения (устройства, которые могут быть обнаружены в локальной сети) . Там так же может отображаться наш маршрутизатор (раздел "Сетевая инфраструктура") и другие устройства.

Сейчас поясню что и как, и почему я вообще решил написать эту статью. У меня роутер ASUS, к которому я подключил USB флешку, и настроил общий доступ к этой флешке для всех устройств в сети. И что вы думаете, в разделе "Сеть" на всех компьютерах появился этот сетевой накопитель (он там отображается как "Компьютер") , а на моем компьютере он не отображался. То есть, мой компьютер не видел ни флешку подключенную к роутеру, ни другие компьютеры в этой сети. Зато отображался DLNA-сервер запущен на том же роутере. Но это ничего не меняет, так как мне нужен обычный сетевой доступ к накопителю.

Так же я не мог получить доступ к флешке, когда набирал ее адрес //192.168.1.1 в проводнике. Сразу этот адрес открывался через браузере. И мне не удалось подключить этот накопитель как сетевой диск. Его просто не было в списке доступных устройств в сетевом окружении.

Такая проблема, когда Windows 7, Windows 8, или Windows 10 не видит сетевые устройства – не редкость. Это не обязательно должна быть флешка, или внешний HDD, который вы подключили к своему маршрутизатору, как в моем случае. Чаще всего настраивают общий доступ между компьютерами в локальной сети. И точно так же сталкиваются с проблемой, когда компьютеры подключены к одной сети (к одному роутеру) , настройки общего доступа выставлены правильно, а на вкладке "Сеть" пусто. Или отображается только маршрутизатор и ваш компьютер.

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

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

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

Мы будем рассматривать два случая:

Когда компьютеры не видят друг друга в локальной сети.
Общий доступ к сетевому накопителю. Это у нас может быть флешка, или жесткий диск который подключен к роутеру, или отдельный накопитель (он же NAS) .

Первый случай

Чтобы компьютеры могли видеть друг друга и отображаться в проводнике в разделе "Сеть", они должны быть подключены через один маршрутизатор. Или соединены напрямую (кабелем, или по Wi-Fi) . Проще говоря, они должны находится в одной локальной сети.

Дальше, на всех компьютерах (не знаю, сколько их там у вас) , желательно присвоить статус сети "Домашняя" (частная). Как это сделать в Windows 10, я писал в статье домашняя (частная) и общественная (общедоступная) сеть Windows 10. В Windows 7 достаточно зайти в "Центр управления сетями и общим доступом" и сменить там статус текущего подключения.

Если после этого по прежнему компьютер не обнаруживает другие компьютеры (или наоборот) , то давайте еще проверим параметры общего доступа.

Для этого, в окне "Центр управления сетями и общим доступом" (если не знаете как открыть его в Windows 10, то смотрите эту статью) нажимаем на пункт "Изменить дополнительные параметры общего доступа".

И для текущего профиля (обычно это "Частная") выставляем параметры как на скриншоте ниже.

Делаем это на всех компьютерах в локальной сети.

Статьи по этой теме:

Как правило, эти советы решают все проблемы с обнаружением компьютеров в локальной сети.

Второй случай

Когда у вас проблемы с доступом к сетевому накопителю. Как в моем случае. Windows 10 не видела USB накопитель, который был подключен к роутеру ASUS. Сейчас много маршрутизаторов имеют USB-порт для подключения накопителей и других устройств, так что тема актуальная.

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

Не путайте настройки общего доступа с настройками FTP. Настройки FTP-сервера на роутере в данном случае не при чем.

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

Антивирус или брандмауэр может блокировать сетевые устройства

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

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

Поэтому, попробуйте на время полностью остановить работу антивируса, или хотя бы отключить встроенный в него фаервол (межсетевой экран) . В NOD 32 это делается вот так:

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

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

Если окажется, что проблема в антивирусе, то нужно добавить свою сеть в исключения. Запретить фаерволу блокировать саму сеть, или сетевые устройства.

Если у вас нет антивируса, то можно поэкспериментировать с отключением/включением брандмауэра встроенного в Windows.

Рабочая группа

Рабочая группа должна быть одинаковой на всех устройствах. Как правило, так и есть. Но желательно проверить. Для этого откройте свойства компьютера "Система" и перейдите в "Дополнительные параметры системы".

Там будет указана "Рабочая группа". Чтобы изменить ее, нужно нажать на кнопку "Изменить".

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

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

Проблема с доступом к общей сетевой папке по SMB1 в Windows 10 (мое решение)

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

Где-то я прочитал, что можно попробовать открыть общую папку через окно "Выполнить". Нажал сочетание клавиш Win + R, ввел адрес сетевой папки //192.168.1.1 (он же адрес роутера) .

Доступ к накопителю я не получил, но появилась интересная ошибка:

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

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

И ссылка, которую нужно вручную набирать 🙂

Это уже интересно. Хоть что-то.

SMB (Server Message Block) – сетевой протокол, который отвечает за общий доступ к файлам, принтерам и другим сетевым устройствам.

Начал искать. И оказывается, что в Windows 10 отказались от протокола SMB1. Из-за безопасности. А установленный на моем роутере пакет программ Samba походу работает по протоколу SMB1. Поэтому Windows 10 его не видит. Но другие компьютеры, которые так же работают на Windows 10 у меня так же не отображались на вкладке "Сеть".

Так как обновить протокол к SMB2 в настройках роутера я не мог, то решил что нужно как-то включить поддержку SMB1 в Windows 10. И как оказалось, это без проблем можно сделать. В итоге, после подключения компонента "Клиент SMB 1.0/CIFS" у меня все заработало. Система увидела общие папки на компьютерах в сети и сетевую папку настроенную на самом роутере.

Как включить SMB1 в Windows 10?

Через поиск найдите и откройте старую "Панель управления".

Переключитесь на "Мелкие значки" и откройте "Программы и компоненты".

Открываем "Включение или отключение компонентов Windows". Находим пункт "Поддержка общего доступа к файлам SMB 1.0/CIFS". Открываем его и ставим галочку возле "Клиент SMB 1.0/CIFS". Нажимаем Ok.

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

После перезагрузки, на вкладке "Сеть" – "Компьютер" должны появится все доступные устройства в вашей сети.

Буду рад, если эта статья кому-то пригодится и поможет решить возникшую проблему. Не забудьте написать в комментариях о результатах. Или задать вопрос, куда же без них 🙂

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

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

Описание тестовой среды
Для начала — несколько слов о тестовой среде. Условия следующие:
•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:

УРОВЕНЬ 1

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

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

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

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

Если команда выполнится успешно, то стоит обратить внимание на конфигурацию 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 с именем интерфейса в качестве аргумента:

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

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

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

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

УРОВЕНЬ 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

УРОВЕНЬ 3

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

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

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

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

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

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

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

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

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

УРОВЕНЬ 4

Сетевое окружение

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

УРОВЕНЬ 5

Лог-файлы и анализ трафика

Иногда корень проблемы сложно определить даже с помощью специализированных диагностических утилит. Тогда на помощь приходят логи. Первые четыре уровня нашей «пирамиды» можно использовать для подтверждения правильности начальной установки Samba и решения простых проблем. Начиная с пятого уровня, начинается решение серьезных проблем. Рано или поздно вы столкнетесь с проблемой, которая потребует работы с логами.

Лог-файлы Samba
Ниже приведена таблица, в которой описаны уровни детализации логов.

Чтобы узнать текущий уровень логирования smbd (например, с pid 1234), выполним следующую команду из-под учетной записи root:

Если мы хотим увеличить уровень логирования до 10, чтобы получить всю возможную информацию, используем следующую команду:

Следующий вопрос: «Что же делать с логами?»
Вот пример, в котором логи помогли решению проблемы. Мы пробуем подключиться с Windows-клиента к общему дисковому ресурсу. Однако smbd не принимает пароль для соединения. Когда мы используем smbclient для теста, мы получаем ошибку:

Мы совершенно уверены, что значение smbpasswd верно, и пароль — test. Попробуем подключиться еще раз, добавив

в секцию [global] файла smb.conf, и мы увидим новые строчки в файле log.TROUBLE:

Последняя строка и есть ответ на наш вопрос. Samba не смогла найти учетную запись testuser. А это произошло, так как кто-то закомментировал строку в файле /etc/passwd:

Это всего лишь один пример. Вывод в логах может быть запутанным, но можно использовать grep, чтобы находить следующие ключевые слова:
• fail
• error
• unsuccessful
• corrupt
• unknown

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

УРОВЕНЬ 6

Внутренние проблемы Samba

Если ничего из вышеприведенного не помогло — возможно, вы столкнулись с каким-либо багом Samba. Список известных можно посмотреть на официальном сайте. Чтобы свести к минимуму вероятность появления подобного рода проблем, используйте актуальную и стабильную версию Samba, а также следите за выходом исправлений: исправляются разведанные баги достаточно быстро.

У меня есть сервер под управлением RHEL. В сети три рабочие станции: две linux (RHEL) и одна Windows 7. Я использую samba для совместного использования устройства хранения (подключенного к серверу) с рабочими станциями. Уже более года это прекрасно работает. Однако после вчерашнего обновления сервера я не могу получить доступ к общей папке на рабочей станции Windows.

В частности, Windows больше не распознает пароль. Когда я нажимаю «Подключить сетевой диск», введите путь к общей папке и введите свои учетные данные, Windows сообщает мне «Указан неверный сетевой пароль». Я могу получить доступ к общим папкам на обеих рабочих станциях Linux.

Вот что я проверил и подтвердил:

Убедитесь, что уровень проверки подлинности LAN Manager установлен на «Отправка LM & NTLM - используйте сеансовую безопасность NTLMv2, если согласовано». [ отсюда]
Гарантировано, что я могу получить доступ к общей папке на обеих рабочих станциях Linux
Создал новую общую папку и может обращаться к ней также на обеих рабочих станциях Linux
Гарантировано, что я могу пропинговать сервер с моей рабочей станции Windows
Убедитесь, что дата и время правильные на всех машинах
Пробовал перезагрузить все (и надеяться, что проблема исчезнет)

Ожидаемое поведение: я хотел бы, чтобы Windows получила доступ к общей папке

Что не происходит: Windows не может получить доступ к общей папке

Я хотел бы еще раз повторить, что папка была доступна до обновления (два дня назад). Моя текущая версия samba - 4.6.2, а RHEL - 7.4.

Вот кусочки из файла smb.conf (полный файл ниже):

где MBIAL_STORAGE - это имя общей папки. Доступ к рабочим станциям Linux осуществляется с использованием smb: // IP_ADDRESS / mbial_storage с MBIAL в качестве имени пользователя и MSHOME в качестве рабочей группы. Я попытался дать Windows MSHOME \ MBIAL в качестве имени пользователя, но это не сработало.

Вот полный файл smb.conf:

Был бы очень признателен за понимание этого вопроса. Я надеюсь, что это что-то действительно тривиальное и глупое, что я упускаю из виду!

Я не думаю, что вы пытались использовать точку восстановления, или пытались удалить последние обновления на прошлой неделе, или восстанавливали образ системы? Это были бы первые вещи, которые нужно попробовать. Я предполагаю, что ваша samba не изменилась за последние несколько месяцев (или с тех пор, как вы в последний раз перезагружали Windows?) . Кроме того, ваш общий доступ к samba в общедоступной или домашней сети с Win7? Или Win7 получает доступ к общему ресурсу через внутреннюю сеть или через Интернет? Ох . ты тоже запускаешь selinux? Эээ . это может осложнить то, чего я ожидал . @Astara Здравствуйте, на самом деле я никогда не обновлял свою рабочую станцию Windows. Только сервер был обновлен. Так что нет обновлений для удаления. Действительно, конфигурация samba не изменилась с прошлого года, и Windows WS был перезагружен только после начала проблемы. Общая папка samba настроена как домашняя на рабочей станции Windows.

Решением для автора было изменение уровня аутентификации LAN Manager Send NTLMv2 response only с Send LM & NTLM - use NTLMv2 session security if negotiated .

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

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

Попробуйте это на клиенте W7:

В редакторе локальной групповой политики перейдите к:

Политика локального компьютера-> Конфигурация компьютера-> Параметры Windows-> Параметры безопасности-> Локальные политики-> Параметры безопасности

Найдите политику по имени Microsoft network client: Digitally sign communications (always) .

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

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

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

Что такое Samba?

Samba - серверное приложение, реализующее доступ клиентских терминалов к папкам, принтерам и дискам про протоколу SMB/CIFS.

Настройка общих папок

Linux

Установка и настройка Samba-сервер для Ubuntu выполняется следующими этапами.

Обновляем информацию о репозиториях и устанавливаем обновления для существующих пакетов в системе:

apt-get update && apt-get upgrade

Устанавливаем пакет Samba:

apt-get install -y samba samba-client

Создадим резервную копию файла конфигурации:

cp /etc/samba/smb.conf /etc/samba/smb.conf_sample

Создадим директории для файлов, например в каталоге /media:

Важно! По умолчанию, директория /media располагается в корне системы /, для нее редко создается свой раздел. По этой причине возможно переполнение корневого раздела. Во избежание этой неприятной ситуации, рекомендуем монтировать отдельный жесткий диск в /media/samba.

Создаем каталог для всех пользователей:

Изменим права доступа к каталогу:

chmod -R 0755 /media/samba/public

Также следует воспользоваться командой chown для смены владельца и/или группы.

Создаем директорию для ограниченного круга лиц:

С помощью системных инструментов создадим группу пользователей:

Добавляем пользователей Samba:

Созданных пользователей добавляем в группу:

usermod -aG smbgrp user1

Изменим группу, которой принадлежит приватная директория:

chgrp smbgrp /media/samba/private

С помощью инструментов Samba создадим пароль для добавленного пользователя:

smbpasswd -a user1

С помощью текстового редактора, например, nano, редактируем конфигурационный файл samba:

Удаляем все строки из файла. Вставляем следующие:

[global]
workgroup = WORKGROUP
security = user
map to guest = bad user
wins support = no
dns proxy = no
[public]
path = /media/samba/public
guest ok = yes
force user = nobody
browsable = yes
writable = yes
[private]
path = /media/samba/private
valid users = @smbgrp
guest ok = no
browsable = yes
writable = yes

Сохраняем используя сочетание Ctrl + X, затем нажимаем Y и Enter.

Объясним значения строк. конфигурационный файл состоит из трех секций:

global - данная секция отвечает за общие настройки Samba-сервера;

public и private - секции описания настроек директорий общего доступа.

В секции global присутствуют пять параметров:

workgroup - рабочая группа. Для упрощения работы пользователей WORKGROUP указывается, как группа по умолчанию. Если в вашей сети имя рабочей группы изменено, то следует изменить это значение и для Samba;
security - уровень безопасности сервера. Значение user означает авторизацию по паре логин/пароль;
map to guest - параметр определяет способ обработки запросов. Значение bad user означает, что запросы с неправильным паролем будут отклонены, даже если такое имя пользователя существует;
wins support - включить или выключить поддержку WINS;
dns proxy - возможность проксирования запросов к DNS.

Настройки директорий выполняются в соответствующих секциях:

path - полный путь до директории на жестком диске;

guest ok - возможность доступа к каталогу без пароля (гостевой);

browsable - показывать ли каталог (“шару”) на сервере среди прочих. Если параметр установлен как “no”, то доступ будет возможен по полному пути, например ip-addresshidden_directory;

force user - пользователь от которого ведется работа с каталогом. Для повышения безопасности сервера, обычно используют nobody. Главное, не использовать пользователя root - это небезопасно.

writable - установка значения как “yes” позволяет пользователю выполнять действия над файлами внутри каталога - переименование, добавление, удаление, перемещение в подкаталог и копирование;

valid users - список пользователей у которых есть доступ к каталогу. Если пользователей несколько, их имена указываются через запятую. Если необходим доступ для пользователей принадлежащих группе, перед именем группы устанавливается символ ”at” @ (“собака”).

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

Читайте также: