User can mount nfs f/s, can't umount it.

[Mike Spencer]

I've been mounting one Linux host on another across the LAN forever,
and umounting same, always as plain user.


In Slack 15, I can mount another host via nfs but I can't umount it.

enoch% mount /mnt/bogus

enoch% umount /mnt/bogus
umount.nfs: You are not permitted to unmount /mnt/bogus

I have to become root to umount it.


/etc/fstab: Same problem with either of these

bogus:/ /mnt/bogus nfs noauto,user,rw,hard,intr 0 0

bogus:/ /mnt/bogus nfs noauto,users,rw,hard,intr 0 0

mount(8) manpage:

Non-superuser mounts

Normally, only the superuser can mount filesystems. However,
when fstab contains the user option on a line, anybody can
mount the corresponding filesystem.
.....
Only the user that mounted a filesystem can unmount it
again. If any user should be able to unmount it, then use users
instead of user in the fstab line.

I don't see anything in manpaages for nfs(5), mount.nfs(8), fstab(5),
umount(8) that helps.

What has changed in 15? How do I revert to former behavior?

[Henrik Carlqvist]

Post by Mike Spencer
I have to become root to umount it.

I can't say why it doesn't work to umount nfs drives mounted with the
user option. However, I might have a better solution:

Make /etc/rc.d/rc.autofs executable (and run it or reboot) and you will
get access to your NFS servers at places like /net/bogus/ . The
automounter will automaticallu mount the directories when needed and
umount them some time after they have not been used.

regards Henrik

[Mike Spencer]

Post by Henrik Carlqvist

Post by Mike Spencer
I have to become root to umount it.

I can't say why it doesn't work to umount nfs drives mounted with the
user option.

Brain damage due to the morass of fulminating complexity.


In 14.2 and before, mounts were recorded in /etc/mtab. In that file,
a user-mounted f/s was tagged with the uname of the user who mounted
it.

Bogus is a 14.2 system:

bogus% mount /mnt/enoch
bogus% grep enoch /etc/mtab

enoch:/ /mnt/enoch nfs rw,user=mds,hard,intr,addr=192.168.0.22 0 0

But in 15, /etc/mtab is a symlink to /proc/mounts and no user info
associated with the user who mounted the f/s is there.

Enoch is a Slackware 15 host:

enoch% mount /mnt/bogus
enoch% cat /proc/mounts

/dev/root / ext4 rw,relatime 0 0
[snip system crap]
bogus:/ /mnt/bogus nfs rw,relatime,vers=3,rsize=131072,wsize=131072,\
namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=\
192.168.0.15,mountvers=3,mountport=59868,mountproto=udp,\
local_lock=none,addr=192.168.0.15 0 0

There's no problem user-umounting a USB device or an ext4 partition.

I haven't figured out what /run/mount/utab does, if anything. It's
empty on both 14.2 and 15. In addition, 15 has /run/mount/utab.lock
which is also empty, also of unknown significance. There's a snarl of
conflicting info on the net.

So it must be brain damage in umount.nfs(8) (which (according to the
manpage) is called umount(8)) or perhaps in a lib somewhere..

Shpx.

Some discussion at

https://www.linuxquestions.org/questions/slackware-14/can't-unmount-nfs-as-normal-user-after-hardware-and-slackware-upgrade-4175708382/

Post by Henrik Carlqvist
Make /etc/rc.d/rc.autofs executable (and run it or reboot) and you will
get access to your NFS servers at places like /net/bogus/ . The
automounter will automaticallu mount the directories when needed and
umount them some time after they have not been used.

Systems to be mounted are always up or aren't connected. And I
dislike the notion anyhow. I always have an exterm su'd to root
iconified on the side. Just extra bother to open it, umount & iconofy
it again. Not to mention that I have to beat up a new syntax to
configure it todo something I don't really want it to do.

Thank anyway. I didn't know about automount.

[Jim Diamond]

Hi Mike,

I admire your ability to find weird things. :-)
See below.

Post by Mike Spencer

Post by Henrik Carlqvist

