External USB Drives No Longer Automount

English Hardware
#1

Not sure if this issue belongs here in hardware or in another section, but here goes.

Up until a few days ago, I had no problems with my external USB docking stations. I have three docking stations holding six hard drives which are the backups to the six drives inside the box. In the evening before going to bed, I turn them on, with the drives being automounted by KDE Plasma per the settings under Removable Storage. Then my fwbackups software backs up my internal drives to the external drives. Works fine, no problem - until a couple days ago - and today it got much worse.

The other day I noticed that one of the docking stations kept dropping off the Device Notifier then remounting itself. I assumed the docking station was wearing out and ordered a new one this morning for delivery tomorrow. No big deal.

Today I got a kernel update: openSUSE-SU-2021:0060-1: important: Security update for the Linux Kernel. Reported in Yast as “5.3.18-lp152.60.1” build date 13 January 2021.

Tonight when I turned on the other two docking stations, none of the drives automounted. If I click the down-arrow in device notifier, they mount for a second, then the down-arrow comes back. If I click mount in the Removable Devices section in Dolphin Places, the same thing: the drive mounts momentarily, then unmounts.

If I mount one of the drive partitions onto a test directory under root, it mounts and stays mounted. If I try to mount it as root on the run/media directory specified for the drive, it does not stay mounted, exactly the same as if I mount it from the Device Notifier or Places.

The mount points under /run/media were all owned by root, except for one my normal user account owns. I changed all the mount points to be owned by me, but that doesn’t appear to have made any difference.

My /etc/fstab is as follows - there has been no change since I reinstalled 15.2 a few weeks ago:

rhack@localhost:~> cat /etc/fstab
UUID=f0f32d8c-bb81-4755-9491-5b2e01dcf6b8  /          ext4  defaults           0  1
UUID=a9608367-acd0-4aed-b656-f863a57572e8  /home      ext4  user,exec,data=ordered  0  2
UUID=A733-DDE3                             /boot/efi  vfat  defaults           0  2
UUID=34ab1271-b4f1-4f39-ba4a-5b2784ed1d8c  /Data7     ext4  user,exec,data=ordered  0  2
UUID=01e2fd8f-825b-4348-a731-737962f23ea3  /Data6     ext4  user,exec,data=ordered  0  2
UUID=bba2cf27-d77e-4ef8-9f02-01c29b7c140f  /Data5     ext4  user,exec,data=ordered  0  2
UUID=3b92ab72-e309-4c2e-82db-c0bb7a70e82f  /Data3     ext4  user,exec,data=ordered  0  2
UUID=b610d0cd-9066-44db-8629-4a2369d11aa5  /Data2     ext4  user,exec,data=ordered  0  2
UUID=8b19f641-2108-410c-9938-3d10ada63d32  /Data1     ext4  user,exec,data=ordered  0  2
UUID=0944b7e1-2694-46cf-8251-da5dd8dce93c  /Data14    ext4  user,exec,data=ordered  0  2
UUID=6634fd1b-c4e5-40f7-8d37-cff7b0669c96  swap       swap  defaults           0  0
UUID=b0737a0c-f918-4c7f-8aa9-bf6b11382e0e  /run/media/rhack/Backup1 ext4  noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=2,x-systemd.device-timeout=2
UUID=2968d14c-4bc3-4142-980c-5fe9128499e4  /run/media/rhack/Backup2 ext4  noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=2,x-systemd.device-timeout=2
UUID=92ade3b6-6d6b-4f47-b39c-d7118aadf55f  /run/media/rhack/Backup3 ext4  noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=2,x-systemd.device-timeout=2
UUID=08cc8081-bd40-4206-b096-bba7668118bf  /run/media/rhack/Backup14 ext4  noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=2,x-systemd.device-timeout=2
UUID=33646f3f-0cf0-47ae-a64a-fc504af9f883  /run/media/rhack/Backup5 ext4  noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=2,x-systemd.device-timeout=2
UUID=8b7843cf-404f-45c2-a0b4-b5bd23be6836  /run/media/rhack/Backup7 ext4  noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=2,x-systemd.device-timeout=2

This is a big problem for me as this is how I do backups of my system. Anyone have any ideas about what could have suddenly changed the ability to automount external USB drives?

#2

This is contradictory to your /etc/fstab.

In your fstab you use systemd automounting (which is a systemd replacement for the automounter). Which means that the file systems are mounted if needed. That has nothing at all to do with any desktop

BTW, I hesitate to mention this, because it probably has nothing to do with your present problem, but it is a bad idea to use mount points in /media/run yourself (as system manager). That place is for the mounting done by the desktop (in coordination with udev and udisk) and that mechanism creates there mount points for the duration of a mount by desktop by a end-user. Rather dynamic. It uses algorithms that decide how to create a mount point that does not collide with other desktop mounts already active or for new mounts. Not a place to interfere with.

Use any place logical to your purpose for creating fixed mount points and (when you run out of fanatsy, use something inside /mnt) but here.

#3

A couple more things:

