NFS v4 export encrypted partition. Client mounts empty dir

Question

I have an encrypted hard drive on my Lan Server. It was encrypted using luks/dm-crypt. The server has a NFS v4 running to share files in the Lan. It works, except for the encrypted USB hard drive. If the client mounts the shares into his file system, he finds an empty folder where the decrypted files should be.

This is the setup:

How the server mounts the luks partition:

sudo cryptsetup luksOpen /dev/sdb1 data1
sudo mount /dev/mapper/data1 /exports/user1/data1

Decrypting and mounting the drive on the server works fine. If I go to /exports/user1/data1 I get the decrypted files.

The NFS exports:

/exports            192.168.178.20(rw,sync,fsid=0,no_subtree_check,root_squash) 192.168.178.21(rw,sync,fsid=0,no_subtree_check,root_squash)
/exports/user1      192.168.178.20(rw,sync,no_subtree_check,root_squash) 192.168.178.21(rw,sync,no_subtree_check,root_squash)

So the decrypted USB drive is mounted right into the NFS exports at /exports/user1/data1

And this is how the client mounts the shared folder:

sudo mount.nfs4 192.168.178.10:/ /fs_data -o soft,intr,rsize=32768,wsize=32768

Now, if the client mounts the server exports into his file system, he finds the 'data1' folder empty.

Is there anything I'm missing?

Update:

Thanks to Gilles great answer I got it working. I tried to avoid crossmnt and nohide to not run into eventual inode problems. This is what I use now:

/etc/exports

/exports/user1           192.168.178.20(rw,sync,fsid=0,crossmnt,no_subtree_check)
/exports/user1/data1     192.168.178.20(rw,sync,no_subtree_check)

client command to mount data1:

sudo mount.nfs4 192.168.178.10:/data1 /fs_data -o soft,intr,rsize=32768,wsize=32768

Answer 1

With the Linux kernel NFS server, if you export a directory tree, this does not include any filesystems mounted on that tree. See the description of the nohide option in the exports(5) man page.

You need to export the mounted filesystem explicitly, i.e. you need a separate line in exports for /exports/user1/data1. Furthermore you'll need to (re)start the NFS server after mounting /exports/user1/data1.

On the client side, you need to mount /fs_data/data1 separately. As discussed in the exports man page, you can avoid this by including the nohide option on /exports/users1/data1, or the crossmnt option on /exports/users1, but this can cause trouble because the client will see files with the same inode number on what appears to be the same filesystem. This can, for example, lead a file copy or archiving program to omit files because it thinks it's already backed them up (if the program has seen /fs_data/foo with inode 42, it'll think that the unrelated file /fs_data/data1/bar with inode 42 on what appears to be the same filesystem — but actually isn't — is the same file).

Answer 2

I can't comment for lack of points so I'll add that I haven't had to restart the nfs server after adding the additional file system to /etc/exports, that would be a pain since I use kernel nfs, instead I only need to do another exportfs -a and it exports the newly specified export.