Ubuntu
coreutils package

ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled

Bug #2033892 reported by René Kosche on 2023-09-01

This bug affects 7 people

	Status	Importance	Assigned to
coreutils (Fedora)	Fix Released	High	redhat-bugs #2044981
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.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 <email address hidden>
Date: Mon, 7 Mar 2022 14:14:13 +0000
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 <email address hidden>
Date: Mon, 7 Mar 2022 23:29:20 +0000
Subject: stat: only automount with --cached=never
Link: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-178-g92cb8427c53

Upstream bugs:
https://bugs.gnu.org/54286
https://bugs.gnu.org/54287

See original description

Tags:

Revision history for this message

In Red Hat Bugzilla #2044981, rsable (rsable-redhat-bugs) wrote on 2022-01-25:

Download full text (5.1 KiB)

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):
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 getdent...

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):
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:

[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

Expected results:
Mount should not be trigger and error "ls: cannot access 'testshare2': No such file or directory"
should not be seen.

Additional info:

[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.000018>
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.000027>
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 */, st_ctime_nsec=580732805}) = 0 <0.000030>
~~~

It seems to me that coreutils-8.30-12 and inherently statx does not pass the flag AT_NO_AUTOMOUNT during this operation.
Checking around a few more it seems that vfs_lstat is just a wrapper to use vfs_statx internally and this explicitly sets AT_NO_AUTOMOUNT :
~~~
3193 static inline int vfs_lstat(const char __user *name, struct kstat *stat)
3194 {
3195         return vfs_statx(AT_FDCWD, name, AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT,
3196                          stat, STATX_BASIC_STATS);
3197 }
~~~
So it may be just a question of why statx syscall does not use AT_NO_AUTOMOUNT as a flag, unless I am wrong in the last few bits.

Revision history for this message

In Red Hat Bugzilla #2044981, ikent (ikent-redhat-bugs) wrote on 2022-01-26:

Before we go further could you check if this build helps with the problem please:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=42539848

Revision history for this message

In Red Hat Bugzilla #2044981, ikent (ikent-redhat-bugs) wrote on 2022-01-26:

