5

I copied somebody's NFS server/client setup verbatim and am having trouble making sense of what's going on with it. This is the /etc/exports:

/export *(rw,fsid=0,crossmnt,insecure,async,no_subtree_check,sec=krb5p:krb5i:krb5) /export/home *(rw,insecure,async,no_subtree_check,sec=krb5p:krb5i:krb5)

Client machines use autofs to mount user home directories on demand. Here's auto.home:

* -fstype=nfs4,rw,soft,sec=krb5 192.168.0.2:/home/&

This works and works well. Still, exporting /export seems unnecessary so I commented that line out of the server config. Now automounting fails on the clients.

Questions

  1. Why does /export/home require /export to also be exported?
  2. Do the security options for /export and /export/home have to be the same?
  3. Why does auto.home read 192.168.0.2:/home/& instead of 192.168.0.2:/export/home/&? It doesn't seem like that should work at all.
Improve this question

2 Answers 2

Reset to default
1

You are using NFS version 4 (nfs4) which exports a single pseudo-filesystem rather than lots of separate filesystems.

This is specified on the NFS server in /etc/exports by fsid=0, and in your case is called /export (although it could be called anything). That is why you cannot remove that line or comment it out.

On the NFS client, this parent (in your case, /export) is seen as / (the root of the exported filesystem) which is why the automounter uses /home.

Improve this answer
2
  • Thanks! I was unfamiliar with the "pseudo filesystem" concept. I see that I have to leave /export in the config. Now I would like to add some additional exports without sec=krb5. Any thoughts on my question #2? Commented May 20, 2012 at 10:32
  • They do not have to be the same. Whether they have to be a subset (remember it is a list of options) I am not sure. Try it and see. Commented May 20, 2012 at 14:43
0

An explicit pseudo-filesystem export (that is, one with the fsid=0 option) is not actually necessary.

Going without it has two effects.

First, it changes the paths with which filesystems are exported within the pseudo-filesystem. Filesystems will simply be exported using their absolute paths. So if you tried to mount 192.168.0.2:/export/home on your client then it would have worked. And if you had mounted 192.168.0.2:/ at, say, /mnt, then you'd have been able to access the filesystem at /mnt/export/home.

Second, it means you can't configure other options for the pseudo-filesystem's export. I ran the command on a server where /home is exported, without an explicit entry for the pseudo-filesystem, after a client had mounted the /home filesystem:

$ cat /proc/fs/nfsd/exports # Version 1.1 # Path Client(Flags) # IPs /home $2001:db8::ff:1(rw,root_squash,sync,wdelay,no_subtree_check,uuid=fec4d53c:3e73d378:00000000:00000000,sec=390003) / $2001:db8::ff:1(ro,insecure,no_root_squash,sync,no_wdelay,no_subtree_check,v4root,fsid=0,sec=390003:390004:390005:1)

Note the value of the sec= option for the synthesized pseudo-filesystem export: it allows allows unauthenticated access. A client would be able to browse the pseudo-filesystem and discover the paths of exported filesystems (similar to NFSv3 which allowed unauthenticated clients to view the list of exported filesystems via MNT calls) even if they wouldn't have access to the filesystems themselves.

As far as I know, the only way to change this is to create an explicit export with fsid=root or fsid=0 and the other options you want. However, the exported directory can be empty: you don't need to bind-mount the filesystems you want to export within it.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.