For user that believes they would be better served with UID/GID of 1000 this is a proposed work around. I have tested this on hardware PC’s and in VBox and in seems to work OK. I see no effect on how I use shared folder in VBox for instance.
Hypothetical user name user. Where you see user in commands change that to your actual user name.
After installation boot to console mode. Login as root. (This also works on an existing system in test situation.)
# usermod -u 1000 user
# groupmod -g 1008 lusers
# groupmod -g 1000 user
# exit
$ sudo chown -R user:user $HOME
Reboot.
To check our work
Check ownership of folders in /home/user:
$ ls -l /home/user
Check UID of user:
$ id -u user
Check GID of:
$ id -g user
What we have done:
Changed UID and GID of user user to 1000. Changed GID of luser 1008.
Set user and group ownership of everything in /home/user to user.
No password or permissions were changed.
Works just fine in test situations. Tested on hardware PC’s and in VBox VM’s. Nothing changed as far as how shared folder works in VBox that I have seen so far.
Hi, I tried following the guide using uid and gig 500 as in Rosa. After the change Dolphin no longer opens the partitions of other systems it asks for the password but does not access the partition. Otherwise all uids and gids have been changed.
Test performed with installation on a real computer
Distributions generally split the available UID range in two:
1…999 → System users. These are users that do not map to actual “human” users, but are used as security identities for system daemons, to implement privilege separation and run system daemons with minimal privileges.
1000…65533 and 65536…4294967294 → Everything else, i.e. regular (human) users.
Note that most distributions allow changing the boundary between system and regular users, even during runtime as user configuration. Moreover, some older systems placed the boundary at 499/500, or even 99/100. In systemd, the boundary is configurable only during compilation time, as this should be a decision for distribution builders, not for users. Moreover, we strongly discourage downstreams to change the boundary from the upstream default of 999/1000.
So far I have tested this only in VBox.
However on my hardware systems as part of my post install config I create a user with UID 1000. I add all the groups to that user that first user (1001) gets. If I login to that user and open Dolphin to access the partition of another OS I have to enter the password of that user (1000) not the root password.
I will do a hardware test of the change to 1000 soon.
Thanks for the suggestion, unfortunately the problem remains even with uid greater than 1000 (1017).
Shares are created in /media/ but are not accessible to the modified user.
I am in my hardware test of this. So far everything seems working OK.
I did not have any problem opening other operating system partitions in Dolphin after entering root password. This is expected behavior.
A few points: It does seem best to do this by booting to console mode so no pids are claimed by user. I do find that one has to do the usermod and groupmod commands and then reboot before doing the chown command. It seems OK to do the chown command in graphical desktop.
I do not have any reason to use a specific UID or GID. But I have been doing this in my ROME and Cooker systems on my desktop. It is easy to change these and I have not seen any ill effects.
