0

FACTS

A previously-working /etc/exports file, running perfectly on Debian, fails to work as expected on Ubuntu. I can export a top-level directory; clients can mount it and see one directory level down; but they are unable to see other subdirectories, and they cannot mount subdirectories.

DISCUSSION

First, something that works just a bit:

/archive 192.168.0.0/255.255.255.0(fsid=root,crossmnt,rw,sync,no_root_squash,no_subtree_check)

The fsid=root is mandatory, apparently -- not so on Debian -- and crossmnt is there for testing.

I can mount /archive on a client. I can descend to /archive/dir1. However, when clients try to read the directory /archive/dir1, the directory shows as empty.

Next I try a two-line version of /etc/exports:

/archive 192.168.0.0/255.255.255.0(fsid=root,crossmnt,rw,sync,no_root_squash,no_subtree_check)
/archive/dir1/dir2/dir3 192.168.0.0/255.255.255.0(rw,sync,no_root_squash,no_subtree_check)

The first line is the same as previously, and the 2nd line exports a subdirectory as a separate entity. Again, this works just fine when exported from Debian.

At this point, any attempt to mount /archive/dir1/dir2/dir3 fails. On a Debian client, the client attempts to use NFS version 4.2, complaints of a stale file handle, falls back to version 3, and cycles on version 3 endlessly.

On an Ubuntu client, an attempt to mount fails with "Stale file handle" using NFS version 4; falls back to version 3 and cycles between protocols 6 and 17; and eventually fails.

Please note: * All clients are behind the same firewall * No machine is running an internal firewall (e.g., ufw is disabled or off)

rpcinfo on the server:

# rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp  51505  mountd
    100005    1   tcp  33248  mountd
    100005    2   udp  59490  mountd
    100005    2   tcp  46113  mountd
    100005    3   udp  59750  mountd
    100005    3   tcp  38367  mountd
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049
    100227    3   tcp   2049
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049
    100227    3   udp   2049
    100021    1   udp  55501  nlockmgr
    100021    3   udp  55501  nlockmgr
    100021    4   udp  55501  nlockmgr
    100021    1   tcp  37597  nlockmgr
    100021    3   tcp  37597  nlockmgr
    100021    4   tcp  37597  nlockmgr

rpcinfo on the client:

   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049
    100227    3   tcp   2049
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049
    100227    3   udp   2049
    100021    1   udp  56523  nlockmgr
    100021    3   udp  56523  nlockmgr
    100021    4   udp  56523  nlockmgr
    100021    1   tcp  37425  nlockmgr
    100021    3   tcp  37425  nlockmgr
    100021    4   tcp  37425  nlockmgr
    100024    1   udp  39290  status
    100024    1   tcp  37851  status
    100005    1   udp  52528  mountd
    100005    1   tcp  43547  mountd
    100005    2   udp  36593  mountd
    100005    2   tcp  34609  mountd
    100005    3   udp  42349  mountd
    100005    3   tcp  45613  mountd

Finally,

RPCMOUNTDOPTS="--manage-gids"

in /etc/default/nfs-kernel-server

EDIT

A possible symptom is that /var/lib/nfs/rmtab is not up to date. I expect when nfs-kernel-server is stopped, rmtab would be updated; or when I unexport the filesystems (exportfs -ua); or when I unmount at the client. Instead, rmtab continues to maintain the stale information.

ACTIONS

I'd like suggestions on how to debug this problem.

EDIT 2

A few more points:

  1. I've checked the ACLs (none set) and the file permissions, and they appear to be correct.
  2. Even after a cold shutdown of both client and server, done for other reasons, I still get "stale file handle" errors.
  3. If I enable rpcdebug to look for NFS proc, I see a complaint about

    no callback path to client Linux NFSv4.2

but that error does not appear for, e.g., MacOS or Ubuntu clients.

  1. I have experimented with absolutely minimalist /etc/exports, but none work. For example,

    /something *(sync,no_subtree_check)

does not work.

Summary: this problem remains intractable, and IMO it's not a simple permissions problem -- unless I'm missing a setting somewhere, or even an entire program or configuration file.

0

After extensive trial and error, I discovered what appears to be the reason for the failure. Looking at /archive, I noticed I had a subdirectory of the same name, that is, there was a /archive/arhive.

When I deleted the /archive/archive my problems stopped for the most part. Based on contents and of permissions of what I saw, the export of /archive was actually exporting /archive/archive.

Going a bit further: I've noticed that when I export /archive the client mounts as NFS version 4. When I mount a subdirectory, namely /archive/dir1/dir2/dir3, that subdirectory (same drive and therefor same filesystem) mounts as version 3! I'm still chasing this down, but in the mean time I am up and running.

If this "subdirectory with same name causes bad mount" requires a bug report, I can reproduce this at will and write one up.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.