GNOME mounts a disk that is not included in fstab

amhairghin · 2024-05-19 11:12:12

I can't say exactly what triggered it but it looks like the kernel update (6.8.9.arch1-2 -> 6.9.1.arch1-1), now I get a secondary disk that I have for Windows data mounted by GNOME on boot by udisksd. This disk is not included in the fstab so I don't understand why my system automounts it.

Any idea? The truth is that in the system log I don't see anything but the mount line.

may 19 12:53:04 hell udisksd[1989]: Mounted /dev/sdb1 at /run/media/ogarcia/Datos on behalf of uid 1000

The full update was:

[2024-05-18T13:02:10+0200] [ALPM] upgraded bluez (5.75-1 -> 5.76-1)
[2024-05-18T13:02:10+0200] [ALPM] upgraded bluez-libs (5.75-1 -> 5.76-1)
[2024-05-18T13:02:10+0200] [ALPM] upgraded cjson (1.7.17-1 -> 1.7.18-1)
[2024-05-18T13:02:10+0200] [ALPM] upgraded libimagequant (4.3.0-1 -> 4.3.1-1)
[2024-05-18T13:02:10+0200] [ALPM] upgraded linux (6.8.9.arch1-2 -> 6.9.1.arch1-1)
[2024-05-18T13:02:10+0200] [ALPM] upgraded nvidia (550.78-2 -> 550.78-4)
[2024-05-18T13:02:10+0200] [ALPM] upgraded xorg-xwayland (23.2.7-1 -> 24.1.0-1)

Maritim · 2024-05-19 11:31:56

I was under the impression that udisksd doesn't care about /etc/fstab. The udisks configuration should be configurable via the gnome-disk-utility application ("Disks" in GNOME). Can you find the Windows partition in there and alter its automount preferences?

Saroumane · 2024-05-19 13:39:02

Same here, all unneeded partitions now auto-mounted since rebooting with kernel 6.9.1-arch1-1
My /etc/udisks2/udisks2.conf and my /etc/fstab have not changed.
I guess I'll have to reference every partition in /etc/fstab and add for each of them "noauto".