Post by Mike Spencer
I have to become root to umount it.

I can't say why it doesn't work to umount nfs drives mounted with the
user option.

Brain damage due to the morass of fulminating complexity.
In 14.2 and before, mounts were recorded in /etc/mtab. In that file,
a user-mounted f/s was tagged with the uname of the user who mounted
it.
bogus% mount /mnt/enoch
bogus% grep enoch /etc/mtab
enoch:/ /mnt/enoch nfs rw,user=mds,hard,intr,addr=192.168.0.22 0 0
But in 15, /etc/mtab is a symlink to /proc/mounts

Not on my Slackware64 15.0 system:

% ls -l /etc/mtab
-rw-r--r-- 1 root root 523 Feb 18 15:57 /etc/mtab

Post by Mike Spencer
and no user info associated with the user who mounted the f/s is
there.

While I don't currently use NFS, there are a couple of lines in my
/etc/mtab with user=<my userid>.

Are you by any chance using some desktop environment which has decided
it knows better than you, and has done some strange things?

If you do a clean reboot, before attempting to mount anything, is
/etc/mtab a symlink or a real file?

And if it is a symlink, I wonder if booting from a USB stick, mounting
the / partition, deleting the symlink, and rebooting would show
anything.

Good luck.
Jim

[Mike Spencer]

Post by Jim Diamond
I admire your ability to find weird things. :-)

I'll be 81 in less than a fortnight so I'm just happy that the wetware
can still do that. But I *would* much rather be *using* my new setup
than groveling through stuff I really shouldn't need to know.

Post by Jim Diamond

Post by Mike Spencer
Brain damage due to the morass of fulminating complexity.
In 14.2 and before, mounts were recorded in /etc/mtab. In that file,
a user-mounted f/s was tagged with the uname of the user who mounted
it.
bogus% mount /mnt/enoch
bogus% grep enoch /etc/mtab
enoch:/ /mnt/enoch nfs rw,user=mds,hard,intr,addr=192.168.0.22 0 0
But in 15, /etc/mtab is a symlink to /proc/mounts

% ls -l /etc/mtab
-rw-r--r-- 1 root root 523 Feb 18 15:57 /etc/mtab

Now that's really bizarre. A very basic difference between 32 and 64
bit Slackware?

Post by Jim Diamond
While I don't currently use NFS, there are a couple of lines in my
/etc/mtab with user=<my userid>.

Yeah, like these from my 14.2 main box:

/dev/sda4 /mnt/sda4 ext4 rw,nosuid,nodev,user=mds 0 0
enoch:/ /mnt/enoch nfs rw,user=mds,hard,intr,addr=192.168.0.22 0 0

A HD partition and a host on the LAN, both mounted by mds, allowed by
"user" in /etc/fstab.

Post by Jim Diamond
Are you by any chance using some desktop environment which has decided
it knows better than you, and has done some strange things?

Gak! No. I use twm, possibly the least intrusive window manager
available. Didn't even install the KDE stuff.

Post by Jim Diamond
If you do a clean reboot, before attempting to mount anything, is
/etc/mtab a symlink or a real file?

Symlink. ls -l /etc/mtab first command after reboot.

Post by Jim Diamond
And if it is a symlink, I wonder if booting from a USB stick, mounting
the / partition, deleting the symlink, and rebooting would show
anything.

It might. I don't understand why, though.

That feels too like a rabbit hole for me. I always have an
iconified window down in the corner su'd to root. Rot can umount NFS
mounts easily enough, just a bother [1] and an annoyance that something
documented to work, doesn't.

[1] People my age are thought to be afflicted with an encroaching fear
of death. The real bummer is more unsought-for bother. :-)

[Henrik Carlqvist]

Post by Mike Spencer

Post by Mike Spencer
But in 15, /etc/mtab is a symlink to /proc/mounts

% ls -l /etc/mtab -rw-r--r-- 1 root root 523 Feb 18 15:57 /etc/mtab

Now that's really bizarre. A very basic difference between 32 and 64
bit Slackware?

