Description of problem: On fedora 32 I cannot add `ac` option to nfs mount. Moreover `findmnt` coredumps when used with `--output-all`. Version-Release number of selected component (if applicable): util-linux-2.35.1-4.fc32.x86_64 How reproducible: Create nfs mount and try to remount it with `ac` option. # findmnt -s -n / /dev/mapper/fedora-root xfs defaults /boot UUID=29adf357-fa8d-4470-b69d-d576cb31fbe5 xfs defaults none /dev/mapper/fedora-swap swap defaults /mnt 127.0.0.1:/home/foo nfs defaults /mounts/barbar 127.0.0.1:/home/bar nfs defaults And then running: `# mount -o remount,noauto,ro,ac 127.0.0.1:/home/bar /mounts/barbar` fails with: `mount: /mounts/barbar: mount point not mounted or bad option.` Dropping `,ac` from the command makes the command succeed. It succeeds on Fedora 31 with this option with version `util-linux-2.34-4.fc31.x86_64`. Side note: I wanted to post output of `findmnt -s -n --output-all` but it coredumps: ``` findmnt: ./include/xalloc.h:74: xstrdup: Assertion `str' failed. Aborted (core dumped) ``` (coredumpctl output) # coredumpctl dump PID: 36343 (findmnt) UID: 0 (root) GID: 0 (root) Signal: 6 (ABRT) Timestamp: Tue 2020-02-25 07:49:05 EST (57s ago) Command Line: findmnt -s -n --output-all Executable: /usr/bin/findmnt Control Group: /user.slice/user-0.slice/session-6.scope Unit: session-6.scope Slice: user-0.slice Session: 6 Owner UID: 0 (root) Boot ID: 7bd09c0fd84c423da2365cf805ab3be2 Machine ID: dc0e396f77cc4111b684b518943d4915 Hostname: localhost.localdomain Storage: /var/lib/systemd/coredump/core.findmnt.0.7bd09c0fd84c423da2365cf805ab3be2.36343.1582634945000000000000.lz4 Message: Process 36343 (findmnt) of user 0 dumped core. Stack trace of thread 36343: #0 0x00007fc958a4ba35 raise (libc.so.6 + 0x3ca35) #1 0x00007fc958a34895 abort (libc.so.6 + 0x25895) #2 0x00007fc958a34769 __assert_fail_base.cold (libc.so.6 + 0x25769) #3 0x00007fc958a43e76 __assert_fail (libc.so.6 + 0x34e76) #4 0x000055d038776e57 get_data (findmnt + 0x7e57) #5 0x000055d038777352 add_line (findmnt + 0x8352) #6 0x000055d03877780b add_matching_lines (findmnt + 0x880b) #7 0x000055d038776001 main (findmnt + 0x7001) #8 0x00007fc958a36042 __libc_start_main (libc.so.6 + 0x27042) #9 0x000055d0387761ae _start (findmnt + 0x71ae) Additional info:
The findmnt issue should be fixed by upstream commit: https://github.com/karelzak/util-linux/commit/c6d8486aad9ba080504d9b1ab4ea396cb2f1b81a, the change will be available in v2.35.2. For the mount issue I need more investigation. Thanks for your report.
Note that without "-t nfs" it does not execute /sbin/mount.nfs, but it directly calls # strace -emount ./mount -oremount,noauto,ro,ac sr.net.home:/mnt/store/backup /mnt/backup mount("sr.net.home:/mnt/store/backup", "/mnt/backup", 0x602000000350, MS_RDONLY|MS_REMOUNT, "ac") = 0 and on kernel 5.4.12-200.fc31.x86_64 it's successful. Maybe you can try strace -emount mount -o remount,noauto,ro,ac 127.0.0.1:/home/bar /mounts/barbar do get more details about how mount(8) calls the syscall. Anyway, re-assigning to NFS guys -- it seems like a regression in f32.
Does not happen anymore. Assuming it is fixed.