Discussion:
Bug#873073: samba: smbd starts before interface is ready, listening only on localhost when "bind to interfaces only = yes"
(too old to reply)
Timo Sigurdsson
2017-08-24 09:20:01 UTC
Permalink
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>
SATOH Fumiyasu
2017-08-28 05:00:02 UTC
Permalink
Have you tried systemd-networkd-wait-online.service(8)
or ifupdown-wait-online.service?
--
-- Name: SATOH Fumiyasu @ OSS Technology Corp. (fumiyas @ osstech co jp)
-- Business Home: http://www.OSSTech.co.jp/
-- GitHub Home: https://GitHub.com/fumiyas/
-- PGP Fingerprint: BBE1 A1C9 525A 292E 6729 CDEC ADC2 9DCA 5E1C CBCA
Timo Sigurdsson
2017-08-30 08:50:01 UTC
Permalink
Dear Fumiyasu,
Post by SATOH Fumiyasu
Have you tried systemd-networkd-wait-online.service(8)
Not really. I tried it briefly yesterday and the unit fails as it requires networkd.service which is not by default enabled in Debian Stretch. So, that doesn't help unless I migrate to networkd which I'm reluctant to do at this point.
Post by SATOH Fumiyasu
or ifupdown-wait-online.service?
I don't have such a unit on my system. Searching the package repository for it shows it's currently only available in sid.

Regards,

Timo
Niccolo Rigacci
2017-12-27 08:30:01 UTC
Permalink
Package: samba
Version: 2:4.5.12+dfsg-2+deb9u1
Followup-For: Bug #873073

Dear Maintainer,

I confirm the problem on a host upgraded from Jessie to Stretch.
As a workaround, I added an "up" option to the /etc/network/interfaces:

allow-hotplug eth0
iface eth0 inet dhcp
ethernet-wol g
up /bin/systemctl restart smbd.service || true


-- System Information:
Debian Release: 9.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.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+deb9u2
ii libtalloc2 2.1.8-1
ii libtdb1 1.3.11-2
ii libtevent0 0.9.31-1
ii libwbclient0 2:4.5.12+dfsg-2+deb9u1
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.12+dfsg-2+deb9u1
ii python2.7 2.7.13-2+deb9u2
ii samba-common 2:4.5.12+dfsg-2+deb9u1
ii samba-common-bin 2:4.5.12+dfsg-2+deb9u1
ii samba-libs 2:4.5.12+dfsg-2+deb9u1
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.12+dfsg-2+deb9u1
ii samba-vfs-modules 2:4.5.12+dfsg-2+deb9u1

Versions of packages samba suggests:
pn bind9 <none>
pn bind9utils <none>
pn ctdb <none>
pn ldb-tools <none>
ii ntp 1:4.2.8p10+dfsg-3+deb9u1
pn smbldap-tools <none>
pn ufw <none>
pn winbind <none>

-- debconf information:
samba-common/title:
samba/run_mode: daemons
Dark Penguin
2019-07-14 13:00:02 UTC
Permalink
This issue is still present in Buster.

Changing the interface name to its IP address in smb.conf does not make
sense because we're talking about a situation when your IP address is
managed by DHCP.

Tweaking the systemd service files does not help according to the OP,
and even if it did, this is not a solution - network-online.target
apparently still does not work.

Mathieu, is there a bug report with more details about the
network-online.target problem? It looks pretty serious since it can
potentially break all network-based daemons, and is still not fixed in
Buster.
--
darkpenguin
Mathieu Parent
2019-07-15 13:40:02 UTC
Permalink
Post by Dark Penguin
This issue is still present in Buster.
Changing the interface name to its IP address in smb.conf does not make
sense because we're talking about a situation when your IP address is
managed by DHCP.
Tweaking the systemd service files does not help according to the OP,
and even if it did, this is not a solution - network-online.target
apparently still does not work.
Mathieu, is there a bug report with more details about the
network-online.target problem? It looks pretty serious since it can
potentially break all network-based daemons, and is still not fixed in
Buster.
Have you considered tuning /etc/default/networking ?

For example:
WAIT_ONLINE_METHOD="ifup"
WAIT_ONLINE_IFACE="enp2s0"
WAIT_ONLINE_ADDRESS=""
WAIT_ONLINE_TIMEOUT=300

