NFS issues after reboot

OES 2015 SP1 server upgraded to OES 2018 SP1.  Running GroupWise 18.  GroupWise Disaster Recovery is backing up the GroupWise server.  It needs NFS access to the GroupWise server.  All was fine while on 2015.  Since upgrading to 2018, backups will fail if the GroupWise server gets rebooted.  So far the only fix I have found is to go to yast > network services > nfs server.  I select next and verify the settings, then finish and quit.  Then DR is able to connect and complete the backup.  I am assuming there is some service or something that is getting started when I go through the yast process, but I haven't been able to figure out what it might be.  "nfs-server.service" is already enabled.  Any suggestions?

  • Hi Ken

    I think

    - OES2015 is based on SLES11SP4 and init, OES2018SP1 is based on SLES12SP3 ans systemd, services are starting parallel with systemd

    - nfs-server is failing start, because NFS-Share points to a directory on NSS-Volume, but it is not mounted at this time --> systemctl --failed   --> shows failed services after bootup

    we have configured dependencies of nfs-server:


    Description=NFS server and services
    Requires= proc-fs-nfsd.mount media-nss-[VOLUME-NAME].mount
    Requires= nfs-mountd.service
    Wants=rpc-statd.service nfs-idmapd.service media-nss-[VOLUME-NAME].mount

    Reconfigure systemd with: systemctl daemon-reload

    After startup of server, nfs-server starts after mounting volume and you should be fine.


  • Errata: use "systemctl reenable nfs-server.service" instead of systemctl deamon-reload
  • Steps I actually took were to copy /usr/lib/systemd/system/nfs-server.service.d/nfsserver.conf to /etc/systemd/system/nfs-server.service.d/nfsserver.conf

    Then edited /etc/systemd/system/nfs-server.service.d/nfsserver.conf  - adding the lines that  recommended with the appropriate volume name.

    Then ran "systemctl reenable nfs-server.service" as mentioned in the follow-up post.

    Looks like that solved it.  Thanks!

  •    I spoke too soon.  That did not solve it.  I did not realize that nfs-server.service had not started due to a dependency issue.  nfs-mountd.service was not running, so nfs-server.service did not start.  I manually started nfs-mountd and then I was able to start nfs-server.

    So my only concern is that I cannot enable nfs-mountd.service.  If I try, it still stays listed as static.  How do I ensure that nfs-mountd will start?

  • Does it work if you just restart the nfs daemon once logged in after reboot? If so, it's still possible to execute stuff via /etc/init.d/after.local

    The process is somewhat "re-routed" via "after-local.service" (note the dash ), you might want to check

    systemctl is-enabled after-local

    While this "solution" would be rather dirty it's merely a "fire and forget" one, and you wouldn't have to tamper with daemon files which might get overwritten by updates.


  • Not sure...I need to setup a quick test server because I can't keep rebooting my production GroupWise server.

  • Tell the users they've been migrated to Exchange  and you'll have unlimited reboots without complaints.