[SOLVED] Can't unmount NFS as normal user after hardware and Slackware upgrade

fido_dogstoyevsky · 02-21-2022, 03:51 PM

Recently upgraded hardware and did a full installation of Slackware 15.

I'm using a network file server with the same settings as I was with Slackware 14.2, which functions the same as before except that now I can only unmount it as root. I can mount it as a normal user as I could before; but if I try to unmount it as a normal user I get the error message

Code:

 umount.nfs: You are not permitted to unmount /media/pinotgrigio_server

I'm using the same fstab entry as before

Code:

10.1.1.80:/home/Tosh3TB/shared_files  /media/pinotgrigio_server  nfs  noauto,user,defaults  0 0

According to man fstab I shouldn't need to unmount as root. Am I looking in the wrong place for the problem?

marav · 02-21-2022, 07:15 PM

Hi,

FWIR,

If you mount NFS with the "user" option, the user who mounted it will be written to /run/mount/utab
Mount specifications are written in /etc/mtab by the kernel¹ (and there is no "user" information).

When umounting NFS, the content of /etc/fstab is irrelevant
The information needed is in /etc/mtab (/proc/mounts) and /run/mount/utab

And regular users are not allowed to write inside /etc/mtab

It's probably a bit simplistic, but I couldn't find the detailed information in which it was explained

¹: I guess

fido_dogstoyevsky · 02-21-2022, 07:58 PM

Thank you, gives me something to look up.

Switching to root to unmount isn't causing me any urgent problems, but not understanding why is really irritating.

jwoithe · 02-22-2022, 03:54 AM

There is further information in a thread I created in May 2021 on this issue:
(Current) Users cannot unmount NFS volume with fstab "users" option

The practical result is that there is no fix that I am aware of. As explained in the above thread, the altered behaviour is a consequence of the way the "users" option is tracked in the case of NFS mounts, and the switch of /etc/mtab from a file (which "mount" could write directly) to a symlink pointing to /proc/mounts (which "mount" has no control over).

The workaround I ultimately adopted was the use of sudo with the appropriate umount command.

fourtysixandtwo · 02-22-2022, 12:34 PM

You could always configure the automounter instead.

slac-in-the-box · 02-22-2022, 12:59 PM

I use nfs to share my users home directory across many cloud-based virtual machines all on the same openvpn created subnet (tun0).

On the nfs server, in my /etc/exports file I defined userid and groupid, like this:

Code:

/nfs/home/me 10.0.0.0/24(rw,all_squash,no_subtree_check,anonuid=2345,anongid=2345)

Even though it's a private subnet, above, I chose arbitrary username, subnet, uid and gid, for illustartive purposes, because I'm not expert enough on security to know if leaking such info could be exploited.

However, since user's shared home directory is what the user logs in to when accessing these remote machines over ssh, I can't test unmounting as regular user, because the directory is in use. But I can say that before I explicitly defined uid and gid, my user couldn't write, even though I had rw specified.

Petri Kaukasoina · 02-22-2022, 02:00 PM

Quote:

Originally Posted by jwoithe

the altered behaviour is a consequence of the way the "users" option is tracked in the case of NFS mounts, and the switch of /etc/mtab from a file (which "mount" could write directly) to a symlink pointing to /proc/mounts (which "mount" has no control over).

If you remove the symbolic link /etc/mtab, rc.S will make it a file. Or if you have an old install like I have, there has never been a link, so it still is a file.

jwoithe · 02-22-2022, 03:57 PM

Quote:

Originally Posted by fourtysixandtwo

You could always configure the automounter instead.

True, in some situations. In my case the automounter could not be used because the volume being mounted was not always available and this caused other issues. For many others though it could be a viable solution. It really depends on why ordinary users - as opposed to the system - need to do the mount/umount in each specific situation.

jwoithe · 02-22-2022, 04:16 PM

Quote:

Originally Posted by Petri Kaukasoina

If you remove the symbolic link /etc/mtab, rc.S will make it a file. Or if you have an old install like I have, there has never been a link, so it still is a file.

Forcing /etc/mtab back to a file is certainly an option. However, there are good reasons why /etc/mtab was changed to a symlink in (from what I've heard) pretty much all distributions (with Slackware being one of the last I think). Among other things, it makes the use of a read-only root filesystem easier and I believe the symlink also simplifies the use of namespaces. If none of the related issues are of concern or relevant, shifting /etc/mtab back to a file could work. However, since most distributions and packages are now assuming /etc/mtab is a symlink to /proc/mounts, there may come a time where a /etc/mtab file causes trouble. This was the primary reason I stuck with the symlink and came up with a solution which worked in my situation: it will prevent things breaking unexpectedly at some point in the future when it won't be possible to quickly get things going again by reverting to a file while a fix is devised.

fido_dogstoyevsky · 02-22-2022, 08:30 PM

Thanks everybody for your suggestions, Ive looked where I'd never have otherwise thought of.

It looks like the easiest way for me is to keep unmounting as root, all the alternatives carry the risk of unexpected consequences some random time in the future. On the plus side, I've learned quite a bit.

Marking the thread as solved.