Or just just go back to previous kernel (linux-lts or pacman -U file:///var/cache/pacman/pkg/linux-6.8.9.arch1-2-x86_64.pkg.tar.zst) and wait 6.9.x with x > 4 (to be extra safe)

Last edited by Saroumane (2024-05-19 13:42:38)

seth · 2024-05-19 14:44:21

Does the kernel downgrade actually prevent this?
Are you also using gnome?
What are those filesystems and disks (internal or external sata, usb)?

EnricoPalazz0 · 2024-05-19 16:26:04

Same here too, all unneeded partitions now auto-mounted since rebooting. :-(
- yep, on gnome46, X11, nVidia 55.78-4
- internal SSDs with more partitions with ext4 filesysrem

Last edited by EnricoPalazz0 (2024-05-19 16:31:36)

seth · 2024-05-19 16:59:31

Does gnome's automounter think they're usb devices?
https://unix.stackexchange.com/question … untu-16-04

gsettings get org.gnome.desktop.media-handling automount
gsettings set org.gnome.desktop.media-handling automount false

If you disable that, do they still automount?

amhairghin · 2024-05-19 17:29:57

seth wrote:

Does gnome's automounter think they're usb devices?
https://unix.stackexchange.com/question … untu-16-04
gsettings get org.gnome.desktop.media-handling automount
gsettings set org.gnome.desktop.media-handling automount false
If you disable that, do they still automount?

What the automount value does is that if you set it to false it does not automatically mount the drive, but it continues to appear in the main listing in Nautilus when it did not appear before (you had to necessarily go to other locations to search for the drive).

As far as I see it happens with internal disks that are detected on /dev/sd*, with disks or partitions I have on /dev/nvme* (M.2 disks) it doesn't seem to happen.

It is something that is clearly seen in Nautilus. I don't know if it happens in the KDE equivalent as well but I wouldn't be surprised.

UPDATE: The failure is 100% caused by the Kernel update. If I boot with the LTS version of the kernel it doesn't happen, with the mainline version it does. There is no other change. Something has been introduced in 6.9 that causes this, what I can't tell you is if it is a bug in the kernel as such or a problem in the kernel configuration that Arch Linux does.

UPDATE 2: At the configuration level by Arch does not seem to be since the only changes that have been made have been this one and this one and none touches the configuration. Either the bug is in the version or in the default configuration that Arch does not touch (or that the current configuration does something different in 6.9).

Last edited by amhairghin (2024-05-19 17:45:16)

seth · 2024-05-19 23:18:12

commit 45b96d65ec68f625ad26ee16d2f556e29f715005
Author: Niklas Cassel <cassel@kernel.org>
Date:   Tue Feb 6 22:13:43 2024 +0100

    ata: ahci: a hotplug capable port is an external port
    
    A hotplug capable port is an external port, so mark it as such.
    
    We even say this ourselves in libata-scsi.c:
    /* set scsi removable (RMB) bit per ata bit, or if the
     * AHCI port says it's external (Hotplug-capable, eSATA).
     */
    
    This also matches the terminology used in AHCI 1.3.1
    (the keyword to search for is "externally accessible").
    
    Tested-by: Damien Le Moal <dlemoal@kernel.org>
    Tested-by: Jian-Hong Pan <jhp@endlessos.org>
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Niklas Cassel <cassel@kernel.org>

commit f7131935238d00745638b826f8c31efc8d361435
Author: Niklas Cassel <cassel@kernel.org>
Date:   Tue Feb 6 22:13:42 2024 +0100

    ata: ahci: move marking of external port earlier
    
    Move the marking of an external port earlier in the call chain.
    This is needed for further cleanups.
    No functional change intended.
    
    Tested-by: Damien Le Moal <dlemoal@kernel.org>
    Tested-by: Jian-Hong Pan <jhp@endlessos.org>
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Niklas Cassel <cassel@kernel.org>

yells at me…

amhairghin · 2024-05-20 11:00:27

seth wrote:

commit 45b96d65ec68f625ad26ee16d2f556e29f715005
yells at me…

Yes, that change is 100% to blame. I have recompiled the kernel removing that change and the disks are not automounted.

I understand that from here on a bug would have to be opened in the upstream with all this. I don't know if there is someone with more gallons than me who can do it because I doubt that they will pay much attention to me.

seth · 2024-05-20 15:54:36

They're not supposed to pay attention to you but to their software.

Kernel patches shall not break the userspace, so the only question is "does this break the userspace or only false expectations" resp. whether this only exposed a "bug" in gnome (and pot. other userspace processes) that just automounts everything that's removable and don't discriminate by the bus or media type.

These questions dictate who will have to do something about the situation.
I'd probably file a bug against gnome/nautilus, since it's what's immediately "broken", and have them hash out the details on lkml - it's pretty hard to argue that the patch is somehow "wrong", but if nautilus cannot apply a better™ filter (does the userbase of nautilus care about hotplugging ata devices?), it'll have to be either reverted or extended.

amhairghin · 2024-05-20 16:36:07

@seth you are right, I have opened a bug in Nautilus and let's see what they tell us.

https://gitlab.gnome.org/GNOME/nautilus/-/issues/3441

Update: Issue moved to GVFS -> https://gitlab.gnome.org/GNOME/gvfs/-/issues/738

Last edited by amhairghin (2024-05-21 06:47:11)

lpga · 2024-05-20 16:51:41

same problem here with kernel linux-6.9.1.arch1-1 and KDE.
in the bios the sata controller is set to use ahci and the "external SATA" setting is disabled.
with the kernel linux-lts-6.6.31-1 there is no problem.

With the linux 6.9.1 kernel all SATA disks are automatically defined as removable

$ cat /sys/block/sd*/removable
1

Saroumane · 2024-05-20 16:56:49

I think @lpga has found something : as far as I know Nautilus is not responsible for defining wrong values in /sys/block/sd*/removable (It's the kernel job)
As this kernel update broke userspace, they'll probably revert their commit.

Last edited by Saroumane (2024-05-20 16:58:08)

Scimmia · 2024-05-20 17:03:22

It didn't 'break' userspace, userspace is just fine. The commit makes it clear this was intentional, it's much more likely nautilus or gvfs making a bad assumption.

There's no real problem here, nothing is broken, behavior just changed.

Saroumane · 2024-05-20 17:36:50

@fellow (Edit) you may be right but if found this comment (in the commit) troubling : "...if the AHCI port says it's external (Hotplug-capable, eSATA)." I don't understand exactly the real implications of the "set scsi removable (RMB) bit per ata bit"
Meanwhile @lpga found that this new behavior is enforced even with "external SATA" disabled.

Last edited by Saroumane (2024-05-20 17:40:27)

seth · 2024-05-20 20:40:47

"Hotplug-capable, eSATA" are alternative descriptions of the situation.
The sata port is hotplugging capable and that by its very definition means that the attached drive is removable - whether you've to use a screwdriver to remove the drive doesn't matter itc, but it's oc. not what desktop users (and therefore nautilus' audience) think of.
Whether you've an eSATA port is unrelated to that feature and just spares you the screwdriver.

https://en.wikipedia.org/wiki/SATA#eSATA
https://en.wikipedia.org/wiki/SATA#Hot_plug

amhairghin · 2024-05-21 08:58:17

The issue has been referred to udisks: https://github.com/storaged-project/udisks/issues/1282

lpga · 2024-05-31 14:01:31

My motherboard is an Asrock P67 Extreme6, all the SATA ports are hotplug compatible and the only option in the bios that I can enable or disable for each port is "external SATA" (always keep disabled). There isn't an option to explicitly disable the hoplug function for each or all sata port (I can only set IDE or AHCI mode).

From the recent kernel v. 6.9.x (I assume because of this kernel commit) all partitions on disks connected to SATA ports are marked as removable and managed as such by KDE's device manager (even though all partitions in /etc/fstab were intended as not removable). This problem does not occur with any previous kernel version.

I was therefore wondering if it was possible to write a udev rule to ensure that the partitions listed in /etc/fstab were not marked as removable by the system or at least by the KDE device manager. I searched the Wiki, the udisks manual, and other sources but couldn't find anything about it that would guide me in writing a such udev rule (is the "removable" attribute of udev read-only?). So my temporary solution was to write a rule of a simple list of UUID partitions that the device manager should ignore:

# 61-hidesata.rules
SUBSYSTEM=="block", ENV{ID_FS_UUID}=="UUID of your partition", ENV{UDISKS_IGNORE}="1"

for /, /boot, /home partitions and so on.
I honestly don't like this approach, so i wonder if someone has a better solution.
Thanks in advance.

seth · 2024-05-31 16:01:08

https://wiki.archlinux.org/title/udev#S … e,_are_not - invert the values.
You could discriminate by the ID_BUS==ata environment:

ENV{ID_BUS}=="ata", ENV{UDISKS_AUTO}="0", ENV{UDISKS_SYSTEM}="1"

No idea whether basing this on anything-fstab is possible, you'd probably have to run a script on every device to read the fstab and set the flag externally - what might also be toolate™/non-deterministic.

amhairghin · 2024-06-02 09:22:18

With the idea mentioned by seth:

ENV{ID_BUS}=="ata", ENV{UDISKS_AUTO}="0", ENV{UDISKS_SYSTEM}="1"

What is achieved is that the disks are not automounted at system startup, but they still appear as external disks in Nautilus. To achieve that they do not appear it would be necessary to combine its idea with that of lpga and to ignore the disks:

ENV{ID_BUS}=="ata", ENV{UDISKS_AUTO}="0", ENV{UDISKS_SYSTEM}="1", ENV{UDISKS_IGNORE}="1"

What happens with this is that USB disks are also connected to the ata bus so they are also ignored.

In the end the only real solution would be to do it but by disk ID (i.e. by “manually” selecting which disks are affected):

udevadm info /dev/sdb | grep ID_SERIAL_SHORT # to obtain the disk ID

ENV{ID_SERIAL_SHORT}=="XXXXX", ENV{UDISKS_AUTO}="0", ENV{UDISKS_SYSTEM}="1", ENV{UDISKS_IGNORE}="1"

Although it is necessary to consider that this in the end has the undesired effect that in Nautilus the disk does not appear in any way, that is to say, it does not appear in “Other locations” that is what it did before the update of the kernel.

There is probably some way to make it recognize the disk as internal in GNOME (and show up in “other locations”), but I don't know what it is.

seth · 2024-06-02 12:22:25

What happens with this is that USB disks are also connected to the ata bus so they are also ignored.

Apparently usb drives w/ an internal sata converter (ie. your external hard drive, not a usb key) are detected as ata, https://github.com/systemd/systemd/issues/21450

amhairghin · 2024-06-03 06:44:17

seth wrote:

Apparently usb drives w/ an internal sata converter (ie. your external hard drive, not a usb key) are detected as ata, https://github.com/systemd/systemd/issues/21450

Yes, you are absolutely right, that's why I think the best option is to use the disk ID. It is something less generic that requires a little more work but at least the ID is an element that is not going to change over time (and internal disks are not something that is being changed every day).

On the other hand, I have raised a question to GNOME as I understand that if you have a disk configured as follows:

ENV{ID_SERIAL_SHORT}=="XXXXX", ENV{UDISKS_AUTO}="0", ENV{UDISKS_SYSTEM}="1"

It should not appear as an external disk. Let's see what they tell me because either it is some bug or there is something else that should be able to be configured other than ignoring the disk.

lpga · 2024-06-03 11:07:16

I already tried without success to write a rule using:

ENV{UDISKS_AUTO}="0", ENV{UDISKS_SYSTEM}="1"

I took a look at the udisk code and it seems to me (I'm not a programmer so I could be wrong) that udisk reads the ATTR{removable} attribute directly to determine whether the disk/media is removable or not. So the new way the kernel handles the removable disk definition leads to the new "behavior" of udisk.

the "somewhat ironic" thing is that for my three external USB hard disks the system assigns ATTR{removable}="0".

I have an old laptop (Toshiba Satellite A300, year 2009) with SATA hard drive and "Ahci mode" enabled. I assume the hotplug feature is not supported by the system and in this case the "removable" attribute remains set to "0" even with the new kernel. So in this case there is no problem with KDE device manager.

thank you all.

amhairghin · 2024-06-03 14:26:08

lpga wrote:

I took a look at the udisk code and it seems to me (I'm not a programmer so I could be wrong) that udisk reads the ATTR{removable} attribute directly to determine whether the disk/media is removable or not. So the new way the kernel handles the removable disk definition leads to the new "behavior" of udisk.

Yes, it is clear that the attribute that makes that a disk is presented or not as removable in Nautilus is with ATTR{removable}, the problem is that as far as I see it is a read-only attribute (at least I have tried to modify it and it has told me that it is not possible) so the only solution that I see right now is to use the ignore.

Funny0facer · 2024-06-05 07:33:46

Maybe I do not understand the comment of the kernel commit correctly, but I read it as HOTPLUG should be identical to REMOVABLE.
For me, this would be true for linux-lts (6.6.x), but not for linux (6.9.x)
compare the values of /dev/sda

basti@BASTI-2022-Q4 ~ $ uname -a
Linux BASTI-2022-Q4 6.6.32-1-lts #1 SMP PREEMPT_DYNAMIC Sat, 25 May 2024 20:20:51 +0000 x86_64 GNU/Linux
basti@BASTI-2022-Q4 ~ $ lsblk -o NAME,LABEL,HOTPLUG --filter 'NAME=~"sd[a-z]"'
NAME LABEL     HOTPLUG
sda                  0
sda1 FEDEFI          0
sda2 FEDBOOT         0
sda3 FED             0
sda4 EXCHANGE        0
sda5 ARCH2EFI        0
sda6 ARCH2           0
sdb                  1
sdb1 SANDISK16       1
sdc                  1
sdc1 Ventoy          1
sdc2 VTOYEFI         1
basti@BASTI-2022-Q4 ~ $ for file in /sys/class/block/sd*/removable ; do echo $file :$(cat $file); done
/sys/class/block/sda/removable :0
/sys/class/block/sdb/removable :1
/sys/class/block/sdc/removable :1

basti@BASTI-2022-Q4 ~ $ uname -a
Linux BASTI-2022-Q4 6.9.3-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 31 May 2024 15:14:45 +0000 x86_64 GNU/Linux
basti@BASTI-2022-Q4 ~ $ lsblk -o NAME,LABEL,HOTPLUG --filter 'NAME=~"sd[a-z]"'
NAME LABEL     HOTPLUG
sda                  0
sda1 FEDEFI          0
sda2 FEDBOOT         0
sda3 FED             0
sda4 EXCHANGE        0
sda5 ARCH2EFI        0
sda6 ARCH2           0
sdb                  1
sdb1 SANDISK16       1
sdc                  1
sdc1 Ventoy          1
sdc2 VTOYEFI         1
basti@BASTI-2022-Q4 ~ $ for file in /sys/class/block/sd*/removable ; do echo $file :$(cat $file); done
/sys/class/block/sda/removable :1
/sys/class/block/sdb/removable :1
/sys/class/block/sdc/removable :1

Arch Linux

#1 2024-05-19 11:12:12

GNOME mounts a disk that is not included in fstab

#2 2024-05-19 11:31:56

Re: GNOME mounts a disk that is not included in fstab

#3 2024-05-19 13:39:02

Re: GNOME mounts a disk that is not included in fstab

#4 2024-05-19 14:44:21

Re: GNOME mounts a disk that is not included in fstab

#5 2024-05-19 16:26:04

Re: GNOME mounts a disk that is not included in fstab

#6 2024-05-19 16:59:31

Re: GNOME mounts a disk that is not included in fstab

#7 2024-05-19 17:29:57

Re: GNOME mounts a disk that is not included in fstab

#8 2024-05-19 23:18:12

Re: GNOME mounts a disk that is not included in fstab

#9 2024-05-20 11:00:27

Re: GNOME mounts a disk that is not included in fstab

#10 2024-05-20 15:54:36

Re: GNOME mounts a disk that is not included in fstab

#11 2024-05-20 16:36:07

Re: GNOME mounts a disk that is not included in fstab

#12 2024-05-20 16:51:41

Re: GNOME mounts a disk that is not included in fstab

#13 2024-05-20 16:56:49

Re: GNOME mounts a disk that is not included in fstab

#14 2024-05-20 17:03:22

Re: GNOME mounts a disk that is not included in fstab

#15 2024-05-20 17:36:50

Re: GNOME mounts a disk that is not included in fstab

#16 2024-05-20 20:40:47

Re: GNOME mounts a disk that is not included in fstab

#17 2024-05-21 08:58:17

Re: GNOME mounts a disk that is not included in fstab

#18 2024-05-31 14:01:31

Re: GNOME mounts a disk that is not included in fstab

#19 2024-05-31 16:01:08

Re: GNOME mounts a disk that is not included in fstab

#20 2024-06-02 09:22:18

Re: GNOME mounts a disk that is not included in fstab

#21 2024-06-02 12:22:25

Re: GNOME mounts a disk that is not included in fstab

#22 2024-06-03 06:44:17

Re: GNOME mounts a disk that is not included in fstab

#23 2024-06-03 11:07:16

Re: GNOME mounts a disk that is not included in fstab

#24 2024-06-03 14:26:08

Re: GNOME mounts a disk that is not included in fstab

#25 2024-06-05 07:33:46

Re: GNOME mounts a disk that is not included in fstab

Board footer