ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
coreutils (Fedora) |
Fix Released
|
High
|
|||
coreutils (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
Medium
|
Matthew Ruffell |
Bug Description
[Impact]
Issuing a 'ls -l' or a 'stat' on an autofs share when you have set --ghost in the auto.master file, or browse_mode=yes in autofs.conf will lead to the shares being mounted, when they didn't previously.
Disks / shares may not be present and the mounts may fail, leading to errors in your output.
This is a behaviour change in autofs 8.32, which occurred in the transition to using statx() instead of stat()/lstat() in previous releases.
There doesn't seem to be any workarounds, apart from not running a 'ls -l' in your autofs share directory.
[Testcase]
Start two Jammy VMs. One will be a NFS server, the other, the client.
NFS server:
Server VM:
$ sudo hostnamectl set-hostname jammy-nfs-server
$ sudo apt update && sudo apt upgrade -y
$ sudo apt install nfs-kernel-server
$ sudo mkdir /export
$ sudo mkdir /export/users
$ sudo vi /etc/exports # add the following lines:
/export 192.168.
/export/users 192.168.
$ sudo systemctl restart nfs-server.service
AutoFS Client:
$ sudo apt update
$ sudo apt install autofs
$ sudo vim /etc/autofs.conf
browse_mode = yes
$ sudo mkdir /mnt2
$ sudo vim /etc/auto.master
/mnt2 /etc/auto.indirect
$ sudo vim /etc/auto.indirect
export 192.168.
export-missing 192.168.
$ sudo reboot
$ cd /mnt2
$ ls -l
ls: cannot access 'export-missing': No such file or directory
total 4
drwxr-xr-x 3 root root 4096 Feb 12 21:48 export
d????????? ? ? ? ? ? export-missing
$ mount -l | grep /mnt2
/etc/auto.indirect on /mnt2 type autofs (rw,relatime,
192.168.
We see the mount for export occurred, and export-missing was attempted, but it was either bogus or the disk was not present, leading to a "No such file or directory" error.
There are test packages available in the following ppa:
https:/
If you install them, this is what should occur:
$ ls -l
total 0
drwxr-xr-x 2 root root 0 Feb 12 22:01 export
drwxr-xr-x 2 root root 0 Feb 12 22:01 export-missing
$ mount -l | grep /mnt2
/etc/auto.indirect on /mnt2 type autofs (rw,relatime,
No mounts happen, and no errors either.
[Where problems could occur]
We are changing the behaviour of core utilities, ls and stat, such that they no longer attempt to mount autofs shares when --ghost option is present or browse_mode is enabled.
This is the intended behaviour in the first place, and has been this way for at least a decade prior, and was changed to return to this behaviour shortly after the release of coreutils that introduced statx() that caused automounts to occur.
It is unlikely any system administrators are relying on the behaviour found in jammy in any scripts or day to day operations that would be adversely affected by the change. The worst case scenario is that a user doing an 'ls -l' on an unmounted disk finds the mount doesn't automatically occur, and they have to attach the disk and issue the mount themselves.
If a regression were to occur, it would be limited to the ls and stat commands, specifically when listing directories linked to autofs mountpoints.
[Other info]
The automount behaviour change was introduced upstream in version 8.32, with the introduction of the statx() call. This means only Jammy is affected.
It was quickly reverted back to how it was originally in version 9.1, which is already available in Mantic and onward.
The commits that solve the issue are:
commit 85c975df2c25bd7
From: Rohan Sable <email address hidden>
Date: Mon, 7 Mar 2022 14:14:13 +0000
Subject: ls: avoid triggering automounts
Link: https:/
commit 92cb8427c537f37
From: Pádraig Brady <email address hidden>
Date: Mon, 7 Mar 2022 23:29:20 +0000
Subject: stat: only automount with --cached=never
Link: https:/
Upstream bugs:
https:/
https:/
tags: | added: jammy |
Changed in coreutils (Fedora): | |
importance: | Unknown → High |
status: | Unknown → Fix Released |
Changed in coreutils (Ubuntu Jammy): | |
status: | New → In Progress |
importance: | Undecided → Medium |
assignee: | nobody → Matthew Ruffell (mruffell) |
description: | updated |
tags: | added: sts-sponsor |
tags: | added: sts |
tags: | removed: sts-sponsor |
Description of problem:
Autofs mounts with --ghost or browse_mode=yes enabled, triggers a mount or shows error "ls: cannot access 'XXXX': No such file or directory" when ls -l is run
Either errors are seen for mount points which we know are inaccessible for this client or
a mount is triggered for accessible mounts.
Version-Release number of selected component (if applicable): 5.1.4-74. el8.x86_ 64 8.30-12. el8.x86_ 64
autofs-
coreutils-
(however, I am starting the bug with autofs as affected component as discussed with Ian)
How reproducible:
Always
Steps to Reproduce:
1. Upgrade to RHEL 8.5 (which should have autofs- 5.1.4-74. el8.x86_ 64 and coreutils- 8.30-12. el8.x86_ 64) 600,bg, tcp,hard, vers=3, rsize=32768, wsize=32768, timeo=600, retrans= 6
2. Create an autofs map :
~~~
[root@rsablerhel85 mnt2]# grep -i mnt /etc/auto.master
/mnt2 /etc/auto.indirect timeout=
[root@rsablerhel85 mnt2]# cat /etc/auto.indirect /testshare <<<<< testshare is a valid export from server /testshare2 <<<<< testshare2 is not available to this client or could be a bogus entry
testshare rsable76server:
testshare2 rsable76server:
~~~
3. Either use --ghost in auto.master as an option or set browse_mode=yes :
~~~
[root@rsablerhel85 mnt2]# grep -i browse /etc/autofs.conf
# browse_mode - maps are browsable by default.
browse_mode = yes
~~~
4. Cd to /mnt2 and run ls -l / ll.
Note : this issue occurs irrespective of direct or indirect maps.
Actual results:
Mount is triggered and ll throws ENOENT for testshare2
~~~
[root@rsablerhel85 mnt2]# ll
ls: cannot access 'testshare2': No such file or directory <<<<< Error
total 0
drwxrwxrwx. 3 1000 1000 15 Jan 17 12:08 testshare <<<<< mount is triggerd for testshare
d?????????? ? ? ? ? ? testshare2 <<<<< Path we know that is inaccessible throws an error
[root@rsablerhel85 mnt2]# mount | grep -i test /testshare on /mnt2/testshare type nfs (rw,relatime, vers=3, rsize=32768, wsize=32768, namlen= 255,hard, proto=tcp, timeo=600, retrans= 6,sec=sys, mountaddr= 192.168. 122.58, mountvers= 3,mountport= 20048,mountprot o=tcp,local_ lock=none, addr=192. 168.122. 58)
rsable76server:
~~~
Expected results:
Mount should not be trigger and error "ls: cannot access 'testshare2': No such file or directory"
should not be seen.
Additional info:
I think the issue is with a behavior change in coreutils- common- 8.30-12. el8. common- 8.30-8. el8 this issue goes away :
Reverting back to coreutils-
~~~
[root@rsablerhel85 mnt2]# ll
ls: cannot access 'testshare2': No such file or directory
total 0
drwxrwxrwx. 3 1000 1000 15 Jan 17 12:08 testshare
d?????????? ? ? ? ? ? testshare2
[root@rsablerhel85 mnt2]# dnf downgrade coreutils- 8.30-8. el8.x86_ 64 8.30-8. el8.x86_ 64 coreutils- common- 8.30-8. el8.x86_ 64
Downgraded:
coreutils-
Complete!
[root@rsablerhel85 mnt2]# ll
total 0
drwxrwxrwx. 3 1000 1000 15 Jan 17 12:08 testshare
drwxr-xr-x. 2 root root 0 Jan 21 11:47 testshare2
~~~
I can see that coreutils- common- 8.30-12. el8 calls statx while coreutils- common- 8.30-8. el8 calls lstat :
~~~
coreutils-8.30-12
3181 12:02:13.828462 getdent...