Description of problem:
I'm facing the problem that when booting a DHCP-lease based desktop in the LAN with "interfaces = lo p37p1", the Samba service does not bind to the all addresses interface 0.0.0.0 and only does so after a simple "systemd restart smb.service":
Started Network Manager.
Starting RPC bind service...
Starting Samba SMB Daemon...
# netstat -tpan|grep smb
tcp 0 0 :::445 :::* LISTEN 1019/smbd
tcp 0 0 :::139 :::* LISTEN 1019/smbd
$ smbclient '//127.0.0.1/homes'
Connection to 127.0.0.1 failed (Error NT_STATUS_CONNECTION_REFUSED)
# systemctl restart smb.service
[root@localhost ~]# netstat -tpan|grep smb
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 1918/smbd
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 1918/smbd
tcp 0 0 :::445 :::* LISTEN 1918/smbd
tcp 0 0 :::139 :::* LISTEN 1918/smbd
$ smbclient '//127.0.0.1/homes'
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.6.0-73.fc16]
smb: \> quit
Version-Release number of selected component (if applicable):
# rpm -qa samba\*
This is with SELinux set to permissive (because of current targeted policy's problems with nmbd among others).
Do we have networkmanager dispatch scripts to reload the samba and winbind configuration after a restart?
Exactly the same problem here !
FC16, i386, upgrade from FC15.
On every start / reboot, no Samba.
A NetworkManager script solves the problem.
Could you send me the NetworkManager script?
Additional Info to reproduce:
i setup 2 maschines (both maschines have 2 NIC's)completly new FC16 with updates.
systemctl status smb.service (active)
systemctl status nmd.service (active)
systemctl status winbind.service (active)
connect to samba share see only empty folders.
if i stop all samba services systemctl stop smb.service etc. maybe kill the PID smbd manually
Start the Samba Service manual with smbd -i .. the shares works fine.
i check the systemd start scripts /lib/systemd/system/smb... but i doesent see a difference. i think a problem could be the NetworkManager or the 2 Network interfaces. i hope this infos are useful. sorry for the breaky english. :-)
Well, the script is very simple.
It's called 15-samba, and is placed in /etc/NetworkManager/dispatcher.d/
case "$2" in
/bin/systemctl restart smb.service || :
/bin/systemctl restart nmb.service || :
Good luck, Alfred.
Thank you for the script.
But my Main Problem is not solved. a restart of the services is not the solution.
if i stop the service with systemctl stop smb.service then start manually with "smbd -i" the share works..
messages from the log.smbd:
Copyright Andrew Tridgell and the Samba Team 1992-2011
[2011/12/09 10:34:02.497715, 0] smbd/server.c:1101(main)
standard input is not a socket, assuming -D option
thanks for helping..
Instead of '/bin/systemctl restart smb.service' you should use 'smbcontrol smbd reload'
*** Bug 759798 has been marked as a duplicate of this bug. ***
Also OpenSWAN (IPSEC) does not startup correctly after boot / reboot.
IPSEC starts before NetworkManager has been able to initialize the external interface. External interface is not seen and cannot be added during startup.
A restart after boot solves this problem.
This can be accomplished by a NetworkManager script.
This also impact services as:
This is, since i've upgraded to FC16.
It seems to me that no network availability at time of starting these services is the source of this problem.
If i login after the start up process and manually (re)start the failed services they do not fail.
Sorry about comment # 10
I have solved that by executing:
"systemctl enable NetworkManager-wait-online.service"
Which enables starting other services to wait for NetworkManager to be started.
This also helps the smb, nmb and winbind services to start without failing.
Doesn't a "systemctl enable NetworkManager-wait-online.service" solve this problems for any one else than me?
Works for me.
Thanks for posting the solution Eddie. I really appreciate you posting it. I'm surprized this topic isn't closed.
Well, Jack, "the solution" is a work-around, but will the packages work by default with Fedora 18, 17, or 16? Or will it be necessary to run the work-around manually?
In Fedora 18 I have the same problem, nmbd and cups won't succesfully start on boot but do start correctly when started later on the command line. I do have NetworkManager-wait-online.service enabled but somehow that doesn't help.
Dennis Verspuij: could you please file a bug report against cups? I haven't seen that behaviour here and I'd like to track down what the problem might be.
Hi Tim. I am not sure if nmb and cups are really significant in this problem. I investigated a little further. My system has two NIC's, one for WAN and one for LAN. De NetworkManager-wait-online.service finishes as soon as one of them is (partially) up. Because I specifically bound nmd and cupsd to the LAN network (not their defaults localhost or all interfaces) there is still the chance the LAN is not available yet. And und fortunately that is 100% of the time for me.
A fix would be to be able to configure NetworkManager-wait-online service to wait for a specific interface and addressing type to complete, e.g. eth1 + IPV4. E.g. in a file /etc/sysconfig/NetworkManager-wait-online. I think bug #837793 is very relevant.
(In reply to comment #17)
> Dennis Verspuij: could you please file a bug report against cups? I haven't
> seen that behaviour here and I'd like to track down what the problem might
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 16's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" and open it against that version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
I think this issue is still current so should move to Fedora 18, please see my earlier comments.
I've tried to reproduce this with F18 and everything works just fine if smbd listens to 0.0.0.0 (everything).
I've install samba on my notebook and activated it with:
systemctl enable smb.service
Then rebooted the machine. It comes up but no ip addresses assigned. Then I connected to my wifi and after that I was able to access smbd from my desktop machine.
desktop$ smbclient -U% -L //192.168.1.2
Domain=[DISCWORLD] OS=[Unix] Server=[Samba 4.0.3]
Sharename Type Comment
--------- ---- -------
profiles Disk Network Profiles Service
users Disk All users
groups Disk All groups
print$ Disk Printer Drivers
guru Disk GURU ACL Test
IPC$ IPC IPC Service (Samba 4.0.3)
After that I enabled nmbd with:
systemctl enable nmb.service
and rebooted my notebook. I connected to my wifi and looked up the netbios name on my desktop.
desktop$ nmblookup -S krikkit
querying krikkit on 192.168.52.255
querying krikkit on 192.168.178.255
Looking up status of 192.168.178.52
KRIKKIT <00> - B <ACTIVE>
KRIKKIT <03> - B <ACTIVE>
KRIKKIT <20> - B <ACTIVE>
DISCWORLD <00> - <GROUP> B <ACTIVE>
DISCWORLD <1c> - B <ACTIVE>
DISCWORLD <1e> - <GROUP> B <ACTIVE>
MAC Address = 00-00-00-00-00-00
Everything works as expected.
Please let's not change history. The original bug report was about F16 in 2011, not about F18. I haven't checked whether the problem was reproducible when F17 (or F18) was released. With F18 I see NetworkManager-wait-online here, but haven't used Samba with F18 yet.
Sorry. I didn't need or use NetworkManager-wait-online at all. Everything worked just fine without it.