(In reply to Ian Kent from comment #3)
> Before we go further could you check if this build helps with the problem
> please:
> https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=42539848

Given our earlier conversation it probably won't but it's worth trying it.

Revision history for this message

In Red Hat Bugzilla #2044981, rsable (rsable-redhat-bugs) wrote on 2022-01-26:

(In reply to Ian Kent from comment #3)
> Before we go further could you check if this build helps with the problem
> please:
> https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=42539848

As you suspected, this _does not_ resolve the issue :

~~~
[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]# cd

[root@rsablerhel85 ~]# wget http://download.eng.bos.redhat.com/brewroot/work/tasks/9859/42539859/autofs-5.1.4-79.el8.x86_64.rpm

[root@rsablerhel85 ~]# dnf install autofs-5.1.4-79.el8.x86_64.rpm
...
Upgraded:
autofs-1:5.1.4-79.el8.x86_64

Complete!

[root@rsablerhel85 ~]# systemctl restart autofs
[root@rsablerhel85 ~]# cd /mnt2
[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]# mount | grep -i testshare
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)
~~~

Revision history for this message

In Red Hat Bugzilla #2044981, kdudka (kdudka-redhat-bugs) wrote on 2022-03-21:

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

Revision history for this message

In Red Hat Bugzilla #2044981, kdudka (kdudka-redhat-bugs) wrote on 2022-03-21:

Fedora commits:
https://src.fedoraproject.org/rpms/coreutils/c/1f1987452485e60c346627502e25d763b4ec77f9?branch=rawhide
https://src.fedoraproject.org/rpms/coreutils/c/1f1987452485e60c346627502e25d763b4ec77f9?branch=f36
https://src.fedoraproject.org/rpms/coreutils/c/d736cafa20f13eeb037a3950bdbb4b63dc39b7e3?branch=f35
https://src.fedoraproject.org/rpms/coreutils/c/0a82158b717f3377ab68b28ebe5cd30255203c52?branch=f34

Revision history for this message

In Red Hat Bugzilla #2044981, errata-xmlrpc (errata-xmlrpc-redhat-bugs) wrote on 2022-11-08:

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (coreutils bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7758

René Kosche (rkraidboxes) on 2023-09-01

tags:

added: jammy

Bug Watch Updater (bug-watch-updater) on 2023-09-01

Changed in coreutils (Fedora):
importance:	Unknown → High
status:	Unknown → Fix Released

Revision history for this message

Launchpad Janitor (janitor) wrote on 2023-10-15:

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in coreutils (Ubuntu):
status:	New → Confirmed

Revision history for this message

Steve Langasek (vorlon) wrote on 2024-02-05:

$ 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

Matthew Ruffell (mruffell) on 2024-02-08

Changed in coreutils (Ubuntu Jammy):
status:	New → In Progress
importance:	Undecided → Medium
assignee:	nobody → Matthew Ruffell (mruffell)

Revision history for this message

Matthew Ruffell (mruffell) wrote on 2024-02-08:

#10

Debdiff for coreutils on Jammy Edit (5.2 KiB, text/plain)

Attached is a debdiff that solves this issue on Jammy.

Matthew Ruffell (mruffell) on 2024-02-12

description:	updated
tags:	added: sts-sponsor
tags:	added: sts

Mauricio Faria de Oliveira (mfo) on 2024-03-01

tags:

removed: sts-sponsor

Revision history for this message

Mauricio Faria de Oliveira (mfo) wrote on 2024-03-01 (last edit on 2024-03-01):

#11

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_).

Revision history for this message

Mauricio Faria de Oliveira (mfo) wrote on 2024-03-01:

#12

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!

Revision history for this message

Mauricio Faria de Oliveira (mfo) wrote on 2024-03-01:

#13

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 <<EOF
test-pass :/home
test-fail :/dir-not-found
EOF

systemctl restart autofs.service

ls -l /test

focal:

# ls -l /test
total 0
drwxr-xr-x 2 root root 0 Mar 1 20:04 test-fail
drwxr-xr-x 2 root root 0 Mar 1 20:04 test-pass

# mount | grep test
/etc/auto.test on /test type autofs (rw,relatime,fd=6,pgrp=3119,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=34040)

# lsb_release -cs
focal

# uname -r
5.4.0-172-generic

jammy:

# ls -l /test
ls: cannot access '/test/test-fail': No such file or directory
total 4
d????????? ? ? ? ? ? test-fail
drwxr-xr-x 3 root root 4096 Mar 1 19:19 test-pass

# mount | grep test
/etc/auto.test on /test type autofs (rw,relatime,fd=6,pgrp=2776,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=26488)
/dev/sda1 on /test/test-pass type ext4 (rw,relatime,discard,errors=remount-ro)

# lsb_release -cs
jammy

# uname -r
5.15.0-97-generic

mantic:

# ls -l /test
total 0
drwxr-xr-x 2 root root 0 Mar 1 20:04 test-fail
drwxr-xr-x 2 root root 0 Mar 1 20:04 test-pass

# mount | grep test
/etc/auto.test on /test type autofs (rw,relatime,fd=6,pgrp=2596,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=27998)

# lsb_release -cs
No LSB modules are available.
mantic

# uname -r
6.5.0-21-generic

stat test on jammy:

# ls -1 /test
test-fail
test-pass

# mount | grep test
/etc/auto.test on /test type autofs (rw,relatime,fd=6,pgrp=662,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=19929)

# stat /test/test-pass
...

# mount | grep test
/etc/auto.test on /test type autofs (rw,relatime,fd=6,pgrp=662,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=19929)
/dev/sda1 on /test/test-pass type ext4 (rw,relatime,discard,errors=remount-ro)

# stat /test/test-fail
stat: cannot statx '/test/test-fail': No such file or directory

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 <<EOF 
	test-pass :/home
	test-fail :/dir-not-found
	EOF

systemctl restart autofs.service

ls -l /test

focal:

# ls -l /test
	total 0
	drwxr-xr-x 2 root root 0 Mar  1 20:04 test-fail
	drwxr-xr-x 2 root root 0 Mar  1 20:04 test-pass

# mount | grep test
	/etc/auto.test on /test type autofs (rw,relatime,fd=6,pgrp=3119,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=34040)

# lsb_release -cs
	focal

# uname -r
	5.4.0-172-generic

jammy:

# ls -l /test
	ls: cannot access '/test/test-fail': No such file or directory
	total 4
	d????????? ? ?    ?       ?            ? test-fail
	drwxr-xr-x 3 root root 4096 Mar  1 19:19 test-pass

# mount | grep test
	/etc/auto.test on /test type autofs (rw,relatime,fd=6,pgrp=2776,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=26488)
	/dev/sda1 on /test/test-pass type ext4 (rw,relatime,discard,errors=remount-ro)

# lsb_release -cs
	jammy

# uname -r
	5.15.0-97-generic

mantic:

# ls -l /test
	total 0
	drwxr-xr-x 2 root root 0 Mar  1 20:04 test-fail
	drwxr-xr-x 2 root root 0 Mar  1 20:04 test-pass

# mount | grep test
	/etc/auto.test on /test type autofs (rw,relatime,fd=6,pgrp=2596,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=27998)

# lsb_release -cs
	No LSB modules are available.
	mantic

# uname -r
	6.5.0-21-generic

stat test on jammy:

# ls -1 /test
	test-fail
	test-pass

# mount | grep test
	/etc/auto.test on /test type autofs (rw,relatime,fd=6,pgrp=662,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=19929)

# stat /test/test-pass
	...

# mount | grep test
	/etc/auto.test on /test type autofs (rw,relatime,fd=6,pgrp=662,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=19929)
	/dev/sda1 on /test/test-pass type ext4 (rw,relatime,discard,errors=remount-ro)

# stat /test/test-fail
	stat: cannot statx '/test/test-fail': No such file or directory

Revision history for this message

Timo Aaltonen (tjaalton) wrote on 2024-03-19: Please test proposed package

#14

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

Revision history for this message

Ubuntu SRU Bot (ubuntu-sru-bot) wrote on 2024-03-19: Autopkgtest regression report (coreutils/8.32-4.1ubuntu1.2)

#15

All autopkgtests for the newly accepted coreutils (8.32-4.1ubuntu1.2) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

coreutils/unknown (arm64, ppc64el, s390x)
dotnet6/6.0.127-0ubuntu1~22.04.1 (amd64, arm64)
linux-gcp-5.19/5.19.0-1030.32~22.04.1 (arm64)
linux-gcp-6.2/6.2.0-1021.23~22.04.1 (arm64)
linux-hwe-5.19/5.19.0-50.50 (arm64)
linux-hwe-6.5/6.5.0-27.28~22.04.1 (arm64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#coreutils

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Revision history for this message

Matthew Ruffell (mruffell) wrote on 2024-03-20:

#16

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:

added: verification-done-jammy
removed: verification-needed verification-needed-jammy

Revision history for this message

Mauricio Faria de Oliveira (mfo) wrote on 2024-03-21:

#17

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

Revision history for this message

Mauricio Faria de Oliveira (mfo) wrote on 2024-03-21:

#18

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

Revision history for this message

Mauricio Faria de Oliveira (mfo) wrote on 2024-03-22:

#19

Autopkgtests are now clear in update_excuses and pending-sru.

Revision history for this message

Matthew Ruffell (mruffell) wrote on 2024-03-24:

#20

Thank you for the help sorting autopkgtests Mauricio.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2024-03-27:

#21

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 <email address hidden> Thu, 08 Feb 2024 16:46:39 +1300

Changed in coreutils (Ubuntu Jammy):
status:	Fix Committed → Fix Released

Revision history for this message

Timo Aaltonen (tjaalton) wrote on 2024-03-27: Update Released

#22

The verification of the Stable Release Update for coreutils has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.