KDE / Dolphin won't update its devices list

Terminally ill · 2024-12-09 21:52:29

I posted about this here but got no bites, so I've done some more digging with a refresh ming on the problem.

My fstab entry:

UUID="33b21784-8b86-45d5-afb7-94b5f33041d1" /vm btrfs compress=zstd:3 0 0

Running lsblk:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 232.9G 0 disk
└─sda1 8:1 0 232.9G 0 part
sdb 8:16 0 232.9G 0 disk
└─sdb1 8:17 0 232.9G 0 part /vm

When I check journalctl, I can see this line when mounting

kernel: BTRFS info (device sdb1): first mount of filesystem 33b21784-8b86-45d5-afb7-94b5f33041d1

If I go back in time with "journalctl -b 10", before I added a 3rd disk (/dev/sdc), I can see it was mount the other drive

kernel: BTRFS info (device sda1): first mount of filesystem 33b21784-8b86-45d5-afb7-94b5f33041d1

And when I try to click on the device in Dolphin, I get an authentication window saying:

"Authentication is required to mount Samsung 840 EVO 250GB (/dev/sda1)

So all this leads me to believe that when I added the 3rd disk, the kernel has started mounting sdb1 instead of sda1, and Dolphin isn't picking up on that fact.

So my solutions are either,
1. Get the kernel to mount sda again
2. Tell Dolphin to check the mount properly based on what the kernel is doing

Ideally its solution #2, so I've been scouring the internet and looked into polkit and udisk, but I don't think they're the culprit here, and I don't know enough about the Linux desktop to know where to go from here.

seth · 2024-12-10 09:49:30

The device name order isn't deterministic - after reading your previous thread I'd have told you to address the device via its UUID, but apparently you're already doing that?

lsblk -f

Also https://bugs.kde.org/show_bug.cgi?id=466600 - but that seems fixed.

Since the drive shows up in fstab, dolphin likely considers it an internal drive and won't offer it in the device list at all?
You're probably looking for a places bookmark instead (since the drive is auto-mounted anyway) but there's apparently also a feature to (un)hide drives?

Terminally ill · 2024-12-13 06:28:50

lsblk -f shows:

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
└─sda1 btrfs VMs 33b21784-8b86-45d5-afb7-94b5f33041d1
sdb
└─sdb1 btrfs VMs 33b21784-8b86-45d5-afb7-94b5f33041d1 125.7G 46% /vm

Yep, every drive is addressed by UUID in fstab.
The device has always been listed under "Devices", along with my other internal drives; Root, Backup, 2tb drive; all listed in Dolphin with the FS Label. It's still there now, but appears with a little orange icon on it. https://imgur.com/r1tVmIG

The only difference is I now have a third disk. I'll try unplugging it and coming back with the results, but naturally removing it is not a solution for me.

seth · 2024-12-13 08:47:12

Is that all?
You've 2 disks, not 3 and one partition on each is one partition and the partitions have the same UUID
Are they clones? Doesn't look like a mdadm/lvm raid setup?

I guess neither is the one you're looking for? What's the nature of the third disk? External USB?
If it's an external disk, unplug it, run "dmesg -W", re-plug it and post the output.

Terminally ill · 2024-12-13 12:54:55

Sorry, guess paranoia is getting the better of me for no reason. Here's my full fstab:

