Arch Linux

NFS automount with util-linux 2.35-1 working for me.
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

Does not work for me even using your options.

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.

Doesn't make a whole lot of sense to include 'user' when you're using an automount (performed on your behalf by systemd). What's the point of doing that?

Hmm, that is a good question. From some more testing, i guess this comes down how mount command handles automounted volumes.

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.

> 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.
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?

> That seems awkward/unlikely. How would Dolphin even know there's something to mount there?
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.

Hi, I think I have similar issue with a different use case (I think the same root cause).
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.

For the record:
https://github.com/karelzak/util-linux/issues/941

Bug is confirmed upstream, fix to be released soon.

New version of util-linux (2.35.1-1) has been released and is in the repos now.

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.

@tippl, it indeed fixes my issue, I can now mount again my NFS shares with user & x- option.