Your message dated Tue, 23 Jul 2019 23:15:30 +0200
with message-id
<CAFX5sbxwyg=NKSudgg=cjeMVLL=5vlhzr2ebmrbz0gxdcjz...@mail.gmail.com>
and subject line Re: [Pkg-samba-maint] Bug#873073: Other ways to disable IPv6 ?
has caused the Debian Bug report #873073,
regarding samba: smbd starts before interface is ready, listening only on
localhost when "bind to interfaces only = yes"
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
873073: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873073
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: samba
Version: 2:4.5.8+dfsg-2+deb9u1+b1
Severity: normal
Dear Maintainer,
I noticed that adding the smb.conf options
interfaces = lo enp2s0
bind to interfaces only = yes
renders samba unusable.
What happens is that smbd is being started too early (before my ethernet
interface enp2s0 is ready), so it only listens on the loopback device but
not enp2s0. Thus, smbd won't respond to any connections by clients. My
ethernet interface is configured via DHCP.
The issue is easily resolved by restarting smbd after the system is up and
running, which also shows the configuration itself is ok.
So, as a temporary workaround to the issue I added the following job to my
root crontab to restart smbd after every reboot with a delay of 15 seconds:
@reboot sleep 15 && systemctl -q restart smbd.service
With this samba works fine and binds to the loopback address as well as the
address of my enp2s0 interface.
This is, however, neither a real nor neat solution to the issue, of course.
First of all, I would have expected the dhclient-scripts to take care of
reloading smbd when the interface is ready. And while I do see in the logs
that smbd is being reloaded via dhclient-scripts, this also happens too early
apparently. Secondly, I'm surprised to see that the systemd unit file for
smbd is set to start after network.target but not network-online.target.
The nmbd unit is set to wait for the latter. In practice, this won't make
much of a difference in most scenarios since smbd waits for nmbd, but there
are setups where you don't need nmbd (see #429429) so having smbd wait for
network-target.online would actually make more sense to me. (Note: On this
installation I do have nmbd running as well.)
So, I tried the following approaches to resolve this issue - without any
luck:
1) Moving /etc/dhcp/dhclient-enter-hooks.d/samba to the exit-hooks directory,
as I hoped that would trigger the reload action later. It didn't work.
It seems the dhclient-exit-hooks are called to early as well and smbd
can't bind to enp2s0 just yet.
2) I had added "network-online.target" to the "After=" list and into "Wants="
in the systemd unit file. It didn't help either.
Please note that I have encountered this issue on two seperate machines and
even two architectures (amd64 and armhf). In both cases DHCP is used to
configure the network interfaces. Both machines run fresh installs of Debian
Stretch and were not upgraded from Jessie.
Regards,
Timo
-- System Information:
Debian Release: 9.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages samba depends on:
ii adduser 3.115
ii dpkg 1.18.24
ii init-system-helpers 1.48
ii libbsd0 0.8.3-1
ii libc6 2.24-11+deb9u1
ii libldb1 2:1.1.27-1+b1
ii libpam-modules 1.1.8-3.6
ii libpam-runtime 1.1.8-3.6
ii libpopt0 1.16-10+b2
ii libpython2.7 2.7.13-2
ii libtalloc2 2.1.8-1
ii libtdb1 1.3.11-2
ii libtevent0 0.9.31-1
ii libwbclient0 2:4.5.8+dfsg-2+deb9u1+b1
ii lsb-base 9.20161125
ii procps 2:3.3.12-3
ii python 2.7.13-2
ii python-dnspython 1.15.0-1
ii python-samba 2:4.5.8+dfsg-2+deb9u1+b1
ii python2.7 2.7.13-2
ii samba-common 2:4.5.8+dfsg-2+deb9u1
ii samba-common-bin 2:4.5.8+dfsg-2+deb9u1+b1
ii samba-libs 2:4.5.8+dfsg-2+deb9u1+b1
ii tdb-tools 1.3.11-2
ii update-inetd 4.44
Versions of packages samba recommends:
ii attr 1:2.4.47-2+b2
ii logrotate 3.11.0-0.1
ii samba-dsdb-modules 2:4.5.8+dfsg-2+deb9u1+b1
ii samba-vfs-modules 2:4.5.8+dfsg-2+deb9u1+b1
Versions of packages samba suggests:
pn bind9 <none>
pn bind9utils <none>
pn ctdb <none>
pn ldb-tools <none>
pn ntp | chrony <none>
pn smbldap-tools <none>
ii ufw 0.35-4
pn winbind <none>
--- End Message ---
--- Begin Message ---
Version: 2:4.9.5+dfsg-5
I'm closing this bug with the version in buster.
Le dim. 21 juil. 2019 à 21:45, Dark Penguin <[email protected]> a écrit :
>
> I tried this just now. The result is, basically, nothing: my kernel does
> not have IPv6 support anyway, so restricting IPv6 out on the systemd
> level does not change anything. There are still error messages about
> being unable to bind to IPv6 upon restarting smbd, however with this,
> restarting it also takes a few seconds instead of happening almost
> instantly.
>
> I guess the "proper" solution would be the same: if there are no IPv6
> interfaces in the system, smbd should not try to bind to them. If it was
> specifically instructed to bind to a certain interface and it is
> unavailable, then output an error message "This interface is requested
> but unavailable", instead of "open_socket_in(): socket() call failed:
> Address family not supported by protocol". This error message is not
> even decipherable without Google's help.
The following binds to IPv4 only:
interfaces = lo 0.0.0.0
bind to interfaces only = yes
Regards
--
Mathieu Parent
--- End Message ---