I can say that on my 64 bit systems, Slackware 14.2 has /etc/mtab as a
file but Slackware 15.0 has /etc/mtab as a symbolic link. If it would
matter, both systems has been installed from scratch and not upgraded
from previous versions of Slackware.

However, I can't say how I got that symlink in Slackware 15.0. Looking at
the Slackware 15 packages, the package etc-15.0-x86_64-17.txz contains an
empty file etc/mtab.new and the doinst.sh script of that package seems to
copy that empty file to etc/mtab.

In /etc/rc.d/rc.S there are some comments about a symlink, but I was
unable to find which package or script that created the symlink.

So to me it seems as if /etc/mtab should have been a file on my 15.0
system, but somehow it has become a symlink.

regards Henrik

[Chris Vine]

Post by Henrik Carlqvist

Post by Mike Spencer
But in 15, /etc/mtab is a symlink to /proc/mounts

% ls -l /etc/mtab -rw-r--r-- 1 root root 523 Feb 18 15:57 /etc/mtab

Now that's really bizarre. A very basic difference between 32 and 64
bit Slackware?

I can say that on my 64 bit systems, Slackware 14.2 has /etc/mtab as a
file but Slackware 15.0 has /etc/mtab as a symbolic link. If it would
matter, both systems has been installed from scratch and not upgraded
from previous versions of Slackware.
However, I can't say how I got that symlink in Slackware 15.0. Looking at
the Slackware 15 packages, the package etc-15.0-x86_64-17.txz contains an
empty file etc/mtab.new and the doinst.sh script of that package seems to
copy that empty file to etc/mtab.
In /etc/rc.d/rc.S there are some comments about a symlink, but I was
unable to find which package or script that created the symlink.
So to me it seems as if /etc/mtab should have been a file on my 15.0
system, but somehow it has become a symlink.

ChangeLog.txt
Thu Nov 22 05:56:56 UTC 2018:
"rc.S: Support replacing the /etc/mtab file with a symlink to /proc/mounts."
Wed Nov 28 07:25:32 UTC 2018:
"Make /etc/mtab a symlink to /proc/mounts on the installer.
On a freshly installed system, make /etc/mtab a symlink to /proc/mounts."

[Mike Spencer]

Post by Chris Vine
ChangeLog.txt
"rc.S: Support replacing the /etc/mtab file with a symlink to
/proc/mounts."
"Make /etc/mtab a symlink to /proc/mounts on the installer. On a
freshly installed system, make /etc/mtab a symlink to /proc/mounts."

So Pat & Co. are on it but they haven't worked out the kinks.

Patrick apparently thinks mtab is still a file becuase this creates a
file, not a symlink:

/etc/rc.d/rc.S

# Any /etc/mtab that exists here is old, so we start with a new one:

/bin/rm -f /etc/mtab{,~,.tmp} && /bin/touch /etc/mtab

There seems to be two questions:

1. Why do some 15.0 installs have mtab a file and others a symlink?
Related: What/where is the code that makes the symlink and what
happened to it if there *is* no symlink?

Different people put together the 32 and 64 bit packages?
Oversight? Complexity catastrophy? :-) No real clue.

2. Given that mtab is a symlink, why doesn't umount work for
user-mouted NFS mounts?

Apparently people using local namespaces [1], containers, CIFS (I don't
even know what those are) & systemd inter alia run aground with a
corrupted mtab file and urge/demand mtab->/proc/mounts.

I found a lengthy discussion among Gentoo devs [2] from 2013/14.
They seem to have believed at that point that all problems had
been dealt with. The info previously in mtab but lacking in
/proc/mounts is to be stowed in utab (/run/utab, /run/mount/utab,
/var/utab. /dev/.mount/utab is mentioned in the libmount source
comments) and retieved from there by code that needs it.

+ Canonical location of utab seems to be uncertain but in my
Slack 15.0 it's in /run/mount/utab.

+ Mount(8) calls mount.nfs(8) as a helper and it, in turn,
depends on libmount.so to attend to the mount/umount details.

