[Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Bug Watch Updater
2033892 at bugs.launchpad.net
Fri Sep 1 12:53:04 UTC 2023
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 '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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/comments/0
------------------------------------------------------------------------
On 2022-01-26T00:34:42+00:00 ikent wrote:
Before we go further could you check if this build helps with the problem please:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=42539848
Reply at:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/comments/1
------------------------------------------------------------------------
On 2022-01-26T00:36:19+00:00 ikent wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/comments/2
------------------------------------------------------------------------
On 2022-01-26T09:54:09+00:00 rsable wrote:
(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 at 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 at rsablerhel85 mnt2]# cd
[root at rsablerhel85 ~]# wget
http://download.eng.bos.redhat.com/brewroot/work/tasks/9859/42539859/autofs-5.1.4-79.el8.x86_64.rpm
[root at rsablerhel85 ~]# dnf install autofs-5.1.4-79.el8.x86_64.rpm
...
Upgraded:
autofs-1:5.1.4-79.el8.x86_64
Complete!
[root at rsablerhel85 ~]# systemctl restart autofs
[root at rsablerhel85 ~]# cd /mnt2
[root at 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 at 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)
~~~
Reply at:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/comments/3
------------------------------------------------------------------------
On 2022-03-21T07:43:08+00:00 kdudka wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/comments/4
------------------------------------------------------------------------
On 2022-03-21T08:10:16+00:00 kdudka wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/comments/5
------------------------------------------------------------------------
On 2022-11-08T10:53:11+00:00 errata-xmlrpc wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/comments/6
** Changed in: coreutils (Fedora)
Status: Unknown => Fix Released
** Changed in: coreutils (Fedora)
Importance: Unknown => High
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, 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:
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
More information about the foundations-bugs
mailing list