{
    "mode": "man",
    "parameter": "nfs.systemd",
    "section": "7",
    "url": "https://www.chedong.com/phpMan.php/man/nfs.systemd/7/json",
    "generated": "2026-06-15T13:13:00Z",
    "synopsis": "nfs-utils.service\nnfs-server.service\nnfs-client.target\netc",
    "sections": {
        "NAME": {
            "content": "nfs.systemd - managing NFS services through systemd.\n",
            "subsections": []
        },
        "SYNOPSIS": {
            "content": "nfs-utils.service\nnfs-server.service\nnfs-client.target\netc\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "The nfs-utils package provides a suite of systemd unit files which allow the various services\nto be started and managed.  These unit files ensure that the services are started in the cor‐\nrect  order,  and the prerequisites are active before dependant services start.  As there are\nquite  few unit files, it is not immediately obvious how best  to  achieve  certain  results.\nThe following subsections attempt to cover the issues that are most likely to come up.\n",
            "subsections": [
                {
                    "name": "Configuration",
                    "content": "The  standard  systemd  unit files do not provide any easy way to pass any command line argu‐\nments to daemons so as to configure their behavior.  In many case such configuration  can  be\nperformed  by making changes to /etc/nfs.conf or other configuration files.  When that is not\nconvenient, a distribution might provide systemd \"drop-in\" files which replace the ExecStart=\nsetting  to  start  the  program  with  different arguments.  For example a drop-in file sys‐‐\ntemd/system/nfs-mountd.service.d/local.conf containing\n[Service]\nEnvironmentFile=/etc/sysconfig/nfs\nExecStart=\nExecStart= /usr/sbin/rpc.mountd $RPCMOUNTDOPTS\nwould cause the nfs-mountd.service unit to run the rpc.mountd program using,  for  arguments,\nthe  value  given for RPCMOUNTDOPTS in /etc/sysconfig/nfs.  This allows for seamless integra‐\ntion with existing configuration tools.\n"
                },
                {
                    "name": "Enabling unit files",
                    "content": "There are three unit files which are designed to be manually enabled.  All others  are  auto‐\nmatically run as required.  The three are:\n"
                },
                {
                    "name": "nfs-client.target",
                    "content": "This  should be enabled on any host which ever serves as an NFS client.  There is lit‐\ntle cost in transparently enabling it whenever NFS client software is installed.\n"
                },
                {
                    "name": "nfs-server.service",
                    "content": "This must be enabled to provide NFS service to clients.  It starts and configures  the\nrequired daemons in the required order.\n"
                },
                {
                    "name": "nfs-blkmap.service",
                    "content": "The  blkmapd  daemon  is  only  required on NFS clients which are using pNFS (parallel\nNFS), and particularly using the blocklayout layout protocol.  If you might  use  this\nparticular extension to NFS, the nfs-blkmap.service unit should be enabled.\n\nSeveral  other  units  which might be considered to be optional, such as rpc-gssd.service are\ncareful to only start if the required configuration file exists.  rpc-gssd.service  will  not\nstart if the krb5.keytab file does not exist (typically in /etc).\n"
                },
                {
                    "name": "Restarting NFS services",
                    "content": "Most  NFS  daemons  can be restarted at any time.  They will reload any state that they need,\nand continue servicing requests.  This is rarely necessary though.\n\nWhen configuration changesare make, it can be hard to know exactly which services need to  be\nrestarted to ensure that the configuration takes effect.  The simplest approach, which is of‐\nten the best, is to restart everything.  To help with this,  the  nfs-utils.service  unit  is\nprovided.  It declares appropriate dependencies with other unit files so that\nsystemctl restart nfs-utils\nwill  restart all NFS daemons that are running.  This will cause all configuration changes to\ntake effect except for changes to mount options lists in  /etc/fstab  or  /etc/nfsmount.conf.\nMount  options  can  only  be changed by unmounting and remounting filesystem.  This can be a\ndisruptive operation so it should only be done when the value justifies the cost.   The  com‐\nmand\numount -a -t nfs; mount -a -t nfs\nshould unmount and remount all NFS filesystems.\n"
                },
                {
                    "name": "Masking unwanted services",
                    "content": "Rarely  there  may  be  a desire to prohibit some services from running even though there are\nnormally part of a working NFS system.  This may be needed to reduce system load to an  abso‐\nlute  minimum, or to reduce attack surface by not running daemons that are not absolutely re‐\nquired.\n\nThree particular services which this can apply to are rpcbind, idmapd, and rpc-gssd.  rpcbind\nis not part of the nfs-utils package, but it used by several NFS services.  However it is not\nneeded when only NFSv4 is in use.  If a site will never use NFSv3 (or  NFSv2)  and  does  not\nwant rpcbind to be running, the correct approach is to run\nsystemctl mask rpcbind\nThis  will  disable  rpcbind,  and  the various NFS services which depend on it (and are only\nneeded for NFSv3) will refuse to start, without interfering with the operation of NFSv4  ser‐\nvices.  In particular, rpc.statd will not run when rpcbind is masked.\n\nidmapd is only needed for NFSv4, and even then is not needed when the client and server agree\nto use user-ids rather than user-names to identify the owners of files.   If  idmapd  is  not\nneeded and not wanted, it can be masked with\nsystemctl mask idmapd\nrpc-gssd  is  assumed  to be needed if the krb5.keytab file is present.  If a site needs this\nfile present but does not want rpc-gssd running, it can be masked with\nsystemctl mask rpc-gssd\n"
                }
            ]
        },
        "FILES": {
            "content": "/etc/nfs.conf\n/etc/nfsmount.conf\n/etc/idmapd.conf\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "systemd.unit(5), nfs.conf(5), nfsmount.conf(5).\n\n\n\nNFS.SYSTEMD(7)",
            "subsections": []
        }
    },
    "summary": "nfs.systemd - managing NFS services through systemd.",
    "flags": [],
    "examples": [],
    "see_also": [
        {
            "name": "systemd.unit",
            "section": "5",
            "url": "https://www.chedong.com/phpMan.php/man/systemd.unit/5/json"
        },
        {
            "name": "nfs.conf",
            "section": "5",
            "url": "https://www.chedong.com/phpMan.php/man/nfs.conf/5/json"
        },
        {
            "name": "nfsmount.conf",
            "section": "5",
            "url": "https://www.chedong.com/phpMan.php/man/nfsmount.conf/5/json"
        },
        {
            "name": "NFS.SYSTEMD",
            "section": "7",
            "url": "https://www.chedong.com/phpMan.php/man/NFS.SYSTEMD/7/json"
        }
    ]
}