SUMMARY I have a partition drive ("BACKUP") that is not mounted at boot time. When I want to access it, Dolphin asks for the superuser password and there is no problem accessing it or creating folders or files. However, when I try to make a copy ("Partition, Backup") of a partition from another disk to this "Backup" partition (regardless of whether I have previously mounted the "Backup" partition with Dolphin or not), "partitionmanager" displays a window with the error message "The specified folder does not exist or could not be read", and I cannot make the copy. The same procedure, with other partitioners like "Disks" (Gdisks) can access to write to the "BACKUP" partition to write the copy file without problems. STEPS TO REPRODUCE 1. Select a partition from "A" disk 2. "Partition, Backup" 3. In "Save file" window, select "BACKUP" partition in "B" disk (owned by root) OBSERVED RESULT "partitionmanager" displays a window with the error message "The specified folder does not exist or could not be read". EXPECTED RESULT Two options: - If "BACKUP" partition not mounted, ask for root password) - If "BACKUP" partition is mounted (from Dolphin) simply leave user select "BACKUP" partition and a folder. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230613 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 Kernel Version: 6.3.7-1-default (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION
I would guess that it's not the mount status but ownership by root of disk B. PartitionManager always tries to save backup as your own user (to avoid creating root owned files is e.g. your home directory). If disk B is owned by root, then that's the reason for failure.
I understand the logic. However, it is also logical that if the user selects a user/password protected disk or partition, it will ask the user for this information and only if they are incorrect, deny access. This is how other applications (such as those mentioned above) that allow partition copying do it. I think this should be an improvement to implement because in the meantime, I won't be able to use the KDE partitioner to make partition copies.
Perhaps, though I couldn't get Gnome disks to make backup at all to root owned location... When I try to use gnome disks to write backup image somewhere in my home directory, then it works. When I tried to save image to root owned location, gnome disks just crashed for me...
I mistook the name of the partitioning application. It is "DISKS" not "GPARTED". And I have also found that it asks for the root password ALWAYS when a partition backup operation is to be performed, regardless of the destination to be chosen for the image file. That is to say, it works as I said, but it really requires root privileges to be able to take control of the partition to be backed up, regardless of whether or not the destination requires root permissions.
Created attachment 167780 [details] DISKS - Selecting source partition to backup
Created attachment 167781 [details] Asking for password when I select "Start creating"
(In reply to Rafael Linux User from comment #4) > . And I have also found that it asks for the root password ALWAYS > when a partition backup operation is to be performed, regardless of the > destination to be chosen for the image file. That is to say, it works as I > said, but it really requires root privileges to be able to take control of > the partition to be backed up, regardless of whether or not the destination > requires root permissions. Yes, of course you need root permissions to read the device. KDE Partition Manager also needs root permissions for that, but you have already entered root password on its startup. It keeps those permissions and doesn't need to ask again. The issue for Partition Manager is really just permissions for output location. At this point it does not use those root privileges for output files as it it easy to end up with root owned files in your home directory (or somewhere else you don't want them). Perhaps we need some kind of detection logic depending on whether destination path is user or root writable. And yes, I tried exactly the same thing in gnome disks (version 45.1) and it just crashes on my system.
(In reply to Andrius Štikonas from comment #7) > > (or somewhere else you don't want them). Perhaps we need some kind of > detection logic depending on whether destination path is user or root > writable. I agree, cause meanwhile, I can't use the KDE partition tool to do backups that way and need to use Gnome based one.
(In reply to Rafael Linux User from comment #8) > (In reply to Andrius Štikonas from comment #7) > > > > (or somewhere else you don't want them). Perhaps we need some kind of > > detection logic depending on whether destination path is user or root > > writable. > > I agree, cause meanwhile, I can't use the KDE partition tool to do backups > that way and need to use Gnome based one. Well, you could always manually adjust destination permissions with chown... Anyway, keep in mind that gnome disks and kde partition manager backup slightly different things. From what I just saw, gnome disks backups whole device, e.g. /dev/sda whereas KDE Partition Manager backups /dev/sda1
(In reply to Andrius Štikonas from comment #9) > (In reply to Rafael Linux User from comment #8) > > (In reply to Andrius Štikonas from comment #7) > > > > > > (or somewhere else you don't want them). Perhaps we need some kind of > > > detection logic depending on whether destination path is user or root > > > writable. > > > > I agree, cause meanwhile, I can't use the KDE partition tool to do backups > > that way and need to use Gnome based one. > > Well, you could always manually adjust destination permissions with chown... Not the way if there are tools that take it into account and let user to do all from that tool. That's how I would like KDE Partitioner to work. > > Anyway, keep in mind that gnome disks and kde partition manager backup > slightly different things. From what I just saw, gnome disks backups whole > device, e.g. /dev/sda whereas KDE Partition Manager backups /dev/sda1 No. "DISKS" let user make backup from whole disk or individual partitions (like I showed in first attached screenshot). I don't understand why KDE have not same features in 2024 .... :(
(In reply to Rafael Linux User from comment #10) > (In reply to Andrius Štikonas from comment #9) > > (In reply to Rafael Linux User from comment #8) > > > (In reply to Andrius Štikonas from comment #7) > > > > > > > > (or somewhere else you don't want them). Perhaps we need some kind of > > > > detection logic depending on whether destination path is user or root > > > > writable. > > > > > > I agree, cause meanwhile, I can't use the KDE partition tool to do backups > > > that way and need to use Gnome based one. > > > > Well, you could always manually adjust destination permissions with chown... > Not the way if there are tools that take it into account and let user to do > all from that tool. That's how I would like KDE Partitioner to work. > > > > Anyway, keep in mind that gnome disks and kde partition manager backup > > slightly different things. From what I just saw, gnome disks backups whole > > device, e.g. /dev/sda whereas KDE Partition Manager backups /dev/sda1 > > No. "DISKS" let user make backup from whole disk or individual partitions > (like I showed in first attached screenshot). I don't understand why KDE > have not same features in 2024 .... :( Well, different people were focussing on different features on different tools... E.g. Gnome disks can't resize LVM logical volumes or LUKS containers. Or even move normal partitions to another place on the disk (you have to backup partition, delete the old one, create a new one and restore).