or:
WAIT_ONLINE_METHOD="ping"
WAIT_ONLINE_IFACE=""
WAIT_ONLINE_ADDRESS="128.31.0.62"
WAIT_ONLINE_TIMEOUT=300

See also /lib/ifupdown/wait-online.sh

What is the content of /etc/network/interfaces?

Regards
--
Mathieu Parent
Dark Penguin
2019-07-21 21:10:02 UTC
Permalink
Oh, there was a file like that?.. ^_^

Ooohkay, this has revealed something interesting.

In /etc/default/networking, it says:

# Which interface to wait for.
# If none given, wait for all auto interfaces, or if there are none,
# wait for at least one hotplug interface.
#WAIT_ONLINE_IFACE=

I have two interfaces: "auto lo" and "allow-hotplug eth0". So, in my
case, by default it waits for lo, and then the network is assumed to be
up. (Apparently "if there are none" includes lo, which makes little sense.)

Changing this to "auto eth0" has fixed the smbd problem!

I remember having read somewhere that "allow-hotplug implies auto", so I
usually change eth0 to allow-hotplug without expecting any consequences
of this kind. Turns out that with "allow-hotplug", the system does not
wait for the interface to come up at boot, that's why samba starts
without it.

Changing it back to "auto" fixes this problem, but introduces another
one. For some reason, DHCP address acquisition takes 5 to 8 seconds, so
the downside is adding 8 seconds to the system boot time.



So, to sum it up:

- If you are running a samba server, then either run it on an "auto"
interface, or restart it after configuring a hotplug interface by adding
this line in the interface's definition:

up /bin/systemctl restart smbd.service nmbd.service || true

This actually makes sense. If you reconfigure a hotplug interface, you'd
probably want to restart everything that is supposed to listen on it.

(Come to think about it, why doesn't sshd have this problem?.. Maybe
because it listens on 0.0.0.0 ?.. Specifying 0.0.0.0/0 as an interface
to listen on in smb.conf does not help.)

- Still, it would be nice to fix samba so that it does not try to bind
to nonexistent interfaces (even though it is not even asked to), and
does not output a high-level uninformative error message when it fails
to do that. This would allow us to not worry about IPv6 and not see the
strange red error message at the same time. It could probe those
interfaces if it wants to bind to all of them, but a negative probing
result is expected, and is not a high-level error.
Post by Mathieu Parent
Post by Dark Penguin
This issue is still present in Buster.
Changing the interface name to its IP address in smb.conf does not make
sense because we're talking about a situation when your IP address is
managed by DHCP.
Tweaking the systemd service files does not help according to the OP,
and even if it did, this is not a solution - network-online.target
apparently still does not work.
Mathieu, is there a bug report with more details about the
network-online.target problem? It looks pretty serious since it can
potentially break all network-based daemons, and is still not fixed in
Buster.
Have you considered tuning /etc/default/networking ?
WAIT_ONLINE_METHOD="ifup"
WAIT_ONLINE_IFACE="enp2s0"
WAIT_ONLINE_ADDRESS=""
WAIT_ONLINE_TIMEOUT=300
WAIT_ONLINE_METHOD="ping"
WAIT_ONLINE_IFACE=""
WAIT_ONLINE_ADDRESS="128.31.0.62"
WAIT_ONLINE_TIMEOUT=300
See also /lib/ifupdown/wait-online.sh
What is the content of /etc/network/interfaces?
Regards
--
darkpenguin
Dark Penguin
2019-07-14 13:10:01 UTC
Permalink
This particular case could be less of a problem (at least to me) if
adding "bind interfaces only = yes" was not the only way to disable IPv6
in samba.

Would it make sense to change the priority of an error message on
startup about missing IPv6 support? If samba sees that IPv6 is not
supported on this system, shouldn't it deduce that it is therefore not
required, and output an "info" message like "Not binding to IPv6 -
protocol not supported" instead of an error?
--
darkpenguin
Mathieu Parent
2019-07-15 14:00:02 UTC
Permalink
Post by Dark Penguin
This particular case could be less of a problem (at least to me) if
adding "bind interfaces only = yes" was not the only way to disable IPv6
in samba.
Would it make sense to change the priority of an error message on
startup about missing IPv6 support? If samba sees that IPv6 is not
supported on this system, shouldn't it deduce that it is therefore not
required, and output an "info" message like "Not binding to IPv6 -
protocol not supported" instead of an error?
Have you tried overriding with:

