Drive Auto-Mounting Has Stopped Working - Why?

General system Kernel, boot, graphics & hardware
1

So I shall get straight to the point…

Before three days ago my recently setup system would turn on, and I would decrypt the main boot disk drive, then login via SDDM into my KDE Plasma 6 Desktop Environment.

I would navigate to the “Dolphin File Manager” and all of my Encrypted Drives would be automatically mounted, so that whenever I click on one of those drives I could immediately & seamlessly access it’s contents.

The “Auto-Mounting” was setup using “Gnome Disk Utility”, understand that I want a seamless experience here which is why I used GUI Software to enable auto-mounting of my encrypted drives.

Each drive has a unique encryption key assigned to it, and each key is saved under the “Gnome Disk Utility” settings such that it doesn’t need to be entered in order to access the drive when inside of the Desktop Environment.

Three days ago, aftet updating my system using pacman, the Encrypted Drives stopped auto-mounting, I did not change ANY settings related to “Gnome Disk Utility” or the drives themselves, the whole setup just stopped working, by that I mean that the drives would no longer “Auto-Mount” and Self-Decrypt as they used to.

Now, on every boot, I have to manually unlock each and every drive, it is as if the settings I chose using “Gnome Disk Utility” are being ignored, and I have already tried removing the settings, then, re-adding them/re-toggling the options I want within “Gnome Disk Utility”, and that didn’t resolve the issue.

I can’t find anyone else mentioning this issue recently, so my hope is that someone with a better understanding of recent package changes might have a better idea than I do of which package changes have caused tbis incredibly annoying issue to occur.

Thank You to Anyone that can help.

2

No idea what happened but have you checked how everything looks in your fstab file ? Because as far as i know the disk-utility writes stuff to that file.

3

Has systemd been used for automount? Query systemctl --type=mount and systemctl --type=automount to see if respective mount/automount units show up. If they are disabled they would not show up and they would need to be re-enabled (sudo systemctl enable --now +NameOfAutomountunit).
And automount units should not be in fstab.

4

I’ll have a look,

Because I don’t know what that file looked like when things were working I am not sure what it should be looking like now.

I’ll see if the Arch Wiki can provide me with any guidance on exactly what it should look like, I can only assume that it should have enteries visible in some kind of start up element of the file and that those enteries aren’t present.

I am ALMOST certain the crypt file is working as it should do because the drives themselves don’t need decrypting as such, they just need me to type in a admin password to get the unlocking of the drives to take place, they do seem to possibly partially mount but not in the way I have tbem configured to do so.

fstab & crypt, are me next ports of call, thanks for the hint!

5

I honestly don’t know, I will check this out too.

Thanks for your help!

6

Where you state “+NameOfAutomountUnit” for the “systemctl --type=automount” do you mean the name that the unit is given when found using the “systemctl --type=mount” command?

For example;

When using the “systemctl --type=mount” command multiple enteries are listed that are the drives I am having issues with getting to mount, lets call one of these enteries “mnt-Drive-1-SSD-1.mount”.

Should I now use the command “sudo systemctl enable --now mnt-Drive-1-SSD-1.mount” in order to enable the “automount” function again for that drive?

I don’t want to execute the command incorrectly and mess up things even more than they are already messed up. This is why I am asking such specific questions, I want to do this right the first time around.

7

Lets start here:
Somewhere on you system disk you have mounts points for your disks, e.g. /mnt/example1, /mnt/example2, etc. You could find these mount points with your file manager.
Gnome Disk Utility apparantly uses media-automount-generator in the background to create these mount points, and to create the automount units and its mount units, following a certain (naming) logic.
I had asked you to find automount units, systemctl --type=automount. Following the logic, you should have automount units like mnt-example1.automount (with above example).

Step 1:
In terminal systemctl --type=automount. That is a query, nothing is messed up.

Step 2a:
If you find your automount units, do systemctl status for each automount unit, example: systemctl status mnt-Drive-1-SSD-1.automount (using your example) and see if they are enabled and active

Step 2b:
If you don’t find your automount units in step 1, they could be disabled. See if they still exist: ls /etc/systemd/system/ | grep mount. If there are listed you can systemctl enable --now for each of the automount units, example: systemctl enable --now mnt-Drive-1-SSD-1.automount (using your example)
Note: Do not touch the mount units (there are triggered by the automount units)

