FS#65269 - [util-linux] Systemd automount of NFS fileshare no longer works after updating.
Attached to Project:
Arch Linux
Opened by Richard Tippl (tippl) - Saturday, 25 January 2020, 13:45 GMT
Last edited by freswa (frederik) - Wednesday, 12 February 2020, 11:24 GMT
Opened by Richard Tippl (tippl) - Saturday, 25 January 2020, 13:45 GMT
Last edited by freswa (frederik) - Wednesday, 12 February 2020, 11:24 GMT
|
Details
Description:
After upgrading util-linux from 5.34-8 to 5.35-1 my fileshare mounted using systemd.automount no longer works. When i try to navigate to it using KDE Dolphin or mount it with mount /mnt/nfs/dir i error out with lack of permissions even though i have the "user" flag in fstab. Mount error: failed to prepare mount: Operation not permitted I am not sure if this affects only NFS mounts or systemd automount in complete, since this is the only volume i have mounted this way. This issue is fixed by downgrading the package back to 2.34-8. If i remove automount flags from fstab (x-systemd.automount,x-systemd.device-timeout=10,x-systemd.idle-timeout=1min) and leave all other flags, i can again mount the share as user, but i lose the features of automounting and unmounting on inactivity. Additional info: /etc/fstab 192.168.1.40:/volume1/dir /mnt/nfs/dir nfs noauto,nofail,soft,user,noatime,retry=0,retrans=4,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0 Steps to reproduce: 1. add a NFS mount using systemd automount to fstab 2. reboot 3. navigate to the directory or try to mount it |
This task depends upon
Closed by freswa (frederik)
Wednesday, 12 February 2020, 11:24 GMT
Reason for closing: Fixed
Additional comments about closing: 2.35.1-1
Wednesday, 12 February 2020, 11:24 GMT
Reason for closing: Fixed
Additional comments about closing: 2.35.1-1
My fstab:
tuxbox:/home/films /home/nas/films nfs noauto,noatime,async,soft,intr,rsize=32768,wsize=32768,_netdev,bg,x-systemd.requires=network.target,x-systemd.automount,x-systemd.device-timeout=1,x-systemd.idle-timeout=10min,timeo=14 0 0
However assuming /home/nas is your current user folder i tried changing the mount volume to my home. This seems to work on 2.35-1.
Could you try modifying the mount location to one similar to mine? It seems to me that if i don't have permissions to the folder i am mounting to with automount, it does not work.
Removing the automount options and just running mount with the user option does allow me to do that however.
I thought KDE Dolphin tried to access the directory and it got automounted, but it seems it just sees it unmounted and issues a mount command before accessing.
This ended by permission denied for me which lead me to adding the user option.
So this means i am not really using automount by itself for the well.. automounting. But mainly using it for the unmount on inactivity after it is explicitly mounted.
Before the explicit mount seemed to have passed the mount request to the automount somehow, and it got mounted (but i could not run that without user flag), now it is not passed forward and the mount fails with an error.
That seems awkward/unlikely. How would Dolphin even know there's something to mount there?
> But mainly using it for the unmount on inactivity after it is explicitly mounted.
Nah, this doesn't work if you aren't going through the kernel's automount feature (via systemd)
> Before the explicit mount seemed to have passed the mount request to the automount somehow
This doesn't even make sense.
Let's not talk about Dolphin at all. It's not relevant.
What's the status of the automount unit prior to trying to access it? What happens when you run 'ls /mnt/nfs/dir'? What's the state of the automount and mount units after that?
Since the volume is there, but not mounted (noauto) and nfs it shows it as a remote fileshare. This happens even if i remove automount and it is still capable of mounting them.
Automount looks to be still working even after the update, when i navigate to the folder in terminal it gets mounted, but when opening it by clicking on the remote fs, it tries to mount it and fails.
> Nah, this doesn't work if you aren't going through the kernel's automount feature (via systemd)
It managed to do it somehow before the update, key clue is probably that when using the mount command, there is no info in the journal about automount mounting the volume, only logs of it being unmounted.
In summary, looks like automount works fine with the updated util-linux package, but the weird way KDE attempted to and managed to mount it no longer works.
And with this, i have no idea whether to even call this a bug... It is a weird interaction that worked for some reason.
It's manual mounting as user.
Here is my fstab:
nas:/volume1/music /nas/music nfs noauto,user,_netdev,bg,x-gvfs-show 0 0
As user I'm trying to mount the directory (with libmount debug activated):
export LIBMOUNT_DEBUG=0xffff
mount.nfs nas:/volume1/music /nas/music
I get this error in the debug output:
...
6494: libmount: CXT: final target '/nas/music' [rc=-1]
6494: libmount: CXT: mount: preparing failed
mount.nfs: failed to prepare mount: Operation not permitted
When I look at the code of libmount, I see a diff in libmount/src/context.c in the function mnt_context_prepare_target.
In version 2.34:
/* mkdir target */
if (cxt->action == MNT_ACT_MOUNT
&& !mnt_context_is_restricted(cxt)
&& (cxt->user_mountflags & MNT_MS_XCOMMENT ||
cxt->user_mountflags & MNT_MS_XFSTABCOMM)) {
rc = mkdir_target(tgt, cxt->fs);
if (rc) {
if (!mnt_context_switch_ns(cxt, ns_old))
return -MNT_ERR_NAMESPACE;
return rc; /* mkdir or parse error */
}
}
In version 2.35:
/* X-mount.mkdir target */
if (cxt->action == MNT_ACT_MOUNT
&& (cxt->user_mountflags & MNT_MS_XCOMMENT ||
cxt->user_mountflags & MNT_MS_XFSTABCOMM)) {
/* supported only for root or non-suid mount(8) */
if (!mnt_context_is_restricted(cxt))
rc = mkdir_target(tgt, cxt->fs);
else
rc = -EPERM;
}
My understanding of this code in 2.35 is that you'll get a -EPERM as non-root (user) each time, as soon as you have a mount comment (x-...).
I'll report this upstream and see what their point of view on this.
https://github.com/karelzak/util-linux/issues/941
It seems to have fixed my issue my issue, valr can you check if it fixes your issue too?
Looks like you were correct about the root cause being the same.