Этой заметкой открываю рубрику Samba, в которой буду описывать неочевидные нюансы работы сего продукта – заменителя файлового сервера для Windows-сетей. На этот раз юзеры не могли достучаться до файлохранилища по имени (оно было PDC), только по IP-адресу. Сразу стало ясно – беда с WINS-сервером.
WINS – сервис, позволяющий сопоставлять NetBIOS-имена компьютеров (символьные имена) с IP-адресами (древний Win-аналог системы DNS). В Samba за его работу отвечает демон nmbd, слушает 137 и 138 UDP-порты. Широковещательный NetBIOS-запрос, к примере, в системе Ubuntu делается таким образом:
$ nmblookup pdc querying pdc on 10.0.0.255 Sending a packet of len 50 to (10.0.0.255) on port 137 Sending a packet of len 50 to (10.0.0.255) on port 137 Sending a packet of len 50 to (10.0.0.255) on port 137 name_query failed to find name pdc
Как видим, у нас ничего не получилось. Теперь залезем на сервер и посмотрим, что там происходит:
# sockstat | grep nmbd root nmbd 30924 4 dgram -> /var/run/logpriv root nmbd 30924 10 udp4 *:137 *:* root nmbd 30924 11 udp4 *:138 *:* root nmbd 30924 12 udp4 10.0.0.1:137 *:* root nmbd 30924 13 udp4 10.0.255.255:137 *:* root nmbd 30924 14 udp4 10.0.0.1:138 *:* root nmbd 30924 15 udp4 10.0.255.255:138 *:*
Вроде бы все нормально, но замечаем, что клиент отправляет широковещательный запрос в подсеть 10.0.0.0/24, а nmbd слушает 10.0.255.255. Оказывается, дело было вот в чем:
# ifconfig re0: flags=8943metric 0 mtu 1500 options=389b ether 01:02:03:04:05:06 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.255.255 media: Ethernet autoselect (100baseTX ) status: active
Осталось только поменять маску подсети:
# ifconfig re0 10.0.0.1 netmask 255.255.255.0
и все встало на свои места:
$ nmblookup pdc Socket opened. querying pdc on 10.0.0.255 Got a positive name query response from 10.0.0.1 ( 10.0.0.1 ) 10.0.0.1 pdc<00>