Now when I boot the PC and in KDE, I get a popup that requests for my sudo password in order to mount the disk /10T_2, but the disk is already mounted and I can fully access it.
So why this popup, and howto get rid of it ?
I don’t get a popup for disk /10T_1 that is mounted as ext4, but for disk /10T_2 moounted as btrfs, there is this popup to mount it although it is already mounted.
A btrfs volume is usually not mounted as a whole — instead, one would mount a subvolume.
Attempting to mount the filesystem without specifying a subvolume will mount the default subvolume, which — unless you’ve changed that — is the root subvolume. It is therefore possible that, even though you have the root subvolume mounted already (via /etc/fstab), dolphin is trying to mount another subvolume on the filesystem.
btrfs is a very complex filesystem in comparison to ext4 or other traditional filesystem types. If you don’t understand how it works, then you’re probably better off just using ext4.
I can only guess that the permissions on the mountpoint and/or on the contents of the root subvolume of the btrfs partition are such that you need root access in order to be able to read them. This too would prompt you for a password.
I can read and write on the entire disk, and permissions are rwx for owner and group.
There is an identical disk formatted in ext4, and permissions and owner are identical, so strange that I get a popup for the btrfs disk, while it is completely accessible.
Both disks are for data storage, and I use the btrfs disk as a passive backup for the ext4 disk, and I regularly use rsync to copy incremental changes from the ext4 to the btrfs disk.
The btrfs disk is only physically connected when making this backups.
It is possible that the authentication dialog is not for the drive itself, but for a particular folder on the drive. Without any detailed context, there is little else I can add.
I can however point you at two very long but elaborate and relevant tutorials.
With btrfs, the mount command should specify the subvolume.
If no subvolume is specified, the “default” subvolume is mounted.
However, I don’t know which subvolume will be used as the default if you haven’t created any subvolume at all.
Your approach might seem logical to you, but it’s extremely unusual for btrfs. Btrfs works with subvolumes, and even a standard installation automatically creates at least one subvolume named “@”. This is then set as the default subvolume.
What calamares does not do is set the default subvolume. This remains at the subvolume with subvolid=5, which is the root subvolume.
If you manually create a btrfs filesystem by way of mkfs.btrfs or by way of a GUI partitioning tool such as gparted or partitionmanager, then there won’t be any subvolumes other than the root subvolume with subvolid=5, but this root subvolume is not the same thing as @, which is itself a subvolume of the root subvolume and which will have subvolid=256 if it’s the first one created. Setting the default subvolume must always be done explicitly, because otherwise it will be the root subvolume.
calamaresdoes not set the root subvolume to @. If it did, then I wouldn’t have needed to write a patch to manjaro-chroot to allow it to work with btrfs, because the way manjaro-chroot automatically mounts all the required partitions and/or subvolumes is by parsing /etc/fstab, but with the default calamares-created subvolume layout, the path to that file from the filesystem root (when the default subvolume is the root subvolume) is /@/etc/fstab. And that’s why manjaro-chroot couldn’t find it.
I was finally able to solve the double mount problem, it had nothing to do with btrfs.
I dual boot with debian, and the problem appeared after I did a disk to image backup with clonezilla.
I would never have imagined that using clonezilla could provoke this effect, by just making a clone image of my SSD.
Apparently clonezilla add an entry as an additional boot option, and after the cloning, when I removed the usb stick, the boot system got confused between my old debian /boot/efi entry, and the newer manjaro entry.
In chroot, i removed the /boot/efi/debian directory to avoid the confusion between the two grub boot instances, and updated grub.
after this the system reacted normal again, and the kde popup to mount the btrfs drive was gone.
It took me a while to figure this out, with the help of deepseek AI.
I used clonezilla only to make an image of the disk, I did not restore anything.
Booted from a USB stick containing clonezilla,
selected the disk to image clone,
after cloning the disk, shutdown the pc and remove the usb stick.
So I was very surprised that making a backup only could mess up things.
