Description of problem: unexported mountpoint of automount is visible in nfsv4 pseudo-filesystem How reproducible: always Steps to Reproduce: 1. echo "/expdir *(rw,no_root_squash)" >/etc/exports systemctl restart nfs-server 2. create a systemd automount target and start 3. mount localhost:/ /mnt/nfsmp 4. ls -l /mnt/nfsmp Actual results: ''' ~]# ls -l /mnt/nfsmp ls: cannot access '/mnt/nfsmp/efi': No such file or directory ls: cannot access '/mnt/nfsmp/home2': No such file or directory total 0 ??????????? ? ? ? ? ? efi drwxr-xr-x. 2 root root 6 Dec 6 05:45 expdir ??????????? ? ? ? ? ? home2 ''' Expected results: ''' ~]# ls -l /mnt/nfsmp total 0 drwxr-xr-x. 2 root root 6 Dec 6 05:45 expdir ''' Reproducer: ''' yum install -y nfs-utils mkdir /home2 /expdir /mnt/nfsmp cat <<EOF >/etc/systemd/system/home2.automount [Unit] Description=EFI System Partition Automount Documentation=TBD [Automount] Where=/home2 TimeoutIdleSec=120 EOF cat <<EOF >/etc/systemd/system/home2.mount [Unit] Description=EFI System Partition Automount Documentation=TBD [Mount] What=/home Where=/home2 Type=$(stat -f -c %T /home) Options=ro,bind EOF systemctl start home2.automount echo "expdir *(rw,no_root_squash)" >/etc/exports systemctl enable nfs-server systemctl start nfs-server showmount -e localhost mount localhost:/ /mnt/nfsmp ls -l /mnt/nfsmp umount /mnt/nfsmp systemctl stop home2.automount systemctl start home2.automount '''
Created attachment 303368 [details] reproducer.sh
(In reply to JianhongYin from comment #0) > Description of problem: > unexported mountpoint of automount is visible in nfsv4 pseudo-filesystem snip ... > ''' > ~]# ls -l /mnt/nfsmp > ls: cannot access '/mnt/nfsmp/efi': No such file or directory > ls: cannot access '/mnt/nfsmp/home2': No such file or directory > total 0 > ??????????? ? ? ? ? ? efi > drwxr-xr-x. 2 root root 6 Dec 6 05:45 expdir > ??????????? ? ? ? ? ? home2 > ''' > > Expected results: > ''' > ~]# ls -l /mnt/nfsmp > total 0 > drwxr-xr-x. 2 root root 6 Dec 6 05:45 expdir > ''' So your asking where did the (apparently invalid) directories efi and home2 come from? I'm not familiar with how that shadow directory tree of exports is constructed and maintained. I think it's tied in with nfs-utils. Perhaps Steve Dixon can help?
Noting that these aren't automounter mounts, they are systemd-mounted local mounts. Sorry for the noise, Ian, I misread the bug description. I just checked on my v6.1-rc server, and actual automounted NFS mounts do not appear in that server's pseudofs.
(In reply to Chuck Lever from comment #3) > Noting that these aren't automounter mounts, they are systemd-mounted local > mounts. Sorry for the noise, Ian, I misread the bug description. I just > checked on my v6.1-rc server, and actual automounted NFS mounts do not > appear in that server's pseudofs. LOL, yeah but it has a systemd automount unit there too. But directories like that are usually just stale dentries that haven't been correctly identified and listed by readdir aren't they ...
The root cause seems to be that mountd is occasionally triggering automounts. We never want it to do that. Patch posted here: https://lore.kernel.org/linux-nfs/20221213160104.198237-1-jlayton@kernel.org/T/#u I think though that this may also demonstrate a problem in the kernel too: What we see on the wire is that the READDIR response includes the automounted directory, but it sets the rdattr_error attribute to NFS4ERR_DELAY. So, while that patch fixes the immediate issue with mountd, I think we need to consider how best to handle an -ETIMEDOUT response in this situation. Skipping the entry seems wrong. Wnat if it actually is a legit export and it's delayed for some other reason? Maybe we should fail the entire READDIR op with NFS4ERR_DELAY instead?
Kernel patch posted here: https://lore.kernel.org/linux-nfs/20221213180826.216690-1-jlayton@kernel.org/T/#u
Fix in v6.2.