+ Slack 15 source for libmount (mount_libmount.c, 2011 Karel
Zak <***@redhat.com>) has cryptic comments suggesting that
it's using utab in some way but AFAICT from the C code, it
doesn't do anything that's needed: put the fstab data into
utab and/or fetch it back.

+ /run/mount/utab remains empty (tail -f while doing NFS
[u]mounts -> nothing.)

Wizards are invited to pursue this. It's beyond my very limited
hacker skills.

[1] Namespaces

With the addition of per-process namespaces with CLONE_NEWNS to
clone(2), each process has its own set of mounts, and as such a
system-wide /etc/mtab is useless: it's only valid in one of the
potentially many namespaces and can quickly get into a horrible
mess. At this point, /etc/mtab *must* be a symlink to avoid
breakage. Note that /proc/mounts is now a symlink to
/proc/self/mounts for this reason: each process has potentially
different mounts.

[2] https://bugs.gentoo.org/show_bug.cgi?id=477498

Debian devs though it was all fixed in 2011.

[Henrik Carlqvist]

Post by Mike Spencer

Post by Chris Vine
ChangeLog.txt
"rc.S: Support replacing the /etc/mtab file with a symlink to
/proc/mounts."
"Make /etc/mtab a symlink to /proc/mounts on the installer.
On a freshly installed system, make /etc/mtab a symlink to /proc/
mounts."

Thanks Chris for clearing that up! This explains why I couldn't find the
creation of any file on my system as the creation was done by the
installation initial ramdisk:

...
isolinux/initrd.img: Rebuilt.
...
On a freshly installed system, make /etc/mtab a symlink to /proc/mounts.

Post by Mike Spencer
1. Why do some 15.0 installs have mtab a file and others a symlink?

The 15.0 systems with a mtab file has probably been updated from 14.2 or
a Slackware current initially installed before 28/11 2018. The 15.0
systems with a symlink has probably been installed from scratch or
updated from a Slackware current initially installed after 28/11 2018.

Post by Mike Spencer
Related: What/where is the code that makes the symlink and what
happened to it if there *is* no symlink?

The code that creates the symlink is in a script in initrd.img on the
installation media. If there is no symlink, /etc/rc.d/rc.S instead
creates /etc/mtab as a file.

Post by Mike Spencer
2. Given that mtab is a symlink, why doesn't umount work for
user-mouted NFS mounts?

Because the user field is missing in the mtab file from /proc which /etc/
mtab points to by a symlink.

You are not alone with your problem, but from this thread it seems as if
there are too few with this problem for any upstream NFS developer to
care:

https://www.linuxquestions.org/questions/slackware-14/[current]-users-
cannot-unmount-nfs-volume-with-fstab-users-option-4175694647/

regards Henrik

[Chris Vine]

On Monday, 20 February 2023 at 05:01:49 UTC, Mike Spencer wrote:
[snip]

1. Why do some 15.0 installs have mtab a file and others a symlink?
Related: What/where is the code that makes the symlink and what
happened to it if there *is* no symlink?
Different people put together the 32 and 64 bit packages?
Oversight? Complexity catastrophy? :-) No real clue.

All new installs using the slackware-15.0/slackware-current installer
will have /etc/mtab as a symlink. If instead you continuously upgrade
slackware-current pre-2018 to post-2018 without using the installer,
having /etc/mtab as a file should be preserved - see rc.S.

What this in turn means is that if you delete the symlink and do 'touch
/etc/mtab' and reboot, mount should restablish /etc/mtab as a file
for you. In which case a user umount on your nfs mount should work
again. Try it and see. However since this is an infrequently used
approach it is possible something else may not work correctly.

2. Given that mtab is a symlink, why doesn't umount work for
user-mouted NFS mounts?

This question has already been answered. /proc/self/mounts
contains different information from what /etc/mtab would contain.

[Jim Diamond]

Post by Mike Spencer

Post by Jim Diamond
I admire your ability to find weird things. :-)

I'll be 81 in less than a fortnight so I'm just happy that the wetware
can still do that. But I *would* much rather be *using* my new setup
than groveling through stuff I really shouldn't need to know.