cat /etc/systemd/system/smbd.service
[Service]
RestrictAddressFamilies=AF_UNIX AF_INET

(then systemctl daemon-reload and systemctl restart smbd)

(Not tested...)

Regards
--
Mathieu Parent
Dark Penguin
2019-07-21 19:50:01 UTC
Permalink
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.
Post by Mathieu Parent
Post by Dark Penguin
This particular case could be less of a problem (at least to me) if
adding "bind interfaces only = yes" was not the only way to disable IPv6
in samba.
Would it make sense to change the priority of an error message on
startup about missing IPv6 support? If samba sees that IPv6 is not
supported on this system, shouldn't it deduce that it is therefore not
required, and output an "info" message like "Not binding to IPv6 -
protocol not supported" instead of an error?
cat /etc/systemd/system/smbd.service
[Service]
RestrictAddressFamilies=AF_UNIX AF_INET
(then systemctl daemon-reload and systemctl restart smbd)
(Not tested...)
Regards
--
darkpenguin
Mathieu Parent
2019-07-24 19:20:02 UTC
Permalink
Version: 2:4.9.5+dfsg-5
I'm closing this bug with the version in buster.
Post by Dark Penguin
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
Address family not supported by protocol". This error message is not
even decipherable without Google's help.
interfaces = lo 0.0.0.0
bind to interfaces only = yes
Regards
Umm... I've actually tried that before.
Confirmed with:
interfaces = 127.0.0.0/8 0.0.0.0
bind interfaces only = yes


$ sudo ss -lntp | grep smbd
LISTEN 0 50 127.0.0.1:445
0.0.0.0:* users:(("smbd",pid=9146,fd=32))
LISTEN 0 50 127.0.0.1:139
0.0.0.0:* users:(("smbd",pid=9146,fd=33))
--
Mathieu Parent
Dark Penguin
2019-07-24 23:40:01 UTC
Permalink
Post by Mathieu Parent
Version: 2:4.9.5+dfsg-5
I'm closing this bug with the version in buster.
Post by Dark Penguin
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
Address family not supported by protocol". This error message is not
even decipherable without Google's help.
interfaces = lo 0.0.0.0
bind to interfaces only = yes
Regards
Umm... I've actually tried that before.
interfaces = 127.0.0.0/8 0.0.0.0
bind interfaces only = yes
$ sudo ss -lntp | grep smbd
LISTEN 0 50 127.0.0.1:445
0.0.0.0:* users:(("smbd",pid=9146,fd=32))
LISTEN 0 50 127.0.0.1:139
0.0.0.0:* users:(("smbd",pid=9146,fd=33))
We should probably reopen this then?..
--
darkpenguin
Mathieu Parent
2019-07-25 06:30:02 UTC
Permalink
Control: clone -1 -2
Control: retitle -2 smbd No way to bind to IPv4 only
Control: severity -2 wishlist
Control: reopen -2
Control: tags -2 confirmed upstrea
Post by Dark Penguin
Post by Mathieu Parent
Version: 2:4.9.5+dfsg-5
I'm closing this bug with the version in buster.
Post by Dark Penguin
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
Address family not supported by protocol". This error message is not
even decipherable without Google's help.
interfaces = lo 0.0.0.0
bind to interfaces only = yes
Regards
Umm... I've actually tried that before.
interfaces = 127.0.0.0/8 0.0.0.0
bind interfaces only = yes
$ sudo ss -lntp | grep smbd
LISTEN 0 50 127.0.0.1:445
0.0.0.0:* users:(("smbd",pid=9146,fd=32))
LISTEN 0 50 127.0.0.1:139
0.0.0.0:* users:(("smbd",pid=9146,fd=33))
We should probably reopen this then?..
The current bug is about samba service depending on network.

I'm cloning this bug to another, about IPv4-only binding.

Regards
--
Mathieu Parent
Loading...