Для include до версии 4.16 работало, а теперь не работает. man smb.conf, раздел VARIABLE SUBSTITUTIONS %i the local IP address to which a client connected. Before 4.0.0 it could contain IPv4 mapped IPv6 addresses, now it only contains IPv4 or IPv6 addresses Похожие баги апстрима для других переменных: https://bugzilla.samba.org/show_bug.cgi?id=15243 https://bugzilla.samba.org/show_bug.cgi?id=15255
Версия - samba-4.20.4-alt1 Шаги воспроизведения На сервере (от рута): echo 'net.ipv6.conf.all.disable_ipv6 = 1' >> /etc/sysctl.conf sysctl -f mkdir -p /data/$(ip route get 1.2.3.4 | awk '{print $7}' | xargs) chmod 777 -R /data/ echo "include = /etc/samba/smb-%i.conf" >> /etc/samba/smb.conf cat >> /etc/samba/smb-$(hostname -i).conf <<'EOF' [client_data] comment = Client Data path = /data/%i browseable = yes writable = yes force directory mode = 0770 force create mode = 0660 create mask = 0660 directory mask = 0770 EOF systemctl restart samba testparm На клиенте: smbclient -L dc -U testuser Ожидаемый результат: client_data в списке Enter SAMBA\testuser's password: Sharename Type Comment --------- ---- ------- media Disk media sysvol Disk netlogon Disk SHARE Disk Share directory for AD users client_data Disk Client Data IPC$ IPC IPC Service (Samba 4.14.10) Фактический результат: client_data нет в списке Password for [SAMBA\testuser]: Sharename Type Comment --------- ---- ------- media Disk media sysvol Disk netlogon Disk SHARE Disk Share directory for AD users IPC$ IPC IPC Service (Samba 4.20.4-alt1) Воспроизводится в P10 Не воспроизводится в P9: версия samba-4.14.10-alt2
(Ответ для GordeevM на комментарий #0) Исходя из финальной части вот этой задачи, получается, что проблема только в отображении: > https://bugzilla.samba.org/show_bug.cgi?id=15255#c8 > ... > substitution is working correctly > files all loaded and parsed correctly > shares accessible but not visible. > ... Давайте определимся со следующим: 0) Можно ли сказать, что 4.16.10 и старше проблема имеет место быть только в плане отображения - "shares accessible but not visible"? 1) Насколько данное поведение воспроизводится в последних релизах. Например, на 4.20.4 и старше? 2) В какой степени целесообразно подключаться к исправлению данной проблемы отображения шары доступной только для заданного ip-адреса? 3) Насколько это исправление актуально для ipv6? Исправление только для ipv4 выглядит полумерой, а для полноценного исправления необходимо строить стенды с ipv6. ______________ Если пункт 0) подтверждается, то данная проблема выглядит общей и на фоне множества других проблем не приоритетной. По мере появления ресурсов к ней можно вернуться, но в ближайшее время заниматься ей можно только опционально.
Если сосвсем коротко, работать перестало это: /etc/samba/browseable-no.conf browseable = no available = no /etc/samba/browseable-yes.conf browseable = yes available = yes в /etc/samba stat ./browseable-yes-A.B.C.D.conf Файл: ./browseable-yes-A.B.C.D.conf -> browseable-yes.conf где A.B.C.D - адрес интерфейса сервера для доступа без ограничений. в /etc/samba/smb.conf: include = /etc/samba/browseable-no.conf include = /etc/samba/browseable-yes-%i.conf [service1] include = /etc/samba/browseable-yes.conf ... [service2] ... [service3] ... Т.е. сначала включается запрет на видимость и доступность всех сервисов (include = /etc/samba/browseable-no.conf), затем включается видимость и доступность, если подключение к интерфейсу сервера с адресом A.B.C.D Видимость и доступность service1 безусловная, а service2 и service2 не содержат include = /etc/samba/browseable-yes.conf и доступность и видимость зависит от того интерфейса, к которому происходит подключение.
С точки зрения производительности выглядит, как необходимость запускать отдельные экземпляры smbd с разными конфигами в рантайме перечитывая дерево вложенных файлов, вычисляя всё это хозяйство для каждого отдельного ip-шника. Странно, что это, вообще, работает. А как это выглядит для ipv6? Или поддержка ipv6 не требуется? Кстати, а каково ожидание от пользователя? Получается, что один и тот же пользователь, обращаясь с разных узлов к одному и тому же серверу, должен получать разные ответы?
(Ответ для Evgeny Sinelnikov на комментарий #4) > Странно, что это, вообще, работает. А как это выглядит для ipv6? Или > поддержка ipv6 не требуется? Работает хорошо. ipv6 не требуется. > Кстати, а каково ожидание от пользователя? Получается, что один и тот же > пользователь, обращаясь с разных узлов к одному и тому же серверу, должен > получать разные ответы? Да, именно так, это не зависит от пользователя. Потому что на один интерфейс сервера приходит трафик из сетей, откуда должно быть видно всё, а на другой интерфейс сервера приходит трафик из сети, откуда только ограниченный набор сервисов должен быть виден.
(Ответ для zvn на комментарий #5) [...] > Да, именно так, это не зависит от пользователя. > Потому что на один интерфейс сервера приходит трафик из сетей, откуда должно > быть видно всё, а на другой интерфейс сервера приходит трафик из сети, > откуда только ограниченный набор сервисов должен быть виден. А указывается ip-адрес клиента или интерфейса на сервере? Кто прислал запрос или на какой ip-адрес пришёл запрос?
(Ответ для Evgeny Sinelnikov на комментарий #6) > (Ответ для zvn на комментарий #5) > [...] > > Да, именно так, это не зависит от пользователя. > > Потому что на один интерфейс сервера приходит трафик из сетей, откуда должно > > быть видно всё, а на другой интерфейс сервера приходит трафик из сети, > > откуда только ограниченный набор сервисов должен быть виден. > > А указывается ip-адрес клиента или интерфейса на сервере? > Кто прислал запрос или на какой ip-адрес пришёл запрос? ... mkdir -p /data/$(ip route get 1.2.3.4 | awk '{print $7}' | xargs) ... Ну, да... ip-адрес, на который пришёл запрос. Никогда такой конфигурацией не пользовался.
> Ну, да... ip-адрес, на который пришёл запрос. Никогда такой конфигурацией не > пользовался. Непосредственно Вам не предъявляли таких требований.