I understand, and sympathize. Does it make you want to heat something
up to red-hot and hit it with a hammer?

Anyway, see below.

Post by Mike Spencer

Post by Jim Diamond

Post by Mike Spencer
Brain damage due to the morass of fulminating complexity.
In 14.2 and before, mounts were recorded in /etc/mtab. In that file,
a user-mounted f/s was tagged with the uname of the user who mounted
it.
bogus% mount /mnt/enoch
bogus% grep enoch /etc/mtab
enoch:/ /mnt/enoch nfs rw,user=mds,hard,intr,addr=192.168.0.22 0 0
But in 15, /etc/mtab is a symlink to /proc/mounts

% ls -l /etc/mtab
-rw-r--r-- 1 root root 523 Feb 18 15:57 /etc/mtab

Now that's really bizarre. A very basic difference between 32 and 64
bit Slackware?

Post by Jim Diamond
While I don't currently use NFS, there are a couple of lines in my
/etc/mtab with user=<my userid>.

/dev/sda4 /mnt/sda4 ext4 rw,nosuid,nodev,user=mds 0 0
enoch:/ /mnt/enoch nfs rw,user=mds,hard,intr,addr=192.168.0.22 0 0
A HD partition and a host on the LAN, both mounted by mds, allowed by
"user" in /etc/fstab.

Post by Jim Diamond
Are you by any chance using some desktop environment which has decided
it knows better than you, and has done some strange things?

Gak! No. I use twm, possibly the least intrusive window manager
available. Didn't even install the KDE stuff.

Post by Jim Diamond
If you do a clean reboot, before attempting to mount anything, is
/etc/mtab a symlink or a real file?

Symlink. ls -l /etc/mtab first command after reboot.

Post by Jim Diamond
And if it is a symlink, I wonder if booting from a USB stick, mounting
the / partition, deleting the symlink, and rebooting would show
anything.

It might. I don't understand why, though.
That feels too like a rabbit hole for me. I always have an
iconified window down in the corner su'd to root. Rot can umount NFS
mounts easily enough, just a bother [1] and an annoyance that something
documented to work, doesn't.
[1] People my age are thought to be afflicted with an encroaching fear
of death. The real bummer is more unsought-for bother. :-)

In
https://www.linuxquestions.org/questions/linux-newbie-8/etc-mtab-vs-proc-mounts-4175423955/
there is a discussion about this, and someone quotes this:
When the proc filesystem is mounted (say at /proc), the files
/etc/mtab and /proc/mounts have very similar contents. The
former has somewhat more information, such as the mount
options used, but is not necessarily up-to-date (cf. the -n
option below). It is possible to replace /etc/mtab by a
symbolic link to /proc/mounts, and especially when you have
very large numbers of mounts things will be much faster with
that symlink, but some information is lost that way, and in
particular using the "user" option will fail.

Note in particular the juicy tidbit in the last line

The quote is from https://linux.die.net/man/8/mount. Apparently
Slackware64 15's man page is not the same version as that on
linux.die.net, but maybe it should be.

I am still confused about why my /etc/mtab is a file and yours (and
Henrik's?) is a symlink. Maybe we should start a poll on
linuxquestions to see how many people have the link and how many have
the file.

And, regardless of the numbers, why is it different? Do you use
containers? I don't (so far).

Jim

[Mike Spencer]

Post by Jim Diamond
I understand, and sympathize. Does it make you want to heat something
up to red-hot and hit it with a hammer?

That's the nice thing about forging hot iron. If it's not quite right,
you heat it up again and smack it with a hammer. Not to be confused
with Percussive Maintenance in the mechanical trades that has less
reliable results and is often deprecated. :-)

