Ошибка 1 при запуске testparm

Не включется общий доступ к папке

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх

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

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

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

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

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

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

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

УРОВЕНЬ 1

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

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

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

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

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

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

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

$ ping 192.168.7.135

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

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

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

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

root# ifconfig eth0 192.168.7.75 netmask 255.255.255.0 broadcast 192.168.7.255

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

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

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

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

УРОВЕНЬ 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

name_query failed to find name __Samba__

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

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

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

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

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

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

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

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

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

Failed to access NBT driver 1

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

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

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

УРОВЕНЬ 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/user::


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

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

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

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

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

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

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

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

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