Update Breaks Working Samba Installation

BillBill New or Quiet Member

We attempted to upgrade a client's SLES 12 installation to SLES12 SP5. Everything appeared to be okay until it was discovered that Samba was not running—Samba was upgraded along with the rest of the system. The newly-installed Samba version, as reported by smbd -V is 4.10.5-git.165.126b152c2383.6.2-SUSE-SLE_12-x86_64. The output from log.smbd is as follows:

[2020/05/27 20:40:44.224139,  0] ../../source3/smbd/server.c:1782(main)
smbd version 4.10.5-git.165.126b152c2383.6.2-SUSE-SLE_12-x86_64 started.
Copyright Andrew Tridgell and the Samba Team 1992-2019
[2020/05/27 20:40:44.225392,  1] ../../source3/lib/messages_dgm.c:1060(messaging_dgm_init)
messaging_dgm_init: bind failed: Permission denied

The output from log.nmbd is as follows:

    [2020/05/27 20:53:41.656254,  0] ../../source3/nmbd/nmbd.c:906(main)
      nmbd version 4.10.5-git.165.126b152c2383.6.2-SUSE-SLE_12-x86_64 started.
      Copyright Andrew Tridgell and the Samba Team 1992-2019
    [2020/05/27 20:53:41.657498,  1] ../../source3/lib/messages_dgm.c:1060(messaging_dgm_init)
      messaging_dgm_init: bind failed: Permission denied

We're quite familiar with Samba, having worked with it since the days of version 2.0, but have no clue what these errors mean.

Please advise if you can.

Thanks!

Comments

  • malcolmlewismalcolmlewis Knowledge Partner
    edited May 28

    @Bill Hi, so the samba directory permissions are ok, mount point not read only for the shares? What about the status output rather than log, if you tail the journal and also try restarting the service is there more info?

    journalctl -f
    systemctl status smbd nmbd
    systemctl restart smbd nmbd
    
  • BillBill New or Quiet Member
    edited May 28

    Here's the journal with unrelated blather removed:

    -- Logs begin at Thu 2020-05-28 13:22:18 CDT, end at Thu 2020-05-28 14:35:38 CDT. --
    May 28 13:22:18 lawsrv01 systemd-journald[158]: Runtime journal (/run/log/journal/) is currently using 8.0M.
                                                    Maximum allowed usage is set to 297.4M.
                                                    Leaving at least 446.2M free (of currently available 2.8G of space).
                                                    Enforced usage limit is thus 297.4M, of which 289.4M are still available.
    May 28 13:22:18 lawsrv01 kernel: Linux version 4.12.14-122.20-default (geeko@buildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Fri 
    
    ...
    
    May 28 14:30:01 lawsrv01 systemd[1]: Started Session 7 of user root.
    May 28 14:35:38 lawsrv01 systemd[1]: Starting Samba NMB Daemon...
    May 28 14:35:38 lawsrv01 systemd[1]: nmb.service: Main process exited, code=exited, status=1/FAILURE
    May 28 14:35:38 lawsrv01 systemd[1]: Failed to start Samba NMB Daemon.
    May 28 14:35:38 lawsrv01 systemd[1]: nmb.service: Unit entered failed state.
    May 28 14:35:38 lawsrv01 systemd[1]: nmb.service: Failed with result 'exit-code'.
    May 28 14:35:38 lawsrv01 systemd[1]: Starting Samba SMB Daemon...
    May 28 14:35:38 lawsrv01 systemd[1]: smb.service: Main process exited, code=exited, status=1/FAILURE
    May 28 14:35:38 lawsrv01 systemd[1]: Failed to start Samba SMB Daemon.
    May 28 14:35:38 lawsrv01 systemd[1]: smb.service: Unit entered failed state.
    May 28 14:35:38 lawsrv01 systemd[1]: smb.service: Failed with result 'exit-code'.
    

    Here's what systemctl status smbd nmbd had to say after the above attempted start:

    ● smb.service - Samba SMB Daemon
       Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; vendor preset: disabled)
       Active: failed (Result: exit-code) since Thu 2020-05-28 14:35:38 CDT; 11min ago
      Process: 2001 ExecStart=/usr/sbin/smbd --foreground --no-process-group $SMBDOPTIONS (code=exited, status=1/FAILURE)
      Process: 1996 ExecStartPre=/usr/share/samba/update-apparmor-samba-profile (code=exited, status=0/SUCCESS)
     Main PID: 2001 (code=exited, status=1/FAILURE)
    
    May 28 14:35:38 lawsrv01 systemd[1]: Starting Samba SMB Daemon...
    May 28 14:35:38 lawsrv01 systemd[1]: smb.service: Main process exited, code=exited, status=1/FAILURE
    May 28 14:35:38 lawsrv01 systemd[1]: Failed to start Samba SMB Daemon.
    May 28 14:35:38 lawsrv01 systemd[1]: smb.service: Unit entered failed state.
    May 28 14:35:38 lawsrv01 systemd[1]: smb.service: Failed with result 'exit-code'.
    
    ● nmb.service - Samba NMB Daemon
       Loaded: loaded (/usr/lib/systemd/system/nmb.service; enabled; vendor preset: disabled)
       Active: failed (Result: exit-code) since Thu 2020-05-28 14:35:38 CDT; 11min ago
      Process: 1990 ExecStart=/usr/sbin/nmbd --foreground --no-process-group $NMBDOPTIONS (code=exited, status=1/FAILURE)
     Main PID: 1990 (code=exited, status=1/FAILURE)
    
    May 28 14:35:38 lawsrv01 systemd[1]: Starting Samba NMB Daemon...
    May 28 14:35:38 lawsrv01 systemd[1]: nmb.service: Main process exited, code=exited, status=1/FAILURE
    May 28 14:35:38 lawsrv01 systemd[1]: Failed to start Samba NMB Daemon.
    May 28 14:35:38 lawsrv01 systemd[1]: nmb.service: Unit entered failed state.
    May 28 14:35:38 lawsrv01 systemd[1]: nmb.service: Failed with result 'exit-code'.
    

    Nothing in the shared directory tree was changed in any way. smb.conf is as it was before the upgrade. As I said, it was a working Samba installation until the upgrade.

    Incidentally, who was it that thought systemd and a binary journal was a good idea? :)

    Thanks for any help you can offer. We reverted the installation to SLES 11 SP4 so the client would have a functioning system.

  • malcolmlewismalcolmlewis Knowledge Partner

    Hi
    I wonder if it's apparmor....

    /usr/share/samba/update-apparmor-samba-profile 
    

    Can you check the above file, may disable apparmor temporarily...

  • BillBill New or Quiet Member

    Thanks for your reply.

    I didn't think to check AppArmor because we do not enable it on our builds. So it could be the upgrade enabled AppArmor, which I do know from past experience will get in Samba's way when using the SuSE Samba build. We will check it out on our next visit to the client, which likely won't be for a few days.

  • BillBill New or Quiet Member
    edited June 6

    Problem solved! It turns out it wasn't AppArmor that was causing the trouble.

    During the upgrade, the Ethernet adapter (eth0) bound to Samba was "magically" configured for both IPv4 and IPv6—IPv6 had been previously disabled, as it wasn't needed on the LAN.  I recalled from past experience that such an arrangement would confuse Samba, and the clue that that was the problem was right in front of me in the logs (...messaging_dgm_init: bind failed: Permission denied). Disabling IPv6 was all it took to get Samba up and running.

    BTW, systemd sucks big time. Shame on you, SuSE, for going that route.

Sign In or Register to comment.