[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
This bug was fixed in the package coreutils - 8.32-4.1ubuntu1.2 --- coreutils (8.32-4.1ubuntu1.2) jammy; urgency=medium * Fix an issue where running 'ls -l' on an autofs mount with '--ghost' or 'browse_mode=yes' enabled causes the mount to be attempted, even when the underlying storage is not available. This changes behaviour of ls back to what it was previously, before statx was introduced in 8.32. (LP: #2033892) - d/p/lp2033892-01-ls-avoid-triggering-automounts.patch - d/p/lp2033892-02-stat-only-automount-with-cached-never.patch -- Matthew Ruffell Thu, 08 Feb 2024 16:46:39 +1300 ** Changed in: coreutils (Ubuntu Jammy) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: Fix Released Status in coreutils package in Fedora: Fix Released 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.122.0/24(rw,fsid=0,no_subtree_check,sync) /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) $ 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.122.18:/export export-missing 192.168.122.18:/export-missing $ 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,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561) 192.168.122.18:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18) 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://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test 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,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346) 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
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Thank you for the help sorting autopkgtests Mauricio. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: Fix Committed Status in coreutils package in Fedora: Fix Released 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.122.0/24(rw,fsid=0,no_subtree_check,sync) /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) $ 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.122.18:/export export-missing 192.168.122.18:/export-missing $ 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,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561) 192.168.122.18:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18) 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://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test 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,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346) 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 85c975df2c25bd799370b04bb294e568e001102f From: Rohan Sable Date: Mon, 7 Mar 2022 14:14:13 + Subject: ls: avoid triggering automounts Link: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2 commit 92cb8427c537f37edd43c5cef1909585201372ab From: Pádraig Brady Date: Mon, 7 Mar 2022 23:29:20 + Subject: stat: only automount with
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Autopkgtests are now clear in update_excuses and pending-sru. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: Fix Committed Status in coreutils package in Fedora: Fix Released 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.122.0/24(rw,fsid=0,no_subtree_check,sync) /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) $ 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.122.18:/export export-missing 192.168.122.18:/export-missing $ 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,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561) 192.168.122.18:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18) 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://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test 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,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346) 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 85c975df2c25bd799370b04bb294e568e001102f From: Rohan Sable Date: Mon, 7 Mar 2022 14:14:13 + Subject: ls: avoid triggering automounts Link: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2 commit 92cb8427c537f37edd43c5cef1909585201372ab From: Pádraig Brady Date: Mon, 7 Mar 2022 23:29:20 + Subject: stat: only automount
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
For dotnet6 on amd64 and arm64, the errors are unrelated to coreutils
(the same test errors happen against dotnet6 itself and even glibc),
thus triggered a migration-reference/0 run.
[0,3] trigger: coreutils/8.32-4.1ubuntu1.2
dotnet-runtime-json-contains-ubuntu-rids FAIL non-zero exit status 253
[1,4] trigger: dotnet6/6.0.128-0ubuntu1~22.04.1
dotnet-runtime-json-contains-ubuntu-rids FAIL non-zero exit status 253
[2,5] trigger: glibc/2.35-0ubuntu3.6
dotnet-runtime-json-contains-ubuntu-rids FAIL non-zero exit status 253
All fail with error messages:
ERROR: RID (Runtime Identifier) 'ubuntu.24.04{,-arm,-arm64,-x64,-x86}'
is missing in
'src/runtime/src/libraries/Microsoft.NETCore.Platforms/src/runtime.json'!
[0]
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/d/dotnet6/20240319_131027_34202@/log.gz
[1]
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/d/dotnet6/20240321_145231_25ae8@/log.gz
[2]
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/d/dotnet6/20240321_154527_e413f@/log.gz
[3]
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/d/dotnet6/20240319_111747_74352@/log.gz
[4]
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/d/dotnet6/20240321_135858_e04d0@/log.gz
[5]
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/d/dotnet6/20240321_141049_ff5d1@/log.gz
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/2033892
Title:
ls -l triggers mount of autofs shares when --ghost option is present
or browse_mode is enabled
Status in coreutils package in Ubuntu:
Fix Released
Status in coreutils source package in Jammy:
Fix Committed
Status in coreutils package in Fedora:
Fix Released
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.122.0/24(rw,fsid=0,no_subtree_check,sync)
/export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync)
$ 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.122.18:/export
export-missing 192.168.122.18:/export-missing
$ 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,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561)
192.168.122.18:/export on /mnt2/export type nfs
(rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18)
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://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test
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,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346)
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
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Re: comment #15
> autopkgtest for dotnet6/6.0.128-0ubuntu1~22.04.1: amd64: Regression ♻ ,
> arm64: Regression ♻
> autopkgtest for linux-hwe-5.19/5.19.0-50.50: amd64: Pass, arm64: Regression ♻
> , ...
> autopkgtest for linux-hwe-6.5/6.5.0-27.28~22.04.1: arm64: Regression ♻ , ...
dotnet6 amd64
apparently unrelated; rerunning without core-utils as trigger:
- rerun with trigger on dotnet6 (from proposed)
- rerun with trigger on glibc (last passing)
dotnet6 jammy/arm64
likewise
linux-hwe-5.19/arm64
timedout several times
rerun
linux-hwe-6.5/arm64
timeout several times
rerun
linux-gcp-5.19 and -6.2 already cleared due to reruns.
Proposed {linux,linux-*}/{arm64,armhf} to long_tests [1] per [2].
[1]
https://code.launchpad.net/~mfo/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/462861
[2] https://wiki.ubuntu.com/ProposedMigration#autopkgtests
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/2033892
Title:
ls -l triggers mount of autofs shares when --ghost option is present
or browse_mode is enabled
Status in coreutils package in Ubuntu:
Fix Released
Status in coreutils source package in Jammy:
Fix Committed
Status in coreutils package in Fedora:
Fix Released
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.122.0/24(rw,fsid=0,no_subtree_check,sync)
/export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync)
$ 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.122.18:/export
export-missing 192.168.122.18:/export-missing
$ 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,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561)
192.168.122.18:/export on /mnt2/export type nfs
(rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18)
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://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test
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,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346)
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
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Performing verification for Jammy I set up two Jammy VMs, one a nfs-server and the other an autofs/nfs- client. The client is using coreutils 8.32-4.1ubuntu1.1 from -updates. $ apt-cache policy coreutils | grep Installed Installed: 8.32-4.1ubuntu1.1 I set up the nfs server and autofs mounts as the Testcase indicates. $ ls -l ls: cannot access 'export-missing': No such file or directory total 4 drwxr-xr-x 3 root root 4096 Mar 20 22:16 export d? ? ?? ?? export-missing $ mount -l | grep mnt2 /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=692,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21588) 192.168.122.65:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.65,mountvers=3,mountport=47718,mountproto=udp,local_lock=none,addr=192.168.122.65) The mounts were previously unmounted, but when I issue 'ls -l', the mounts occur, which is not wanted, and we error out on the non-existant export-missing mount. I then enabled -proposed, and installed coreutils 8.32-4.1ubuntu1.2. $ apt-cache policy coreutils | grep Installed Installed: 8.32-4.1ubuntu1.2 From there, lets try the 'ls -l': $ ls -l total 0 drwxr-xr-x 2 root root 0 Mar 20 22:25 export drwxr-xr-x 2 root root 0 Mar 20 22:25 export-missing $ mount -l | grep mnt2 /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=648,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=16856) This time the mounts do not occur, we just get a listing of the possible autofs mounts. We can confirm with 'mount -l' that nothing was actually actioned. The package in -proposed fixes the issues. Happy to mark verified for Jammy. ** Tags removed: verification-needed verification-needed-jammy ** Tags added: verification-done-jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: Fix Committed Status in coreutils package in Fedora: Fix Released 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.122.0/24(rw,fsid=0,no_subtree_check,sync) /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) $ 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.122.18:/export export-missing 192.168.122.18:/export-missing $ 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,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561) 192.168.122.18:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18) 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://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test 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
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Hello René, or anyone else affected, Accepted coreutils into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/coreutils/8.32-4.1ubuntu1.2 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-jammy. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: coreutils (Ubuntu Jammy) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: Fix Committed Status in coreutils package in Fedora: Fix Released 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.122.0/24(rw,fsid=0,no_subtree_check,sync) /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) $ 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.122.18:/export export-missing 192.168.122.18:/export-missing $ 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,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561) 192.168.122.18:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18) 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://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test 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,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346) 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
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Considerations for the SRU team: I confirmed that the behavior in Jammy is different than Focal and Mantic, the previous / next supported releases. (Steps in the next comment.) So, although this SRU changes behavior in a stable release (generally not OK in SRUs), it is actually Jammy that changed behavior _across_ stable releases (and to a buggy one!). Thus, the SRU is reasonably _restoring_ (arguably, _fixing_) the _expected_ behavior. So, this looks OK for SRU, IMHO. Additionally, I considered two points before sponsoring this. 1) The impact of the code changes to non-autofs/non-automount: And it seems virtually zero, considering the man pages explain the flag now used in statx() is used in other related syscalls (stat, lstat, fstatat), which have it implied since Linux 4.11. And it indeed only affects automount (note the flag name). So, even though this change is "new" in Jammy, it's been tested in older and later releases for a long time (pre-Bionic kernels). stat(2): AT_NO_AUTOMOUNT (since Linux 2.6.38) [...] Since Linux 4.11 this flag is implied. statx(2): AT_NO_AUTOMOUNT [...] All of stat(2), lstat(2), and fstatat(2) act as though AT_NO_AUTOMOUNT was set. 2) Whether users may have started to rely on this behavior I agree this is unlikely, and think so because of 3 points: 2.1) This behavior did not exist in previous releases, which reduces the chances it has been 'learned' before. 2.2) The usage of autofs/automount rely on access to be made _to a particular mountpoint_ in order for it to be _mounted_. This is reflected in different documentation sources online, so it is likely that this is the way that has been 'learned'. 2.3) The safe side is, _even if_ an user started to rely on this behavior to automount the subdirs, the very next thing they will do (if they actually need that subdir mounted) is to _access_ that subdir - which can mount it just as before! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: In Progress Status in coreutils package in Fedora: Fix Released 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.122.0/24(rw,fsid=0,no_subtree_check,sync) /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) $ 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.122.18:/export export-missing 192.168.122.18:/export-missing $ 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,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561) 192.168.122.18:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18) 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://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test If you install them, this is what should occur: $ ls -l total 0 drwxr-xr-x 2 root root 0 Feb 12 22:01
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Reviewed and sponsored to Jammy; thanks! Notes: - Please add test for `stat` as well (bottom of tests comment). - I just changed the DEP3 Origin tag (commit ID; backport_ed_). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: In Progress Status in coreutils package in Fedora: Fix Released 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.122.0/24(rw,fsid=0,no_subtree_check,sync) /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) $ 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.122.18:/export export-missing 192.168.122.18:/export-missing $ 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,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561) 192.168.122.18:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18) 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://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test 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,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346) 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 85c975df2c25bd799370b04bb294e568e001102f From: Rohan Sable Date: Mon, 7 Mar 2022 14:14:13 + Subject: ls: avoid triggering automounts Link: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2 commit
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Test Steps: lxc launch --vm ubuntu:$SERIES autofs-$SERIES lxc shell autofs-$SERIES # replace linux-kvm with linux-generic for autofs DEBIAN_FRONTEND=noninteractive apt remove --yes --purge '?and(?installed,?or(?source-package(linux-kvm),?source-package(linux-meta-kvm)))' dpkg -s linux-image-virtual >/dev/null 2>/dev/null || (apt install --yes linux-image-virtual && reboot) apt update && apt install -y autofs sed '/^browse_mode =/ s/=.*/= yes/' -i /etc/autofs.conf echo '/test /etc/auto.test' >/etc/auto.master.d/test.autofs cat >/etc/auto.test
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
** Tags removed: sts-sponsor -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: In Progress Status in coreutils package in Fedora: Fix Released 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.122.0/24(rw,fsid=0,no_subtree_check,sync) /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) $ 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.122.18:/export export-missing 192.168.122.18:/export-missing $ 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,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561) 192.168.122.18:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18) 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://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test 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,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346) 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 85c975df2c25bd799370b04bb294e568e001102f From: Rohan Sable Date: Mon, 7 Mar 2022 14:14:13 + Subject: ls: avoid triggering automounts Link: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2 commit 92cb8427c537f37edd43c5cef1909585201372ab From: Pádraig Brady Date: Mon, 7 Mar 2022 23:29:20 + Subject: stat: only automount with --cached=never Link:
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
** Description changed: - Release: 22.04.3 LTS - coreutils 8.32-4.1ubuntu1 + [Impact] - ls triggers unwanted mounts of autofs filesystems + 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. - cause: coreutils 8.32.4.1ubuntu1 uses statx which not pass the - AT_NO_AUTOMOUNT flag + Disks / shares may not be present and the mounts may fail, leading to + errors in your output. - This bug is also known (and fixed) at Redhat - https://bugzilla.redhat.com/show_bug.cgi?id=2044981 + This is a behaviour change in autofs 8.32, which occurred in the + transition to using statx() instead of stat()/lstat() in previous + releases. - upstream commits: - https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2 - https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-178-g92cb8427c53 + There doesn't seem to be any workarounds, apart from not running a 'ls + -l' in your autofs share directory. - fedora commit - https://src.fedoraproject.org/rpms/coreutils/c/d736cafa20f13eeb037a3950bdbb4b63dc39b7e3?branch=f35 + [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.122.0/24(rw,fsid=0,no_subtree_check,sync) + /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) + $ 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.122.18:/export + export-missing 192.168.122.18:/export-missing + $ 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,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561) + 192.168.122.18:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18) + + 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://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test + + 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,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346) + + 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 85c975df2c25bd799370b04bb294e568e001102f + From: Rohan Sable + Date: Mon, 7 Mar 2022 14:14:13 + + Subject: ls: avoid triggering automounts + Link:
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Attached is a debdiff that solves this issue on Jammy. ** Patch added: "Debdiff for coreutils on Jammy" https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/+attachment/5745181/+files/lp2033892_jammy.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: In Progress Status in coreutils package in Fedora: Fix Released Bug description: Release: 22.04.3 LTS coreutils 8.32-4.1ubuntu1 ls triggers unwanted mounts of autofs filesystems cause: coreutils 8.32.4.1ubuntu1 uses statx which not pass the AT_NO_AUTOMOUNT flag This bug is also known (and fixed) at Redhat https://bugzilla.redhat.com/show_bug.cgi?id=2044981 upstream commits: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2 https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-178-g92cb8427c53 fedora commit https://src.fedoraproject.org/rpms/coreutils/c/d736cafa20f13eeb037a3950bdbb4b63dc39b7e3?branch=f35 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
** Also affects: coreutils (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: coreutils (Ubuntu Jammy) Status: New => In Progress ** Changed in: coreutils (Ubuntu Jammy) Importance: Undecided => Medium ** Changed in: coreutils (Ubuntu Jammy) Assignee: (unassigned) => Matthew Ruffell (mruffell) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: In Progress Status in coreutils package in Fedora: Fix Released Bug description: Release: 22.04.3 LTS coreutils 8.32-4.1ubuntu1 ls triggers unwanted mounts of autofs filesystems cause: coreutils 8.32.4.1ubuntu1 uses statx which not pass the AT_NO_AUTOMOUNT flag This bug is also known (and fixed) at Redhat https://bugzilla.redhat.com/show_bug.cgi?id=2044981 upstream commits: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2 https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-178-g92cb8427c53 fedora commit https://src.fedoraproject.org/rpms/coreutils/c/d736cafa20f13eeb037a3950bdbb4b63dc39b7e3?branch=f35 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
$ git tag --contains 85c975df2c2 v9.1 v9.2 v9.3 v9.4 $ git tag --contains 92cb8427c53 v9.1 v9.2 v9.3 v9.4 $ Ubuntu 23.10 includes coreutils 9.1, 24.04 LTS will include coreutils 9.4. So this bug is fixed in the latest release of Ubuntu. ** Changed in: coreutils (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils package in Fedora: Fix Released Bug description: Release: 22.04.3 LTS coreutils 8.32-4.1ubuntu1 ls triggers unwanted mounts of autofs filesystems cause: coreutils 8.32.4.1ubuntu1 uses statx which not pass the AT_NO_AUTOMOUNT flag This bug is also known (and fixed) at Redhat https://bugzilla.redhat.com/show_bug.cgi?id=2044981 upstream commits: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2 https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-178-g92cb8427c53 fedora commit https://src.fedoraproject.org/rpms/coreutils/c/d736cafa20f13eeb037a3950bdbb4b63dc39b7e3?branch=f35 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: coreutils (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Confirmed Status in coreutils package in Fedora: Fix Released Bug description: Release: 22.04.3 LTS coreutils 8.32-4.1ubuntu1 ls triggers unwanted mounts of autofs filesystems cause: coreutils 8.32.4.1ubuntu1 uses statx which not pass the AT_NO_AUTOMOUNT flag This bug is also known (and fixed) at Redhat https://bugzilla.redhat.com/show_bug.cgi?id=2044981 upstream commits: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2 https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-178-g92cb8427c53 fedora commit https://src.fedoraproject.org/rpms/coreutils/c/d736cafa20f13eeb037a3950bdbb4b63dc39b7e3?branch=f35 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Launchpad has imported 7 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=2044981.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
On 2022-01-25T12:22:21+00:00 rsable wrote:
Description of problem:
Autofs mounts with --ghost or browse_mode=yes enabled, triggers a mount
or shows error "ls: cannot access '': 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):
autofs-5.1.4-74.el8.x86_64
coreutils-8.30-12.el8.x86_64
(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)
2. Create an autofs map :
~~~
[root@rsablerhel85 mnt2]# grep -i mnt /etc/auto.master
/mnt2 /etc/auto.indirect
timeout=600,bg,tcp,hard,vers=3,rsize=32768,wsize=32768,timeo=600,retrans=6
[root@rsablerhel85 mnt2]# cat /etc/auto.indirect
testshare rsable76server:/testshare < testshare is a valid
export from server
testshare2 rsable76server:/testshare2 < testshare2 is not
available to this client or could be a bogus entry
~~~
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
rsable76server:/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,mountproto=tcp,local_lock=none,addr=192.168.122.58)
~~~
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.
Reverting back to coreutils-common-8.30-8.el8 this issue goes away :
~~~
[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
Downgraded:
coreutils-8.30-8.el8.x86_64
coreutils-common-8.30-8.el8.x86_64
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 getdents64(3, [{d_ino=27279, d_off=1, d_reclen=24,
d_type=DT_DIR, d_name="."}, {d_ino=27279, d_off=2, d_reclen=24, d_type=DT_DIR,
d_name=".."}, {d_ino=27281, d_off=3, d_reclen=32, d_type=DT_DIR,
d_name="testshare"}, {d_ino=27280, d_off=4, d_reclen=32, d_type=DT_DIR,
d_name="testshare2"}], 32768) = 112 <0.18>
3181 12:02:14.033318 statx(AT_FDCWD, "testshare2",
AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW,
STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE,
0x7ffc0d6f1c60) = -1 ENOENT (No such file or directory) <0.035781>
~~~
~~~
coreutils-8.30-8
2854 12:01:11.302926 getdents64(3, [{d_ino=27279, d_off=1, d_reclen=24,
d_type=DT_DIR, d_name="."}, {d_ino=27279, d_off=2, d_reclen=24, d_type=DT_DIR,
d_name=".."}, {d_ino=27281, d_off=3, d_reclen=32, d_type=DT_DIR,
d_name="testshare"}, {d_ino=27280, d_off=4, d_reclen=32, d_type=DT_DIR,
d_name="testshare2"}], 32768) = 112 <0.27>
2854 12:01:11.311912 lstat("testshare2", {st_dev=makedev(0, 0x31),
st_ino=27280, st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0,
st_blksize=1024, st_blocks=0, st_size=0, st_atime=1642783648 /*
2022-01-21T11:47:28.580732805-0500 */, st_atime_nsec=580732805,
st_mtime=1642783648 /* 2022-01-21T11:47:28.580732805-0500 */,
st_mtime_nsec=580732805, st_ctime=1642783648 /*
2022-01-21T11:47:28.580732805-0500 */,
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
** Bug watch added: Red Hat Bugzilla #2044981 https://bugzilla.redhat.com/show_bug.cgi?id=2044981 ** Also affects: coreutils (Fedora) via https://bugzilla.redhat.com/show_bug.cgi?id=2044981 Importance: Unknown Status: Unknown ** Tags added: jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: New Status in coreutils package in Fedora: Unknown Bug description: Release: 22.04.3 LTS coreutils 8.32-4.1ubuntu1 ls triggers unwanted mounts of autofs filesystems cause: coreutils 8.32.4.1ubuntu1 uses statx which not pass the AT_NO_AUTOMOUNT flag This bug is also known (and fixed) at Redhat https://bugzilla.redhat.com/show_bug.cgi?id=2044981 upstream commits: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2 https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-178-g92cb8427c53 fedora commit https://src.fedoraproject.org/rpms/coreutils/c/d736cafa20f13eeb037a3950bdbb4b63dc39b7e3?branch=f35 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
