NFS¶

Practical 6.3 nfs-annex.pdf · PDF

Samba asked every person for a name and a password. Now imagine fifty Linux machines in a company, all needing the same project folder the moment they start, with nobody at the keyboard. Who types fifty passwords at 8:00 in the morning?

Nobody. There is another door into the building, built for machines instead of people. It is fast, it is simple, and it trusts in a way that will surprise you: on this page you will make the server write "joan" on a file that Joan never touched.

The staff door¶

NFS (Network File System) is a protocol that makes a directory of another machine appear inside your own directory tree, so programs do not notice the difference.

It was created by Sun Microsystems in 1984 for its Unix workstations. The protocol was published openly (version 2 as RFC 1094, in 1989), so every Unix copied it. Today's version 4 uses a single port: TCP 2049.

Remember the building with four doors from the Samba file server page. NFS is a staff door at the back. There is no reception. The guard only looks at which van arrives (the address of the client machine), and then believes the badge number each person shows. No password.

flowchart LR
    subgraph SAMBA ["Front door: Samba"]
        direction TB
        P["<b>a person</b>"] --> R["<b>reception</b><br>user + password"] --> D1["the files"]
    end
    subgraph NFS ["Staff door: NFS"]
        direction TB
        V["<b>a machine</b><br>shows a badge number (UID)"] --> G["<b>guard</b><br>is this van on my list?"] --> D2["the files"]
    end

Two verbs:

• The server exports a directory: it offers it to certain machines, with one line in /etc/exports.
• The client mounts it on a folder of its own tree: exactly the mount from Unit 4, with server:/path in the place of /dev/sdb1.

The export line¶

/srv/nfs/projects 192.168.122.0/24(rw,sync,no_subtree_check)

No space between the network and the bracket. You will see why further down.

Export and mount¶

On the server:

sudo apt install nfs-kernel-server
sudo mkdir -p /srv/nfs/projects
echo "/srv/nfs/projects 192.168.122.0/24(rw,sync,no_subtree_check)" \
  | sudo tee -a /etc/exports
sudo exportfs -ra
sudo exportfs -v

/srv/nfs/projects
        192.168.122.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,root_squash,no_all_squash)

exportfs -ra re-reads /etc/exports; exportfs -v shows what is really exported. There are more options than you wrote: the defaults. Keep two of them in mind for later: sec=sys and root_squash.

On the client (deb-lab):

sudo apt install nfs-common
showmount -e ubu-srv
sudo mkdir -p /mnt/projects
sudo mount ubu-srv:/srv/nfs/projects /mnt/projects
df -hT /mnt/projects

showmount -e lists what the server exports; df -hT shows the type nfs4. Now try to write:

touch /mnt/projects/test.txt
sudo touch /mnt/projects/test.txt

Both fail with Permission denied, even with sudo. The export says rw. Why? Make a guess before reading on.

Numbers, not names¶

First, the two doors again. rw in the export is door 3: the machine may write. Door 4 is still the file system: /srv/nfs/projects belongs to root, mode 755. You are not its owner, so you cannot write. The stricter door wins, as on the Share permissions page.

But how does the server know who "you" are, with no password? The client sends a number: your UID (user ID). That is what sec=sys means.

Names are never sent. If number 1003 arrives, the server writes "joan" on the file, whoever sent it. Give the folder to your own number on the server (sudo chown 1000 /srv/nfs/projects) and touch works from the client. Then compare:

ls -ln /mnt/projects    # numbers: the same on both machines
ls -l /mnt/projects     # names: each machine shows its own name for that number

The same file can show two different owner names, one per machine.

Root squash¶

And root, UID 0? Whoever is root on the client would be root on the server's files. So the server changes 0 into the UID of a user with no rights, nobody (65534). This is root squash, and it is on by default. That is why sudo touch failed too.

The badge experiment¶

On the server, make a folder only Joan can enter (mkdir -m 700, chown joan) and read Joan's number with id -u joan. On the client, create a user with the same number:

sudo useradd -u NUMBER visitor
sudo -u visitor touch /mnt/projects/joan-only/hello.txt

On the server, sudo ls -l /srv/nfs/projects/joan-only shows hello.txt owned by joan. Joan was never there. The server believed the badge number.

How do real companies keep the numbers equal on every machine? One central list of users for all machines: a directory, a domain. And for networks you do not control, NFS has a mode with real proof of identity (Kerberos). Both come back later in this unit.

Mount it at boot¶

What is mounted by hand is gone after a reboot. Add one line at the end of /etc/fstab on the client:

ubu-srv:/srv/nfs/projects  /mnt/projects  nfs  defaults,_netdev,nofail  0  0

• _netdev = "this needs the network: wait for it".
• nofail = "if the server is off, boot anyway". Without it, a client can stop at boot because a server is down: the classic way to break twenty PCs with one line.

Test before rebooting:

sudo umount /mnt/projects
sudo systemctl daemon-reload
sudo mount -a
findmnt /mnt/projects

If mount -a complains, the boot would too: fix it first. findmnt should show the source ubu-srv:/srv/nfs/projects and type nfs4, also after a reboot.

The space trap¶

A read-only export for documents. Look at these two lines:

/srv/nfs/docs 192.168.122.0/24(ro,sync,no_subtree_check)
/srv/nfs/docs 192.168.122.0/24 (ro,sync,no_subtree_check)

One space of difference. With the first one, writing from the client gives Read-only file system, a different message from Permission denied: this time the export said no. With the second one:

exportfs: No options for /srv/nfs/docs 192.168.122.0/24: suggest 192.168.122.0/24(sync) to avoid warning
exportfs: No host name given with /srv/nfs/docs (ro,sync,no_subtree_check), suggest *(ro,sync,no_subtree_check) to avoid warning
$ sudo exportfs -v
/srv/nfs/docs   192.168.122.0/24(sync,...,ro,root_squash,no_all_squash)
/srv/nfs/docs   <world>(sync,...,ro,root_squash,no_all_squash)

With the space there are two rules: our network with the default options, and <world> (every machine that can reach the server) with the options in the bracket. Had the bracket said rw, the whole world could write. And exportfs only printed a warning.

SMB or NFS?¶

The question that decides: who are the clients, and who must be identified, people or machines? Tramuntana's answer is both: Samba for the people's department folders, NFS for the project tree of the Linux machines.

Key takeaways¶

• NFS (Sun, 1984, TCP 2049) lets a server export a directory that clients mount into their own tree.
• An export is one line in /etc/exports: directory, allowed network, options in brackets with no space. exportfs -ra applies it, exportfs -v shows it.
• By default NFS trusts the client machine and the UID number it sends; names are never sent. Root squash turns the client's root into nobody.
• rw in the export only lets the machine try: the file system still decides for each UID.
• At boot, mount it in /etc/fstab with _netdev,nofail, and test with mount -a before rebooting.
• SMB identifies people on mixed PCs; NFS shares a tree between Linux machines you administer.

Quick check¶

Files are shared. One more thing in every office is shared, and it always causes a queue. Next: Print server.