Bug 407192

Summary: Filesystems created by Partition manager are owned by root
Product: [Applications] partitionmanager Reporter: Matej Mrenica <matejm98mthw>
Component: generalAssignee: Andrius Štikonas <andrius>
Status: RESOLVED FIXED    
Severity: normal CC: amanita+KDEBUGS, brucewwayne1234, bugseforuns, ianp, karpaz, katyaberezyaka, kde.lwzr1, leftcrane, nate, nortexoid, oguilherme, pieterkristensen, stefan.bruens
Priority: VHI    
Version: unspecified   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In: 22.04.0

Description Matej Mrenica 2019-05-03 19:13:15 UTC
SUMMARY
New partitions with these filesystems are owned by root after creation and so cannot be written to without chown-ing first: XFS, Btrfs, Ext4

EXPECTED RESULT
New partitions are owned by user so they can be used (written to) normally.

SOFTWARE/OS VERSIONS
Partition manager 4.0.0
KDE Plasma Version: 5.15.4
KDE Frameworks Version: 5.57
Qt Version: 5.13.0beta1
Comment 1 Andrius Štikonas 2019-05-03 19:40:33 UTC
Hmm, I'm not sure if it's partition manager's responsibility to do that. It might be whoever is mounting (Solid?).

I discussed it briefly with Fedora packager some time ago (after fedora bug was open https://bugzilla.redhat.com/show_bug.cgi?id=1538641)
It was actually Fedora packager who thought that this is not partition manager's responsibility.

Well, let's keep this bug open, to track this issue even though I was aware of it.
Comment 2 Nate Graham 2019-05-09 15:14:34 UTC
This is probably a side effect of running the whole app as root. Now that partition manager uses polkit, hopefully that will fix or alleviate the issue. If not, it really should explicitly return ownership of the new partition to the user who has just made it.
Comment 3 Andrius Štikonas 2019-05-09 17:49:38 UTC
(In reply to Nate Graham from comment #2)
> This is probably a side effect of running the whole app as root. Now that
> partition manager uses polkit, hopefully that will fix or alleviate the
> issue. If not, it really should explicitly return ownership of the new
> partition to the user who has just made it.

In principle I can run chown after creating the partition. But the question is why is this partition manager's job.

Shouldn't it be the job of whatever mounts the new partition (Solid?).

Let's say user A has two computers, on one computer his UID is 1000, on another, 1001.

If the user formats USB stick with Ext4 on the first computer, that user won't have permissions on the other computer. Shouldn't this be done while mounting from e.g. Dolphin/Plasma?
Comment 4 Andrius Štikonas 2019-05-09 18:17:55 UTC
(In reply to Nate Graham from comment #2)
> This is probably a side effect of running the whole app as root. Now that
> partition manager uses polkit, hopefully that will fix or alleviate the
> issue. If not, it really should explicitly return ownership of the new
> partition to the user who has just made it.

By the way, GUI running as normal user wouldn't fix it. All operations are still done with root privileges, e.g. sfdisk or mkfs.ext4 runs as root.
Comment 5 Nate Graham 2019-05-12 21:57:42 UTC
So should we move this bug to frameworks-solid?
Comment 6 Andrius Štikonas 2019-05-12 22:00:49 UTC
(In reply to Nate Graham from comment #5)
> So should we move this bug to frameworks-solid?

I don't know... But it would be good to know opinion of more people on who should change permissions.

Maybe solid people would think that we shouldn't change permissions when we mount external devices in solid.

Do you know who maintains Solid? Maybe we can add them to CC on this bug and ask what they think?
Comment 7 Nate Graham 2019-05-12 22:02:11 UTC
CCing Stefan Brüns, the pseudo/de-facto maintainer these days. :)
Comment 8 Andrius Štikonas 2019-05-17 18:13:54 UTC
*** Bug 353651 has been marked as a duplicate of this bug. ***
Comment 9 Andrius Štikonas 2019-05-30 12:09:04 UTC
*** Bug 408105 has been marked as a duplicate of this bug. ***
Comment 10 Stefan Brüns 2019-05-30 17:46:55 UTC
Permissions for filesystems supporting permission models are in general completely handled by the kernel, which uses the permissions of the filesystem.

There is no way of overriding the filesystem permissions, neither by mount options nor by any other means. If you want non-root access, you have to change the root directory of the filesystem.

The only outlier is ntfs-3g, which defaults to full access for everybody and optionally allows to use use e.g. the Posix permission model.
Comment 11 Andrius Štikonas 2019-05-30 17:57:11 UTC
(In reply to Stefan Brüns from comment #10)
> Permissions for filesystems supporting permission models are in general
> completely handled by the kernel, which uses the permissions of the
> filesystem.
> 
> There is no way of overriding the filesystem permissions, neither by mount
> options nor by any other means. If you want non-root access, you have to
> change the root directory of the filesystem.
> 
> The only outlier is ntfs-3g, which defaults to full access for everybody and
> optionally allows to use use e.g. the Posix permission model.

hmm, I wonder what gnome-disks does then. Maybe it runs chown user on newly formatted USB stick. Although, I don't think it's always the right thing to do.
Comment 12 PK 2019-05-31 06:08:08 UTC
This is not only the case when formatting usb media. Also when I create a partition on my harddrive/ssd to write (backup)data to using partition manager it will be read only. But when I use gnome disks it will be read/write, what is exactly what I want.
Comment 13 Andrius Štikonas 2019-06-01 15:41:28 UTC
(In reply to PK from comment #12)
> This is not only the case when formatting usb media. Also when I create a
> partition on my harddrive/ssd to write (backup)data to using partition
> manager it will be read only. But when I use gnome disks it will be
> read/write, what is exactly what I want.

Yes, I agree that it makes much more sense for removable devices only.
Comment 14 Patrick Silva 2019-06-17 15:40:41 UTC
I have the same problem. Gparted and even mkfs.ext4 command also create an ext4 partition
owned by root. Gnome-disks is the only app that can create ext4 partition owned by my user.

Operating System: Arch Linux 
KDE Plasma Version: 5.16.0
KDE Frameworks Version: 5.59.0
Qt Version: 5.12.3
Comment 15 Stefan Brüns 2019-06-17 18:19:33 UTC
mkfs.ext4 has an extended option, "-E root_owner[=UID:GID]" to set the UID/GID. Unfortunately, mkfs.btrfs has not.

The behavior should be selectable.
Comment 16 PK 2019-06-17 18:24:34 UTC
It would be great if you could choose if the partition would belong to root or to you. Then you could have it exactly your way. 
Great!
Comment 17 PK 2019-11-05 05:11:57 UTC
The summary of this bug reads: New partitions with these filesystems are owned by root after creation and so cannot be written to without chown-ing first: XFS, Btrfs, Ext4...
Yesterday I got Partition manager 4.0.0.2 on my Debian Testing box and did some experimenting with it.
I noticed that indeed all is fine with fat32 and ntfs but also I noticed that it still wasn't with the above mentioned filesystems.
Only I also formatted a usb-key to f2fs and that turned out to be root-owned too!
Comment 18 Andrius Štikonas 2020-01-07 22:05:26 UTC
*** Bug 415964 has been marked as a duplicate of this bug. ***
Comment 19 Nate Graham 2020-11-25 02:24:07 UTC
*** Bug 423810 has been marked as a duplicate of this bug. ***
Comment 20 Nate Graham 2020-12-08 16:11:49 UTC
*** Bug 430135 has been marked as a duplicate of this bug. ***
Comment 21 Nate Graham 2021-02-04 23:46:11 UTC
This issue just annoyed my wife after she partitioned a new backup hard drive she bought. The distro is KDE Neon User Edition. She commented that if I hadn't been present, she would have thought the hard drive was broken and tried to return it.

It would be great if we could find a solution to this issue, one way or another. As-is, it makes partition operations require an esoteric manual step afterwards that the average user may not be equipped to handle.
Comment 22 Thibault Molleman 2021-03-07 09:57:30 UTC
For people who come across this bug. What's the correct permission command they should run to 'manually' set it correctly?
Comment 23 PK 2021-03-07 10:10:47 UTC
On my ubuntu based machine:
- if it's a partition on your machine:
first 
sudo chgrp adm /media/user/NamePartition
then
sudo chmod g+w /media/user/NaamPartition 
and the reboot. The partition will be writable after this.
- the above mentioned only works on your own machine. So if it's a "mobile" device (hdd,ssd of usb) the only way is to choose fat32 as filesystem or ntfs if it must be bigger than 2 tb.

I have never found an other way to make it work "out the box" with ext4, f2fs, btrfs etc. Gnome Disks can do it but I don't know how. At least in my own experience with ext4 and usb medium.
Comment 24 Andrius Štikonas 2021-03-07 10:38:27 UTC
(In reply to PK from comment #23)
> On my ubuntu based machine:
> - if it's a partition on your machine:
> first 
> sudo chgrp adm /media/user/NamePartition
> then
> sudo chmod g+w /media/user/NamePartition 

This looks like you are granting permissions to adm group only. This might work for your use on your machine, but I think if you want it to work everywhere you need
sudo chmod +w /partition/mount/point

or possibly sudo chmod +w -R /partition/mount/point
Comment 25 PK 2021-03-07 12:26:18 UTC
Would chmod do the trick? I am by far no expert, but is chmod not made to set the permissions of files and directories? 
Perhaps you need to change the permissions for the whole filesystem here. 
Fat32 works all the time just because there is no user-ownership of files. Hence it makes no difference what user writes anything on what machine.
Comment 26 Nate Graham 2021-03-07 13:33:58 UTC
(In reply to Andrius Štikonas from comment #24)
> or possibly sudo chmod +w -R /partition/mount/point
Could we have Partition Manager do this automatically if needed?
Comment 27 Andrius Štikonas 2021-03-07 15:41:10 UTC
(In reply to Nate Graham from comment #26)
> (In reply to Andrius Štikonas from comment #24)
> > or possibly sudo chmod +w -R /partition/mount/point
> Could we have Partition Manager do this automatically if needed?

I think it should be possible. But We probably should try to determine if device is removable first.
Comment 28 Andrius Štikonas 2021-03-21 20:15:00 UTC
*** Bug 434729 has been marked as a duplicate of this bug. ***
Comment 29 ianp 2021-03-31 18:56:46 UTC
I finally found a GUI way to change the permissions for non IT pros:

1. Start the program Krusader (if installed)
2. Go to Tools->"Start Root Mode Krusader"
3. Click the devices Icon to show the partition
4. Right Click it and choose Properties
5. Go to the tab Permissions
6. For Owner set your user and group "adm"
7. Set "Can view and modify content"
8. Tick "Apply to subfolders" then OK

A bit hidden and long winded. But better than nothing in an emergency.
Comment 30 PK 2021-04-01 05:17:55 UTC
As I understand the fact that ext4 links owner-rights to all files stands in the way of making a writabel-for-all usb-stick.
The methode of Ianp (comment 29) could very well be a way out. But I can imagine that there are also users who are not member of de "admin" group. Perhaps it would be smarter to choose a group all users are a member of. If such a group exists.
That could be the way out, making the content of a medium be owned by a group everybody is a member of...
Comment 32 Michael D 2021-12-28 17:25:11 UTC
Awesome, thanks!
Comment 33 Andrius Štikonas 2022-02-20 16:48:36 UTC
*** Bug 450620 has been marked as a duplicate of this bug. ***
Comment 34 Mr.Nobody 2022-03-11 16:25:56 UTC
I have this problem too, on version 21.12.2.
It's not fixed, same as in https://bugs.kde.org/show_bug.cgi?id=450620
When delete partition

STEPS TO REPRODUCE
1. Delete the partitions of a USB-drive
2. Create a new ext4 partition
3. Mount
4. Try to write on it

OBSERVED RESULT
The USB stick is read only, even after a few remounts.

When formatting in FAT32, its not read-only by default.

EXPECTED RESULT
Every partition format should be writable.

SOFTWARE/OS VERSIONS
Operating System: Manjaro KDE
KDE Plasma Version: 5.24.2
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.2
Kernel Version: 5.10.102-1-MANJARO (64-bit)
Graphics Platform: X11
Comment 35 Andrius Štikonas 2022-03-11 16:37:21 UTC
Please don't randomly reopen fixed bugs.

It clearly states that bug is fixed in version 22.04.0 and you are saying that you still have it on 21.12.2. So either compile the latest version from git repository yourself or patiently wait till your distro packages 22.04.0.
Comment 36 Mr.Nobody 2022-03-11 18:55:37 UTC
(In reply to Andrius Štikonas from comment #35)
> Please don't randomly reopen fixed bugs.
> 
> It clearly states that bug is fixed in version 22.04.0 and you are saying
> that you still have it on 21.12.2. So either compile the latest version from
> git repository yourself or patiently wait till your distro packages 22.04.0.

Please accept my apologies, I overlooked the fact that this was fixed in version 22.04.0. I saw ver. 21.04.0
My mistake