# Static information about the filesystems.
# See fstab(5) for details.
# <file system> <dir> <type> <options> <dump> <pass>
# Root subvolume on /dev/nvme0n1p2
UUID=ecc43cac-118c-43f6-8f6d-5c18eb0bb913 /    btrfs    rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=256,subvol=/@ 0 0
# Home subvolume on /dev/nvme0n1p2
UUID=ecc43cac-118c-43f6-8f6d-5c18eb0bb913 /home    btrfs    rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=257,subvol=/@home 0 0
# Other subvolumes on /dev/nvme0n1p2
UUID=ecc43cac-118c-43f6-8f6d-5c18eb0bb913 /var/log    btrfs    rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvol=/@var_log0 0
UUID=ecc43cac-118c-43f6-8f6d-5c18eb0bb913 /var/tmp    btrfs    rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvol=/@var_tmp0 0
UUID=ecc43cac-118c-43f6-8f6d-5c18eb0bb913 /var/cache    btrfs    rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvol=/@var_cache 0 0
UUID=ecc43cac-118c-43f6-8f6d-5c18eb0bb913 /var/spool    btrfs    rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvol=/@var_spool 0 0
# /dev/nvme0n1p1
UUID=3BFA-9802 /efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 2
UUID=3BFA-9802 /boot/efi vfat defaults 0 1
# SWAP
UUID="aaab2f9d-d639-470a-b01f-1396c3b6dc05" none swap sw 0 0
# RAID1 for Virtual Machines
UUID="33b21784-8b86-45d5-afb7-94b5f33041d1" /vm btrfs compress=zstd:3 0 0
# 2TB for Data
UUID="a0882106-2cd1-4463-8d24-baf73c2f6805" /2tb-data btrfs compress=zstd:3 0 0
# 1TB SATA for Backup
UUID="a8c519ee-4ca7-4f7a-88e8-c5dfd91a2b4a" /backup btrfs compress=zstd:3 0 0

Nothing is external, everything is either NVME or SATA.
They're not clones, they're a BTRFS mirror. Thus why they've got the same UUID. I've tried adding "device=/dev/sda" to the mount options for /vm but it didn't take effect, no matter what since I've added /dev/sdc it keeps primarily mounting /dev/sdb as the "primary" drive in the mirror.

seth · 2024-12-13 15:48:20

Please use [code][/code] tags, not "quote" tags. Edit your post in this regard.

Fwwi, the UUIDs are meaningless (they exist for collision prevention) but if you'd worry, you could perfectly pseudonymize them (main the structure and XOR them with a constant salt)

However, the main question remains where are a0882106-2cd1-4463-8d24-baf73c2f6805 - /2tb-data and a8c519ee-4ca7-4f7a-88e8-c5dfd91a2b4a - /backup in your lsblk?
These drives don't show up at all - nor do the nvme's (which is why I guess the lsblk output is just some snippet)

In doubt please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

(it's not supposed to contain any sensitive data, occasionally publically routable IPv6 have show up but I've not seen that in a long time. Also sudo is audited, so "sudo mpv porn.mp4" calls will show up there )

Terminally ill · 2024-12-13 22:25:35

Yep, I know there's no public information there - just being paranoid that posting excessive information is a potential attack vector, but realistically that chance is insanely low....
Thanks for your patience with my hesitation.
Haven't set up IPv6 yet so its fine, the worst thing will be "sudo dumb-command"

My boot journal: https://0x0.st/XFMf.txt

For completeness sake, here's the full lsblk -f, with correct tags (Thanks for heads up, I'm still learning how to use this forum)

NAME        FSTYPE FSVER LABEL        UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
└─sda1      btrfs        VMs          33b21784-8b86-45d5-afb7-94b5f33041d1
sdb
└─sdb1      btrfs        VMs          33b21784-8b86-45d5-afb7-94b5f33041d1    126G    46% /vm
sdc
└─sdc1      btrfs        Backup       a8c519ee-4ca7-4f7a-88e8-c5dfd91a2b4a  723.5G    22% /backup
nvme0n1
├─nvme0n1p1
├─nvme0n1p2 ntfs         Recovery     7C43315FBBF7A6E9
├─nvme0n1p3 vfat   FAT32              278B-33B4
├─nvme0n1p4 ntfs         NVMe Windows 9A462EF8F587E0E8
└─nvme0n1p5 ntfs                      703CC9243CC8E5E6
nvme1n1
└─nvme1n1p1 btrfs        2TB-Data     a0882106-2cd1-4463-8d24-baf73c2f6805  776.8G    58% /2tb-data
nvme2n1
├─nvme2n1p1 vfat   FAT32              3BFA-9802                            1014.2M     1% /efi
│                                                                                         /boot/efi
├─nvme2n1p2 btrfs        Root         ecc43cac-118c-43f6-8f6d-5c18eb0bb913  176.6G    58% /var/log
│                                                                                         /home
│                                                                                         /var/tmp
│                                                                                         /var/spool
│                                                                                         /var/cache
│                                                                                         /
└─nvme2n1p3 swap   1                  aaab2f9d-d639-470a-b01f-1396c3b6dc05                [SWAP]