Please note, above is an incomplete recipe

8

Thanks for your help so far, it is proving valuable in teaching me about where to look for certain elements of the system and vaguely how they function too.

I ran the command that you suggested from “Step 1” and I got two enteries niether of which appear to be what I am looking for.
The second entry is “proc-sys-fs-binfmt_misc.automount”, I don’t know what this does but it is loaded & active, so I doubt this is what I am after.
The first entry is only visible if I run the command from “Step 1” with the “–all” parameter attached to the end of the command. It is called “boot.automount” under the “LOAD” column it is registered as “not-found” it is “Inactive”, and under the “SUB” coloumn it is registered as “dead”.
It is described as “boot.automount”.

This first entry may be what I am looking for, that is of course assuming that one entry can stop all 6 drives from not auto-mounting at boot, I don’t know and the documentation online (Arch Wiki, and, Free Desktop Foundation) doesn’t make it very clear as to what this is for.

Anyway, I continued to “Step 2b” because “Step 2a” is currently not relevant to the results that I am seeing…

I ran the first command and I got no output from the terminal, nothing at all, not even an acknowledgement that nothing was found, when I run the command the terminal just drops to a new line with no output to confirm or deny that any action took place, so I have no way of verifying for definite that the command is working or even running, but assuming that it is running I must conclude that I do not have any entires for any automount('s).

If this “Step 2b” command is operating correctly, and the results from “Step 1” are normal then I can only conclude that “Gnome Disk Utility” isn’t doing what it should be doing, or, something else somewhere else in the system that I haven’t touched has decided to go rogue and mess with my configuration.

Those are the only logical reasons I can think of to explain why a perfectly functioning system has managed to corrupt itself without any user input to those configurations. It feels like I am not in control of the confirguration files that I have set in my system using GUI tools.

It gives me vibes of back when Windows 10 was trying to take control of parameters that I was setting myself, Which is not good. I left Windows 10 so that I could remain in control of the core functions of my system without an update changing settings on me that I had set myself.

9

So we know a little more with your feedback.
There are no inactive/active systemd automount unit files on your system at the moment. At least not for the taken search path /etc/systemd/system/.

Step 3: See if you find your drives in fstab cat /etc/fstab. You may want to share your terminal output

What are your mount points in gnome disk utility, menu edit mount options / mount point?
https://docs.bazzite.gg/Advanced/GNOME_Disks_Auto-Mount_Guide/

Background systemd automount , I know it is quite an entry level…
https://man.archlinux.org/man/systemd.automount.5.en
https://man.archlinux.org/man/systemd.unit.5.en

Well the GUI tools normally does the job, but you have no idee how it was accomplished unless there is a good GUI system documentation.

10

So for “Step 3”, when running the “cat /etc/fstab” command to read the contents of my fstab file I get all six enteries for the other drives.

Note that I have manually mounted them on this boot by clicking on them in the Dolphin File Manger and entering my user password once, this unlocks all the drives at the same time so once I start clicking on the other drives once the first is unlocked they all just unlock automatically as if all that is needed is a single point of authentication to confirm that I do want the drives to mount, of course they don’t actually mount until I select each one within the File Manager.

On a fresh boot, without doing anything else other than logging into a new Desktop Environment User Session the drives are still present in the fstab file, so the file is not being modified when I type in my user password to unlock the drives to allow them to finish mounting.

The mount points for my drives under fstab are as follows;

LABEL=LSD1\040-\040Main /mnt/LSD1\040-\040Main auto nosuid,nodev,nofail,x-gvfs-show 0 0
LABEL=LSD1\040-\040Copy /mnt/LSD1\040-\040Copy auto nosuid,nodev,nofail,x-gvfs-show 0 0
LABEL=LSD2\040-\040Main /mnt/LSD2\040-\040Main auto nosuid,nodev,nofail,x-gvfs-show 0 0
LABEL=LSD2\040-\040Copy /mnt/LSD2\040-\040Copy auto nosuid,nodev,nofail,x-gvfs-show 0 0
LABEL=VMD2\040-\040Main /mnt/VMD2\040-\040Main auto nosuid,nodev,nofail,x-gvfs-show 0 0
LABEL=VMD2\040-\040Copy /mnt/VMD2\040-\040Copy auto nosuid,nodev,nofail,x-gvfs-show 0 0

And the mount points in Gnome Disk Utility are;

/mnt/LSD1 - Copy
/mnt/LSD2 - Main
/mnt/LSD2 - Copy
/mnt/VMD2 - Main
/mnt/VMD2 - Copy

For each respective drive.

So the fstab file matches the Gnome Disk Utility Mount Points.

11

Please copy the terminal output entirely for easier understanding.
Anyway, we learned how gnome disk utility works.
So all mounts work technically.
I believe it would be wiser to rename your mount points from /mnt/LSD1 - Copy to /mnt/LSD1copy to prevent unforseeable hiccups (no space, underline etc).

As far as your original question “why auto-mounting your drives has stopped working” - I do not know.
I’m not familiar with fstab, so I can’t really say if your output is right or need some optimization - other than the naming of the mount points.

And concerning package updates, gnome disk utility wasn’t updated recently:
https://archlinux.org/packages/extra/x86_64/gnome-disk-utility/
You may want to review the issues list or request in-depth advice

12

About fstab look at the arch wiki, there is also a part about encrypted drives,maybe that will help.
https://wiki.archlinux.org/title/Fstab

13

A bit of a tangent here, but as a general rule of thumb for both EndeavourOS and Other Arch Linux based Distiributions is it standard behaviour for an update to a package to enable the modification of functionality that said package doesn’t ever interact with directly?

I am just trying to understand if, without being updated or loaded in any way, how Gnome Disk Utility would change settings on my system without any kind of deliberate trigger by me or by the system through way of an update.

This issue just happened after a routine system update, my concern is that if a routine system update can bork functionality of my Operating System in that way then perhaps this flavour of Linux isn’t for me as I am after something that is more stable than that while still also properly supporting my hardware like any modern Operating System should be able to do with hardware that is over a year old since it’s release (and over a year since availability of it’s software/firmware).

It feels like my needs contradict what EndeavourOS is trying to offer.
I just want a Operating System that works, and doesn’t change settings or functionality on me for key elements of the Operating System without implementing a seamless transition method that is enacted when I update the system as per normal.

I have grown tired of spending days or weeks trying to fix my Operating System, at this point I am now looking for a solution that just works as I expect it to, without any major bugs or glitches ruining day-to-day usability of the Operating System.
It seems I am on a path to switch over to something like Debian Stable KDE, or some other Debian-based KDE Plasma 6 Linux Distribution that is stable while offering a large suite of software options.

14

The beauty of linux is, you choose what you prefer, there is so much available.
If you believe Debian stable better fits your needs, go for it.
I’m not sure if plasma 6 is stable yet. It works and has great features, yes.
Please note, Debian also uses systemd, fstab, etc. So whatever you learned here is still valid there.

In all fairness your EOS worked before the update as it did after. So the OS itself works.
But Arch distributions all require hands on, for sure. I like that.
.

15

Okay, this is crazy but I ACCIDENTALLY fixed this issue today by fixing another issue that my system was having, and given how on a surface level the two issues shouldn’t be related I am starting to wonder if I have found a bug possibly…

Anyway, here is my solution to THIS problem mentioned in THIS Forum Post, run the following command;
systemctl mask dev-tpmrm0.device

You can find info on how I came to discover this command by reading my other issue post here:

Now here is some context in case that post above ever gets deleted or goes missing (I will try to back them up using the Wayback Machine just so that it can benefit others hopefully in the future!).
The issue seem to be indirectly (or maybe directly, I don’t know for sure) linked to the TPM 2.0 Module of the Linux Kernel, or at least some part of it, and strangely this issue has been a thorn in my side for years but didn’t actually provide any context in the Kernel Boot-Up Output until I purchased & installed a dedicated TPM 2.0 Hardware Module onto my motherboard.

By installing the TPM 2.0 Physical Hardware Module (NOT the Linux Kernel Module) I managed to get the kernel to start outputting information which has then lead to me ultimately working out what is broken and how to at the very least work around the issue until it can be properly fixed.
I say this as I don’t think that this is meant to happen when you install but don’t actually use a TPM 2.0 Hardware Module, it should just be ignored but clearly it isn’t, or at least it isn’t ignored fully.

Hopefully this helps someone out!

16

Had an issue regarding LUKS encrypted volumes over on Cachy, which turned out to be TPM related too.

17

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.