Smbtree не отображает компьютеры
Я изо всех сил пытаюсь поделиться папками по Lan между двумя машинами Ubuntu 17.04.
Сначала я попытался использовать общий доступ к ресурсам Nautilus, но когда я не мог просматривать папки в обоих направлениях, я переключился на использование Samba. AFAIK обе установки Samba почти идентичны; Я скопировал smb.conf между машинами несколько раз без какого-либо эффекта.
Я могу видеть обе машины в разделе «Другие местоположения» в Nautilus и просматривать общие папки на рабочем столе с ноутбука, но не наоборот.
john @ Laptop: ~ $ smbclient -L //192.168.20.136 -U john
на моем ноутбуке, он выдает ожидаемый список общих ресурсов. На рабочем столе он генерирует ошибку:
john@Desktop:~$ smbclient -L //192.168.20.102 -U john WARNING: The "syslog" option is deprecated Enter john2's password: Connection to 192.168.20.102 failed (Error NT_STATUS_HOST_UNREACHABLE)
Я использовал Other Locations , но переключился на smbpasswd, чтобы упростить действие без эффекта.
Брандмауэры отключены; GUFW сообщает, что одни и те же порты используются на обеих машинах.
Работает разрешение имени; Я могу пинговать имена сетей. Я проверил Wireshark, и Samba общается с рабочего стола на ноутбук, и наоборот.
Я установил smbpasswd в smb.conf на обеих машинах и посмотрел на их журнал, auth.log, /var/log/samba/log.smbd, /var/log/samba/log.nmbd, не обнаружив ничего, связанного с неудавшимся соединением.
Единственная незначительная проблема заключается в том, что обе машины принимают ее по очереди, чтобы действовать как локальный главный браузер для рабочей группы; Я поднял приоритет рабочего стола, чтобы избежать этого, но поведение продолжалось.
Похоже на какую-то проблему авторизации, поэтому я настроил вторую учетную запись пользователя на ноутбуке, чтобы проверить чистую настройку, но получил те же результаты, что и раньше.
Как я могу ближе посмотреть, что происходит, когда Samba на рабочем столе пытается получить доступ к общим папкам ноутбука?
Рабочий стол smb.conf:
Рабочий стол smbtree; нет ресурсов портативного компьютера:
john@Desktop:~$ smbtree Enter john's password: OFFICE-DESIGN \\DESKTOP Desktop server (Samba, Ubuntu) \\DESKTOP\Downloads \\DESKTOP\Pictures \\DESKTOP\PDF PDF \\DESKTOP\IX6500 IX6500 \\DESKTOP\Canon-PIXMA-iX6560 Canon PIXMA iX6560 \\DESKTOP\Canon-iX6500-series Canon iX6500 series \\DESKTOP\iX6500-series Canon iX6500 series \\DESKTOP\Canon-iX6500-series-2 Canon iX6500 series \\DESKTOP\IPC$ IPC Service (Desktop server (Samba, Ubuntu)) \\DESKTOP\Documents \\DESKTOP\Public \\DESKTOP\print$ Printer Drivers \\LAPTOP laptop server (Samba, Ubuntu)
Рабочий стол smbd; нет ошибок. Ошибки рабочего стола nmbd:
john@Desktop:~$ systemctl status nmbd.service ● nmbd.service - Samba NMB Daemon Loaded: loaded (/lib/systemd/system/nmbd.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2017-12-19 11:52:52 +07; 20min ago Docs: man:nmbd(8) man:samba(7) man:smb.conf(5) Main PID: 25317 (nmbd) Status: "nmbd: ready to serve connections. " Tasks: 1 (limit: 4915) CGroup: /system.slice/nmbd.service └─25317 /usr/sbin/nmbd Dec 19 12:09:58 Desktop nmbd[25317]: Dec 19 12:09:58 Desktop nmbd[25317]: Samba name server DESKTOP has stopped being a local master browser for workgroup OFFICE-DESIGN on subnet 192.168 Dec 19 12:09:58 Desktop nmbd[25317]: Dec 19 12:09:58 Desktop nmbd[25317]: ***** Dec 19 12:10:15 Desktop nmbd[25317]: [2017/12/19 12:10:15.371279, 0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2) Dec 19 12:10:15 Desktop nmbd[25317]: ***** Dec 19 12:10:15 Desktop nmbd[25317]: Dec 19 12:10:15 Desktop nmbd[25317]: Samba name server DESKTOP is now a local master browser for workgroup OFFICE-DESIGN on subnet 192.168.20.136 Dec 19 12:10:15 Desktop nmbd[25317]: Dec 19 12:10:15 Desktop nmbd[25317]: *****
Состояние портативного компьютера smbd; нет ошибок. Laptop nmbd status:
john@laptop:/etc/samba$ systemctl status nmbd.service ● nmbd.service - Samba NMB Daemon Loaded: loaded (/lib/systemd/system/nmbd.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2017-12-20 11:57:37 +07; 1min 38s ago Docs: man:nmbd(8) man:samba(7) man:smb.conf(5) Main PID: 11314 (nmbd) Status: "nmbd: ready to serve connections. " Tasks: 1 (limit: 4915) CGroup: /system.slice/nmbd.service └─11314 /usr/sbin/nmbd Dec 20 11:57:37 laptop systemd[1]: nmbd.service: Supervising process 11314 which is not our child. We'll most likely not notice when it exits. Dec 20 11:57:37 laptop nmbd[11314]: [2017/12/20 11:57:37.518663, 0] ../lib/util/become_daemon.c:124(daemon_ready) Dec 20 11:57:37 laptop nmbd[11314]: STATUS=daemon 'nmbd' finished starting up and ready to serve connections Dec 20 11:57:37 laptop systemd[1]: Started Samba NMB Daemon. Dec 20 11:58:08 laptop nmbd[11314]: [2017/12/20 11:58:08.875623, 0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2) Dec 20 11:58:08 laptop nmbd[11314]: ***** Dec 20 11:58:08 laptop nmbd[11314]: Dec 20 11:58:08 laptop nmbd[11314]: Samba name server LAPTOP is now a local master browser for workgroup OFFICE-DESIGN on subnet 192.168.20.102 Dec 20 11:58:08 laptop nmbd[11314]: Dec 20 11:58:08 laptop nmbd[11314]: *****
Использование smbclient Я могу подключаться локально как на ноутбуке, так и на рабочем столе и удаленно с ноутбука на рабочий стол, но с рабочего стола на ноутбук не удается.
Рабочий стол для ноутбука:
john@Desktop:/etc/samba$ smbclient //192.168.20.102/j2Documents -U john2 WARNING: The "syslog" option is deprecated Enter john2's password: Connection to 192.168.20.102 failed (Error NT_STATUS_HOST_UNREACHABLE)
В сети 3 компьютера: ISKATEL-DSK - этот компьютер с Linux, ASUS - Windows 7, ERIKA-NORD - Windows XP.
Почему smbtree не видит ASUS? Почему на компьютерах с Windows не показываются шары? При этом иногда smbtree вообще ничего не отображает, причем именно иногда, где тут закономерность я не пойму.
Теперь пытаюсь обозрить компьютер ERIKA-NORD с помощью smbclient. Обрашаюсь и по имени и по ip-адресу, ошибки разные:
Мне кажется что проблема с настройкой общего доступа в самих ASUS - Windows 7, ERIKA-NORD - Windows XP.
эти ASUS - Windows 7, ERIKA-NORD - Windows XP видят друг друга в сети? В 7 там надо разрешать сетевое обнаружение в центре управления сетями для сетевого профиля.
Serega86
Вообще-то такая же ситуация у меня была и в сети из 30 компьютеров. Не может у всех быть "проблемы с настройкой общего доступа".
SERVER ROLE = STANDALONE
Если параметр security также не определен, то используется значение security по умолчанию. При этом, клиент должен сначала произвести вход (logon), с существующим именем пользователя и паролем (имя может быть транслировано с помощью параметра username map). Шифрованные пароли (см. encrypted passwords) также могут быть использованы в этом режиме. Такие параметры, как user и guest only, если они установлены на ресурс, могут поменять значение пользователя UNIX, который будет использоваться в конечном счете, НО только после того как пользователь успешно пройдет аутентификацию. Eng.
а фаервол включен? Используется ли роутер?
Правильно заданный вопрос содержит более половины ответа, чего здесь увы, пока не наблюдается.
Дело в том, что на LANMAN/SMB/SMB2/SMB3 протоколы много чего влияет:
1) на "серверах" (машинах, куда подключаетесь):
- наличие их в одной сети с точки зрения прохождения широковещательных запросов (иначе wins, smb ovet tcp)
- наличие запущенной службы server (Windows) или smbd (*nix)
- настройки фаервола
- настройки приоритетов master browser (тот, кто ведет список машин), непосредственно влияет на вывод smbtree
- настройки анонимного доступа к шаре IPC$ (иначе не будет списка шар для неавторизованного пользователя)
- настройки авторизации
2) на клиенте:
- настройки фаервола
- настройки авторизации
- настройки LANMAN/SMB/SMB2/SMB3/CIFS
При этом нужно отдельно различать собственно доступ к шаре (общему ресурсу) и просмотр списка доступных серверов, одно от другого зависит не очень сильно. smbtree отдаст вам список в своей рабочей группе.
Эта статья по сути будет подборкой «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, а также следите за выходом исправлений: исправляются разведанные баги достаточно быстро.
Заключение
Итак, мы разобрали методологию поиска и решения проблем Samba. Проблемы были разнесены по уровням, и каждый уровень зависит от успешной работоспособности более низкого уровня. Еще раз взглянем на них:
•Уровень 1. Сетевое соединение и работоспособный smb.conf.
•Уровень 2. Серверное и клиентское ПО.
•Уровень 3. Удаленный доступ к ресурсам.
•Уровень 4. Сетевое окружение.
•Уровень 5. Логи и анализ трафика.
•Уровень 6. Внутренние проблемы Samba.
Не стоит забывать, что, возможно, с вашей проблемой уже кто-то сталкивался. В этом случае просмотр профильных форумов и других ресурсов может вам сэкономить драгоценное время. Не зацикливайтесь на единственно возможной по вашему мнению причине. Постарайтесь посмотреть на проблему с другой точки зрения. В конце концов решение любой проблемы может быть найдено!
Примерно начиная с версии Samba 4.10 команда smbtree не находит никаких доступных ресурсов, не выдавая при этом никакой диагностики, при этом команда smbclient -L ресурсы конкретных машин отображает правильно. Кроме этого, команды smbtree и smbclient ещё и запрашивают пароль для текущего пользователя при каждом выполнении, чего ранее не было.
Запрос пароля при выполнении команд smbtree/smbcient отключается опцией -N:
Настройки различаются для серверов Samba и для клиентов, при этом любой компьютер может быть одновременно и сервером и клиентом, то есть указанные далее настройки могут применяться совместно.
Для обнаружения разделяемых ресурсов используется протокол NT1 (он же CIFS), по умолчанию отключенный как устаревший. Указанные ниже настройки позволяют использовать этот протокол, однако следует помнить, чото протокол устарел и подвержен уязвимостям.
На серверах
Для того, чтобы новые серверы samba корректно отвечали на запросы нужно в файл /etc/samba/smb.conf в секцию [global] на сервере Samba добавить параметр:
После чего перезагрузить конфигурацию сервера:
sudo smbcontrol smbd reload-config |
Samba (версии 4.9 и выше, более старые версии не проверялись) по умолчанию привязывается ко всем обнаруженным интерфейсам. Если на сервере samba установлена система виртуализации (проверено с Oracle VirtualBox и с KVM), то samba привязывается и к адаптерам виртуальных мостов, после чего samba в виртуальной подсети сама среди себя проводит выборы мастер-браузера, объявляет себя мастером и перестаёт видеть разделяемые ресурсы на физическом сетевом интерфейсе. Характерный симптом - после команды
sudo systemctl restart nmbd |
Чтобы этого избежать нужно в секцию [global] конфигурационного файла /etc/samba/smb.conf добавить указание, с какими интерфейсами работать, и запрет работать с другими интерфейсами (интерфейс lo - локальная обратная петля, второй интерфейс задан адресом подсети):
После чего перезапустить сервисы:
sudo systemctl restart smbd nmbd |
Побочный эффект - команда smbtree, выполненная на сервере, при этом перестаёт показывать собственные ресурсы, хотя свой сервер показывает. |
При выполнении команды smbtree samba-клиент пытается разрешить NETBIOS-имя собственного сервера. Порядок разрешения имён по умолчанию:
- lmhosts - файл /etc/samba/lmhosts, samba-аналог файла /etc/hosts, которого обычно нет;
- wins - WINS-сервер, которого тоже обычно нет;
- hosts - файл /etc/hosts, в котором для машины обычно указан адрес локальной обратной локальной петли 127.0.1.1;
В стандартном /etc/hosts имя сервера разрешается в 127.0.1.1, по этому адресу запрашивается список ресурсов, однако сервер samba привязан не к 127.0.1.1, а к 127.0.0.1, соответственно никаких ресурсов не видно.
Для того чтобы smbtree показывал собственные ресурсы имя сервера должно разрешаться в адрес сетевого интерфейса, к которому привязана samba - проще всего указать адрес в /etc/hosts.
Привязать samba к адресу 127.0.1.1 не получилось, видимо потому, что это адрес виртуальный.
По умолчанию служба samba (smbd) использует только авторизацию NTLM2. При этом некоторые старые компьютеры Windows, выступая в роли клиентов samba, не могут получить доступ к разделяемым ресурсам samba. В такой ситуации:
В первую очередь следует изучить возможность включить авторизации NTLM2 на клиенте. В большинстве случаев ОС Windows с установленными обновлениями может поддерживать авторизацию NTLM2.
Протокол авторизации на сервере samba выбирается параметром ntlm auth, по умолчанию разрешающим только авторизацию NTLM2:
Первым шагом снижения версии протокола проверить работоспособость варианта:
В этом варианте если клиент не поддерживает авторизацию NTLM2, то допускается авторизация NTLM1 при условии использования протокола MSCHAPv2, в котором устранены некоторые уязвимости протокола MSCHAPv1;
Следующим шагом понижения версии протокола является безусловное разрешение авторизации NTLM1:
На серверах
Для того, чтобы новые серверы samba корректно отвечали на запросы нужно в файл /etc/samba/smb.conf в секцию [global] на сервере Samba добавить параметр:
После чего перезагрузить конфигурацию сервера:
Samba (версии 4.9 и выше, более старые версии не проверялись) по умолчанию привязывается ко всем обнаруженным интерфейсам. Если на сервере samba установлена система виртуализации (проверено с Oracle VirtualBox и с KVM), то samba привязывается и к адаптерам виртуальных мостов, после чего samba в виртуальной подсети сама среди себя проводит выборы мастер-браузера, объявляет себя мастером и перестаёт видеть разделяемые ресурсы на физическом сетевом интерфейсе. Характерный симптом - после команды
Чтобы этого избежать нужно в секцию [global] конфигурационного файла /etc/samba/smb.conf добавить указание, с какими интерфейсами работать, и запрет работать с другими интерфейсами (интерфейс lo - локальная обратная петля, второй интерфейс задан адресом подсети):
После чего перезапустить сервисы:
Побочный эффект - команда smbtree, выполненная на сервере, при этом перестаёт показывать собственные ресурсы, хотя свой сервер показывает.
При выполнении команды smbtree samba-клиент пытается разрешить NETBIOS-имя собственного сервера. Порядок разрешения имён по умолчанию:
- lmhosts - файл /etc/samba/lmhosts, samba-аналог файла /etc/hosts, которого обычно нет;
- wins - WINS-сервер, которого тоже обычно нет;
- hosts - файл /etc/hosts, в котором для машины обычно указан адрес локальной обратной локальной петли 127.0.1.1;
В стандартном /etc/hosts имя сервера разрешается в 127.0.1.1, по этому адресу запрашивается список ресурсов, однако сервер samba привязан не к 127.0.1.1, а к 127.0.0.1, соответственно никаких ресурсов не видно.
Для того чтобы smbtree показывал собственные ресурсы имя сервера должно разрешаться в адрес сетевого интерфейса, к которому привязана samba - проще всего указать адрес в /etc/hosts.
Привязать samba к адресу 127.0.1.1 не получилось, видимо потому, что это адрес виртуальный.
По умолчанию служба samba (smbd) использует только авторизацию NTLM2. При этом некоторые старые компьютеры Windows, выступая в роли клиентов samba, не могут получить доступ к разделяемым ресурсам samba. В такой ситуации:
В первую очередь следует изучить возможность включить авторизации NTLM2 на клиенте. В большинстве случаев ОС Windows с установленными обновлениями может поддерживать авторизацию NTLM2.
Далее описано снижение версии протокола авторизации на сервере samba, понижающее защищенность информационой системы.
Протокол авторизации на сервере samba выбирается параметром ntlm auth, по умолчанию разрешающим только авторизацию NTLM2:
Первым шагом снижения версии протокола проверить работоспособость варианта:
В этом варианте если клиент не поддерживает авторизацию NTLM2, то допускается авторизация NTLM1 при условии использования протокола MSCHAPv2, в котором устранены некоторые уязвимости протокола MSCHAPv1;
Следующим шагом понижения версии протокола является безусловное разрешение авторизации NTLM1:
На клиентах
Для того, чтобы команда smbtree корректно запрашивала разделяемые ресурсы можно в параметрах команды принудительно указать протокол:
Для того, чтобы клиенты samba всегда использовали протокол NT1 и корректно запрашивали разделяемые ресурсы нужно в файл /etc/samba/smb.conf на клиентском компьютере в секцию [global] добавить параметр:
После этого запросы к серверам samba версии 4.9 будут отправляться и отрабатываться корректно, запросы к настроенным по умолчанию серверам версии 4.11 и новее будут завершаться ошибкой вида:
smbtree -N
\\CE-2-13-3-1115 Samba 4.12.5-Debian
smbXcli_negprot_smb1_done: No compatible protocol selected by server.
На клиентах
Для того, чтобы команда smbtree корректно запрашивала разделяемые ресурсы можно в параметрах команды принудительно указать протокол:
smbtree -N "--option=client min protocol=NT1" |
Для того, чтобы клиенты samba всегда использовали протокол NT1 и корректно запрашивали разделяемые ресурсы нужно в файл /etc/samba/smb.conf на клиентском компьютере в секцию [global] добавить параметр:
После этого запросы к серверам samba версии 4.9 будут отправляться и отрабатываться корректно, запросы к настроенным по умолчанию серверам версии 4.11 и новее будут завершаться ошибкой вида:
\\CE-2-13-3-1115 Samba 4.12.5-Debian
smbXcli_negprot_smb1_done: No compatible protocol selected by server.
Ссылки вне экспортируемого дерева
В настройках samba, принимаемых по умолчанию для ALD задан параметр wide links = yes (следовать ссылкам вне экспортируемого дерева) , который, из соображений безопасности, не работает в сочетании с другим принятым по умолчанию параметром unix extensions = yes. Чтобы эти параметры работали совместно нужно добавить пареметр allow insecure wide links = yes.
Разрешение следовать ссылкам вне экспортируемого дерева снижает защищённость системы повышая риск утечки или повреждения данных.
Использование smbtree в Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.5)
Для того, чтобы команда smbtree в ОС Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.5) (samba_3.6.26) начала отображать свои и чужие разделяемые ресурсы в секцию [global] на клиенте 1.5 нужно добавить параметр:
Отключение подписания запросов возвращает уязвимость CVE-2016-2115: Samba 3.x and 4.x before 4.2.11, 4.3.x before 4.3.8, and 4.4.x before 4.4.2 does not require SMB signing within a DCERPC session over ncacn_np, which allows man-in-the-middle attackers to spoof SMB clients by modifying the client-server data stream.
Запрос пароля при выполнении команд smbtree/smbcient отключается опцией -N:
Настройки различаются для серверов Samba и для клиентов, при этом любой компьютер может быть одновременно и сервером и клиентом, то есть указанные далее настройки могут применяться совместно.
Для обнаружения разделяемых ресурсов используется протокол NT1 (он же CIFS), по умолчанию отключенный как устаревший. Указанные ниже настройки позволяют использовать этот протокол, однако следует помнить, чото протокол устарел и подвержен уязвимостям. |
Ссылки вне экспортируемого дерева
В настройках samba, принимаемых по умолчанию для ALD задан параметр wide links = yes (следовать ссылкам вне экспортируемого дерева) , который, из соображений безопасности, не работает в сочетании с другим принятым по умолчанию параметром unix extensions = yes. Чтобы эти параметры работали совместно нужно добавить пареметр allow insecure wide links = yes.
Разрешение следовать ссылкам вне экспортируемого дерева снижает защищённость системы повышая риск утечки или повреждения данных.
Использование smbtree в Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.5)
Для того, чтобы команда smbtree в ОС Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.5) (samba_3.6.26) начала отображать свои и чужие разделяемые ресурсы в секцию [global] на клиенте 1.5 нужно добавить параметр:
Отключение подписания запросов возвращает уязвимость CVE-2016-2115: Samba 3.x and 4.x before 4.2.11, 4.3.x before 4.3.8, and 4.4.x before 4.4.2 does not require SMB signing within a DCERPC session over ncacn_np, which allows man-in-the-middle attackers to spoof SMB clients by modifying the client-server data stream.
Читайте также: