The goal of this article is to assist in setting up an nfs-server for sharing files over a network.
- For NFSv4, see: NFSv4
- nfs-utils has been upgraded since 2009-06-23, and NFS4 support is now implemented. Refer to the news bulletin.
- portmap has been replaced by rpcbind.
- 1 Required packages
- 2 Setting up the server
- 3 Setting up the client
- 4 Troubleshooting
- 4.1 Unreliable performance, slow data transfer, and/or high load when using NFS and gigabit
- 4.2 Portmap daemon fails to start at boot
- 4.3 Nfsd fails to start with "nfssvc: No such device"
- 4.4 Nfsd seems to work, but I cannot connect from MacOS X clients
- 4.5 mount.nfs: Operation not permitted
- 4.6 Ownership of mounted shares is 4294967294:4294967294
- 5 Links and references
Required packages for both the server and the client are minimal. You will only need to install:
# pacman -S nfs-utils rpcbind
Setting up the server
You can now edit your configuration and then start the daemons.
This file defines the various shares on the nfs server and their permissions. A few examples:
/files *(ro,sync) # Read-only access to anyone /files 192.168.0.100(rw,sync) # Read-write access to a client on 192.168.0.100 /files 192.168.1.1/24(rw,sync) # Read-write access to all clients from 192.168.1.1 to 192.168.1.255
If you make changes to /etc/exports after starting the daemons, you can make them effective by issuing the following command:
# exportfs -r
If you decide to make your NFS share public and writable, you can use the all_squash option in combination with anonuid and the anongid option. For example, to set the privileges for the user nobody in the group nobody, you can do the following:
; Read-write access to a client on 192.168.0.100, with rw access for the user 99 with gid 99 /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99))
This also means, that if you want write access to this directory, nobody.nobody must be the owner of the share directory:
# chown -R nobody.nobody /files
Full details on the exports file are provided by the exports man page.
Edit this file to pass appropriate run-time options to nfsd, mountd, statd, and sm-notify. The default Arch NFS init scripts require the --no-notify option for statd, as follows:
Others may be left at the provided defaults, or changed according to your requirements. Please refer to the relevant man pages for full details.
You can now start the server with the following commands:
# rc.d start rpcbind (or: rc.d start portmap) # rc.d start nfs-common (or: rc.d start nfslock) # rc.d start nfs-server (or: rc.d start nfsd)
Please note that they must be started in that order. To start the server at boot time, add these daemons to the DAEMONS array in /etc/rc.conf.
Setting up the client
Edit this file to pass appropriate run-time options to statd - the remaining options are for server use only. Do not use the --no-notify option on the client side, unless you are fully aware of the consequences of doing so.
Please refer to the statd man page for full details.
Start the rpcbind and nfs-common daemons:
rc.d start rpcbind (or: rc.d start portmap) rc.d start nfs-common (or: rc.d start nfslock)
Please note that they must be started in that order or start only nfs-common, as rpcbind will be started as a dependency.
To start the daemons at boot time, add them to the DAEMONS array in /etc/rc.conf.
Then just mount as normal:
mount server:/files /files
Unlike CIFS shares or rsync, NFS exports must be called by the full path on the server; example, if /home/fred/music is defined in /etc/exports on server ELROND, you must call:
mount ELROND:/home/fred/music /mnt/point
instead of just using:
mount ELROND:music /mnt/point
or you will get mount.nfs: access denied by server while mounting
Mounting using cifs
Mounting using cifs works a bit differently then using NFS. First, you need to have a share defined on your server in Samba. For that look at the Samba article. Lets say you made a share on "ELROND" with the name "music". To mount that share using cifs a command like the following should work
mount -t cifs -v ELROND:music /mnt/point -o guest,iocharset=utf8
You can try:
mount -t cifs -v ELROND:music /mnt/point
Or to login with a username and password:
mount -t cifs -v ELROND:music /mnt/point -o username=USERNAME,password=PASSWORD,iocharset=utf8
Auto-mount on boot
If you want to mount on boot, make sure network, rpcbind (portmap), nfs-common (nfslock) and netfs are in the DAEMONS array in /etc/rc.conf. Make sure the order is this one. It is better not to put any '@' in front of them (although you could safely use @netfs); for instance:
DAEMONS=(... network rpcbind nfs-common @netfs ...)
DAEMONS=(... network portmap nfslock @netfs ...)
Add an appropriate line in /etc/fstab, for example:
server:/files /files nfs defaults 0 0
If you wish to specify a packet size for read and write packets, specify them in your fstab entry. The values listed below are the defaults if none are specified:
server:/files /files nfs rsize=32768,wsize=32768 0 0
Read the nfs man page for further information, including all available mount options.
Unreliable performance, slow data transfer, and/or high load when using NFS and gigabit
Verify that the async flag is used in Template:Filename Example:
/nfs4exports 192.168.0.0/24(ro,fsid=0,no_subtree_check,async) /nfs4exports/data 192.168.0.0/24(rw,no_subtree_check,async,nohide) /nfs4exports/backup 192.168.0.0/24(rw,no_subtree_check,async,nohide)
This is a result of the default packetsize used by NFS, which causes significant fragmentation on gigabit networks. You can modify this behavior by the rsize and wsize mount parameters. Using rsize=32768,wsize=32768 should suffice. Please note that this problem does not occur on 100Mb networks, due to the lower packet transfer speed.
Default value for NFS4 is 32768. Maximum is 65536. Increase from default in increments of 1024 until maximum transfer rate is achieved.
Portmap daemon fails to start at boot
Make sure you place portmap before netfs in the daemons array in /etc/rc.conf.
Nfsd fails to start with "nfssvc: No such device"
Make sure the nfs and nfsd modules are loaded in the kernel.
Nfsd seems to work, but I cannot connect from MacOS X clients
When trying to connect from a MacOS X client, you will see that everything is ok at logs, but MacOS X refuses to mount your NFS share. You have to add Template:Codeline option to your share and re-run Template:Codeline.
mount.nfs: Operation not permitted
After updating to nfs-utils 1.2.1-2, mounting NFS shares stopped working. Henceforth, nfs-utils uses NFSv4 per default instead of NFSv3. The problem can be solved by using either mount option
'nfsvers=3' on the command line:
# mount.nfs <remote target> <directory> -o ...,vers=3,... # mount.nfs <remote target> <directory> -o ...,nfsvers=3,...
<remote target> <directory> nfs ...,vers=3,... 0 0 <remote target> <directory> nfs ...,nfsvers=3,... 0 0
The following two values in /etc/conf.d/nfs-common.conf (on the client) need to be set:
Links and references
- See also Avahi, a Zeroconf implementation which allows automatic discovery of NFS shares.
- HOWTO: Diskless network boot NFS root
- Very helpful
- If you are setting up the Archlinux NFS server for use by Windows clients through Microsoft's SFU, you will save a lot of time and hair-scratching by looking at this forum post first !
- Microsoft Services for Unix NFS Client info
- Unix interoperability and Windows Vista Prerequisites to connect to NFS with Vista