When I turn on the docking station, the drives mount for a second, then unmount. BUT they do not disappear from the Device Notifier. The mount command shows they are not mounted. Usually when I click the up arrow to unmount the drives, they disappear from the Device Notifer. If they’re not mounted, why does Device Notifier continue to show them?

Second, I have an external SSD drive plugged into one of the USB ports. It has been designed in Removable Storage as automount when logging in. It stays mounted. This drive has not been affected by whatever is going on. The drive mount point under /run/media is owned by me.

Third, I attached one of the docking stations to a USB data hub and turned it on. Same situation - won’t stay mounted. So it does not appear to have anything to do with the specific USB ports the docking stations are attached to.

#4

The reason I added the entries to /etc/fstab was because every time I turn on the docking stations, they didn’t automount: they would show up in Device Notified and I would have to click the down-arrow to mount them, even though they were set to “automount” via KDE Removable Storage settings. Then on top of that I would have to actually “visit” each backup directory in turn because if I didn’t, my backup program when it ran would try to backup to the drive and that would fail because the drive was not actually “mounted” (apparently) by Device Notifier or KDE itself.

OK, so what is the proper way to set up the system so that when I turn on the docking stations, the drives are properly mounted and ready to be accessed? Should I disable the KDE Removable Storage settings? Should I remove the /etc/fstab settings? I don’t want to have the drives permanently mounted like I do the SSD USB drive; I want to be able to turn them off during the day and back on before bed for the overnight backups. That lets them cool down during the day and keeps them off-line for backup security. But if I have to mount them permanently the way the internal drives are, then that’s what I’ll do. But I would prefer to have them automounted when turned on - fully automounted and ready to access by my backup software.

#5

OK, so this is what I just did. I removed the /etc/fstab settings.

That fixed the problem of the drives dropping off of Device Notifier. They show up and they have the Up Arrow indicating they are mounted. Even the docking station that looked like it was failing seems to be working.

So apparently the issue was some conflict between the KDE settings and the autofs settings, as you suggested. Why it just showed up in the last couple days is beyond me, unless it has something to do with the kernel update today.

I still don’t know why frequently the fwbackups utility will not be able to run until I “visit” the drive in some manner such as by visiting the drive in Dolphin which is what I usually do. I guess I’ll just try not doing that and see if that problem returns. Possible that issue is caused by the program itself not properly identifying the mounted drive - although it works fine after I click on the drive in Places for a few seconds. Maybe it has something to do with the way Python interacts with the system (fwbackups is written in Python.)

I guess this problem has been resolved. This is what I get for trying to do something (automount drives) when I don’t know what I’m doing - which is not hard since the whole concept of autofs is complex and confusing to someone not a system programmer.

#6

I am NOT deciding how you should configure things so they work for your needs (which may not be mine).

But I conclude that you use two very different ways of getting these file systems mounted. It starts already at the responsibility. Is this something that should be organized by the system manager or by (One of your( en user(s).
You say it is fir a backup. What sort of backup? a backup organized by the system manager for important system files and/or as a service to the users? Or is it something to be used by a particular user to backup her/his own data.

You seem to have done both.

As system manager (that is “as root”), you have created fstab entries. Those entries do not try to mount when the devices are connected (by switching power on somewhere), but they try to mount when some process wants to use a directory/file that is stored inside one of those file system. The result will be success when the devices are connected, it will be fail when not (for what you configured a device-timeout of two seconds, it will also have much repercussions because of the nofail, but the process that tries to go there might hang or fail).
I repeat, the trial to mount will be triggered by the try to access, not by switching on.
I can add that you have a idle-timeout of 2 secs, which means that 2 seconds after no process is anymore busy in the file system, it will be unmounted (which may explain why you see them unmounted sometimes after they where mounted earlier). Personally think 2 secs is a bit short when the usage is really going and leaving repeatedly in a short time frame. I use systemd automount on an NFS file system and have there x-systemd.idle-timeout=5min, but it depends on your needs and use case.

Now the end-user that connects a device while (s)he has an open desktop session. In Unix and also in original Linux that required root to mount the file system(s) on such a device. When hardware that supports such “on the run” connections became available (USB) that was seen as not user friendly. Thus all sorts of mechanisms were designed and implemented to improve here. Several failed to survive until today. Today this is done by a cooperation of the desktop with udev and udisk (those two run as a root owned process, after all, only a root owned process can mount). But the idea behind this is still: the desktop end-user connects a mass storage device and is then offered away to use it (the famous pop-up). This user is (at least does not need be) aware of where the file system is mounted. This is internal to the mechanism. And it is in an otherwise probably vulnerable place. Such mount points normally disappears after the umount that follows when the end-user decides to remove the device. It even when it lingers on, it may disappear at system shutdown.
This mechanism will NOT mount when it sees file systems that are in /etc/fstab, because it then decides that this is not to be handled by the desktop mechanism, but by a “normal” mount.
Thus indeed the addition of the fstab entries will have blocked your earlier way of desktop mounting.

So, it is up to you to decide what this is for and thus what solution path you must walk.