Post by Jim Diamond
In
https://www.linuxquestions.org/questions/linux-newbie-8/etc-mtab-vs-proc-mounts-4175423955/
When the proc filesystem is mounted (say at /proc), the files
/etc/mtab and /proc/mounts have very similar contents. The
former has somewhat more information, such as the mount
options used, but is not necessarily up-to-date (cf. the -n
option below). It is possible to replace /etc/mtab by a
symbolic link to /proc/mounts, and especially when you have
very large numbers of mounts things will be much faster with
that symlink, but some information is lost that way, and in
particular using the "user" option will fail.
Note in particular the juicy tidbit in the last line
The quote is from https://linux.die.net/man/8/mount. Apparently
Slackware64 15's man page is not the same version as that on
linux.die.net, but maybe it should be.

Nothing I can find that came with my 32 bit 15 package mentions that.

Post by Jim Diamond
I am still confused about why my /etc/mtab is a file and yours (and
Henrik's?) is a symlink.

As am I. See my previous post; do you have:

/bin/rm -f /etc/mtab{,~,.tmp} && /bin/touch /etc/mtab

in rc.S? I do but something revises that later in the boot process.

Post by Jim Diamond
Maybe we should start a poll on linuxquestions to see how many
people have the link and how many have the file.

Good. I'm not a registered user. Do post here if that happens.
Other distros, though, that use systemd, will, AIUI, be sure to have
the symlink because (I read somewhere) systemd after version $X
requires it.

Post by Jim Diamond
And, regardless of the numbers, why is it different? Do you use
containers? I don't (so far).

No, nor namespaces. Don't even know what they are.

[Jim Diamond]

Post by Jim Diamond
I understand, and sympathize. Does it make you want to heat something
up to red-hot and hit it with a hammer?

That's the nice thing about forging hot iron. If it's not quite right,
you heat it up again and smack it with a hammer.

I can see there are some pleasing aspects to blacksmithing.

Not to be confused with Percussive Maintenance in the mechanical
trades that has less reliable results and is often deprecated. :-)

Still, I wouldn't discount the value of percussive maintenance.

Post by Jim Diamond
In
https://www.linuxquestions.org/questions/linux-newbie-8/etc-mtab-vs-proc-mounts-4175423955/
When the proc filesystem is mounted (say at /proc), the files
/etc/mtab and /proc/mounts have very similar contents. The
former has somewhat more information, such as the mount
options used, but is not necessarily up-to-date (cf. the -n
option below). It is possible to replace /etc/mtab by a
symbolic link to /proc/mounts, and especially when you have
very large numbers of mounts things will be much faster with
that symlink, but some information is lost that way, and in
particular using the "user" option will fail.
Note in particular the juicy tidbit in the last line
The quote is from https://linux.die.net/man/8/mount. Apparently
Slackware64 15's man page is not the same version as that on
linux.die.net, but maybe it should be.

Nothing I can find that came with my 32 bit 15 package mentions that.

Post by Jim Diamond
I am still confused about why my /etc/mtab is a file and yours (and
Henrik's?) is a symlink.

/bin/rm -f /etc/mtab{,~,.tmp} && /bin/touch /etc/mtab
in rc.S? I do but something revises that later in the boot process.

There is, but it is guarded by this if condition:
if [ ! -L /etc/mtab -o ! -r /etc/mtab ]
and so if mtab has been made into a link, then your quoted code won't
touch it. Assuming your rc.S is the same, I don't think it is
something later in the boot process. But for giggles you could try
grep mtab /etc/rc.d/* | grep -v lvmtab
and see if you see anything else suspicious. I don't on my system,
but obviously my system is different than yours.

I just fired up a Slackware64 15.0 VM. Curiously, in there /etc/mtab
is a symlink. Evidently I did something different when setting up my
two systems. Too bad I don't know what that was.

Post by Jim Diamond
Maybe we should start a poll on linuxquestions to see how many
people have the link and how many have the file.

Good. I'm not a registered user. Do post here if that happens.
Other distros, though, that use systemd, will, AIUI, be sure to have
the symlink because (I read somewhere) systemd after version $X
requires it.

Post by Jim Diamond
And, regardless of the numbers, why is it different? Do you use
containers? I don't (so far).

No, nor namespaces. Don't even know what they are.

So much for that wild grasping at straws. If no-one else comes up
with the answer and I find anything out I'll let you know.

Jim