/dev/nvme0n1 is my Windows install, and is the only device I have hidden in Dolphin.

seth · 2024-12-13 22:50:24

So summary:
You've 3 sata's and 3 nvme's
nvme0n1: windows
nvme1n1: 2TB data
nvme2n1: linux OS

sdc: backup
sdb: /vm
sda: mirrors sdb

All but windows and the mirror are mounted as expected.

Trying to access one of the sda/sdb mirrors in dolphin fails - the reason for that is incredibly likely to be the UUID collision, ie. that sda and sdb are completely indistinguishable.
Replace

UUID="33b21784-8b86-45d5-afb7-94b5f33041d1"    /vm    btrfs    compress=zstd:3    0 0

with either

/dev/sda1    /vm    btrfs    compress=zstd:3    0 0

or

/dev/sdb1    /vm    btrfs    compress=zstd:3    0 0

ie. use a (volatile but) unique identifier and see what happens.

Terminally ill · 2024-12-14 00:12:57

I believe the similar UUID is intentional? This was done automatically when creating the btrfs raid set. I see the same thing on my proxmox server with zfs, where all members of an array have the same UUID.

Here's the new fstab snippet: (I assume you no longer need the full output, so I'm keeping clutter down)

# RAID1 for Virtual Machines
#UUID="33b21784-8b86-45d5-afb7-94b5f33041d1"    /vm     btrfs   compress=zstd:3 0 0
/dev/sda1                                       /vm     btrfs   compress=zstd:3 0 0

Rebooted, and the problem in Dolphin remains unchanged. Here is a screenshot along with the prompt when double-clicking on "VMs" https://imgur.com/x4TLN4v (Samsung 840 Evo is /dev/sda)

Here is the lsblk -f snippet

NAME        FSTYPE FSVER LABEL        UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
└─sda1      btrfs        VMs          33b21784-8b86-45d5-afb7-94b5f33041d1
sdb
└─sdb1      btrfs        VMs          33b21784-8b86-45d5-afb7-94b5f33041d1    126G    46% /vm

I'm at a loss. Its still mounting sdb1 regardless of my fstab.

Last edited by Terminally ill (2024-12-14 00:13:44)

Terminally ill · 2024-12-14 03:07:25

I ended up blowing away the array, and rebuilding.

When rebuilding I noticed that the 2nd "unmounted" drive appears in the Dolphin devices list, so seeing that I believe I did have it hidden and assumed otherwise without checking.

I'm not sure why it decided to start mounting the other drive. Something to be aware of in future I guess.

Thanks for your help seth.

seth · 2024-12-14 08:17:14

I''ve never use a btrfs array, do the partitions actually (still) have the same UUIDs?

Edit: Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Last edited by seth (2024-12-14 08:17:30)

Arch Linux

#1 2024-12-09 21:52:29

KDE / Dolphin won't update its devices list

#2 2024-12-10 09:49:30

Re: KDE / Dolphin won't update its devices list

#3 2024-12-13 06:28:50

Re: KDE / Dolphin won't update its devices list

#4 2024-12-13 08:47:12

Re: KDE / Dolphin won't update its devices list

#5 2024-12-13 12:54:55

Re: KDE / Dolphin won't update its devices list

#6 2024-12-13 15:48:20

Re: KDE / Dolphin won't update its devices list

#7 2024-12-13 22:25:35

Re: KDE / Dolphin won't update its devices list

#8 2024-12-13 22:50:24

Re: KDE / Dolphin won't update its devices list

#9 2024-12-14 00:12:57

Re: KDE / Dolphin won't update its devices list

#10 2024-12-14 03:07:25

Re: KDE / Dolphin won't update its devices list

#11 2024-12-14 08:17:14

Re: KDE / Dolphin won't update its devices list

Board footer