User and group default ID

Support
1

Hi to all.

I have a question/problem.

I installed (successfully) OMV Lx 3.02 (b1082) in my box. I’ve decided to share my home partition with my working OMV Lx 2014.2. My idea, after testing 3.02 (and after it’s decided that a build of 3.02 is the final release), is finally install 3.02 over 2014.2.

But there is a BIG REALLY BIG problem. The user ID for the very first user is now “1000”. In Lx 2014.2 it was 500. And it was 500 since LONG time ago. The same occurs with the group ID number for the first group. Now it’s 1000, before it was 500. The real-life consequence of this is that I CAN’T ACCESS ANY OF MY OLD 2014.2 FILES AND DOCS from Lx 3.02. All my work files and visible but inaccessible.

WHY (you can add some words here) SUCH CHANGE WAS DONE ???

WHICH IS THE REAL (I mean, REAL) ADVANTAGE of changing the default user number ???

Does anybody thought that all user will loose the access to their old files changing that ??? I cannot even share the group with my old user !!!

Now, if I really need to access an old file, I go to Midnight Commander, change the permissions, and access the file. BUT THIS IS A REAL NUISANCE, AND A RISKY OPERATION !

Even if changing all the permissions of the old files and for all users (sharing the first group, for example) could be automatized and/or possible with minimal computer knowledge, the question remains: WHY ?!?!?!?!

Real-life consequence: I’m still using Lx 2014.2, because my PC only has Linux, and I use the PC to work (I’m NOT a computer professional, I’m civil engineer).

2

Ii guess it’s a technical matter, quite all distributions do this. You may update uid and gid with the following command (make a backup first!):

usermod -g new_uid USER
groupmod -g new_gid GROUP
find $HOME -uid old_uid -gid old_gid -exec chown new_uid:new_gid '{}' \;
find $HOME -uid old_uid -exec chown new_uid '{}' \;
find $HOME -gid old_gid -exec chown :new_gid '{}' \;
3

Ok. You wrote 5 CLI to make the “conversion”.

It’s a solution. And maybe is the FAR WORST user-friendly decision has been made. 5 commands to write as root in console… Recipe for a disaster. Can you see my point?

4

Sure, but I’m more confident with cli than gui tool. Maybe there is a gui tool to make all this.

1 Like
5

I’m talking about “user-friendness” !!

CLI will do the work. Faster and, maybe, better. It can be cool, simple and elegant. BUT IT’S NOT NOT NOT NOT UNDER ANY POINT OF VIEW USER FRIENDLY.

It’s not a matter of how trusty is for you or me to use CLI. It’s a matter of how common users see all this.

Do we want Linux being more used in our desktops???

If yes, then STOP MAKING THIS KIND OF “DECISIONS” !!!

A possible solution, not free of risk, should be that the conversion be automatic if anyone update from Lx 2014.2 to Lx 3 (or any “old-linux” to a “new-linux”).

Is this type of tool (automatic conversion for OpenMandriva Lx) available during update of OMV Lx?

I’m really asking, as I don’t know if such tool exist.

6

@Sirius I have the feeling you may be a bit angry or tired or disappointed. I really can understand you.
However I suppose this kind of changes are made “upstream”.

Think who have had the brilliant idea to give the 1st user the admin privileges, to add it to wheel group, and so on…
Not to mention the genius who prevented to open dolphin and editors as root [1] “”“for our best”"", for the good of us stupid users :rage:

[1] Well, yes there is a workaround for the editors but guess what? you need to run command in console LOL
:wink:

1 Like
7

Well. I’m disappointed. VERY. And that disappointment leads to a little angry.

I’m using Linux since maybe 2005. Since Mandrake 8.2 Bluebird. Since 2011 or 2012 I use it almost exclusively (my notebook is Windows native, but in my desktop I don’t even install Windows).

I “suffer” this kind of… foolishness? (and the first fool was me !) first some years ago, when “we” (at Mandrake/Mandriva/OMA) migrate towards systemd. Before that, the general recommendation about directories and partitions was “to have /usr in a separate partition”. I had it that way. I think (but I’m not sure) I had MDV 2011 in those moments. It wasn’t using systemd (it was something like “MDV 2010 upgraded to MDV 2011” without formatting, just updating). I read more and more in the web about “systemd being the future” and so. Then I finally decided to “upgrade” my 2011 to use systemd.

It was maybe one of the worst decisions I made in Linux. My system totally wracked up. All those idiotic nerds speaking about “the future” and no body can explain in simple words “you shouldn’t have /usr in a separate partition”. The result was a total reinstallation of something that was working well before systemd. It took me some research to finally find that the culprit was “/usr in a different partition than root”. I don’t lost files. But I lost TIME.

I see a total disconnection between developers (not only OMV but in general under Linux). Under our loved distro, we still have some “reminiscences” of this behaviour. For example, which are the REAL advantages of using CLang instead of gcc, or using Wayland instead of X, or using SSDM instead of KDM? (I may be not technically right in comparing that things, but please, catch the idea behind this). I’m not saying that those changes are good or bad, or even needed or not. I’m saying that we are low on manpower, and then “we” (not me but developers) last A LOT OF TIME trying to make CLang things work, rewriting a LOT of packages, all that for gaining… For gain what? I’m not having a very faster distro after “upgrading” to CLang. I’m not saying “keep all the things in gcc”. I’m saying “tell us why we must wait another 6 months migrating toward CLang”.

We, the normal users, in this distro (a community driven, supposedly, distro), should be at least informed about why some changes are made. Or, at least, warn us that some changes came from upstream. But please, warn us. Access to my work files is VERY FAR MUCH MORE IMPORTANT for me than having a top-notch distro running in my box !!

After all that. Can someone explain, in simple-and-for-normal-users words, which is the REAL advantage of being the user 1000 instead of user 500? Remember. I’m not blaming the developers for this. Or not totally (even less if changes came upstream). But, can I know why ?

Ok. It’s like you said @rugyada, “it was done for us, the stupid users”. I’ve lost the access to my files (I don’t yet, because I still use 2014.2, for OBVIOUS REASONS). I can restore my access using 5 risky commands I should write as root in console. I’m technically capable of doing that. I’m ready to take the risk (it doesn’t look THAT risky for me, but it can be very intimidating for other users). So, please, tell me, the stupid user, WHY SHOULD I TAKE THAT RISK ?

1 Like
8

I understand you frustration about user ID incompatibility. Encountered it years ago. This is one of many areas where Linux users wish there were better standardization between and within the many Linux distributions. Me included. Yet it never happens.

The rest of this post is meant as general information for anyone interested.

As a work around you can use a throw away user for the install. But you need to know what you doing with users, permissions, ownership, and more. In short you are deciding to be a System Administrator which for most of us requires learning how to be a System Administrator.

OM Lx 3 and Om Lx 2014 are not compatible with one another. This has been stated since development began with Lx 3. That is one reason why Release Notes tell us:

Upgrading from OpenMandriva Lx 2014.x and older

Currently for OpenMandriva Lx 2014.x and older a fresh install is recommended

The best advice for sharing /home between the 2 is don’t do it. If the user ID conflict were the only conflict you’d encounter you would be lucky.

The fact that there are users that do this doesn’t make it a good idea. IMO it is obviously not a good idea. I have never seen sharing /home in the documentation of any Linux distro. This isn’t an accident or oversight. If one still persists and wants to use shared /home the first step is to learn basics of system administration. This is a ‘must do’ requirement. Anyone uncomfortable working from command line shouldn’t be doing this.

Another approach

Another way to share user settings between different Linux systems is to store the settings file/files in a separate partition (call it Data or whatever you wish) and symbolically link them. For instance I keep Default profiles of Thunderbird and Firefox in /Data1 and link them so that no matter which system I’m in on a multi-boot computer my Thunderbird and Firefox are nearly identical. This is described here. It includes a brief synopsis of why not to share /home. Note the date of the article, it is old. From experience I can also state that early on I learned that one requirement of this approach is that user ID’s need to be identical for this to work.

Do note: This quickly gets to be like work. Don’t start down this Another approach unless you are willing to learn, problem solve, and continue to maintain your operating systems. It is not a “set it and forget it” solution. Again if one is uncomfortable with the command line this is not for you.

2nd note: There is more than enough free training and education available on the internet to learn the basics of system administration. This did not make me an expert, I’m not. I have used courses from the Linux Foundation myself. Still refer to the material to this day.

2 Likes
9

This is an answer as I understand it, developers probably know more, or can correct me if what I write is incorrect.

Short answer is to leave more ID’s available for the system itself as Unix/Linux and personal computer operating systems get more complex. Secondary reason was to become more compatible across all of Linux. (Originally Red Hat centric distros used 500 Debian centric used 1000).

The compatibility issue is difficult as some distros use or used 500 or 1000 for 1st user and some use or used 501 or 1001.

Edit: If Y’all remember one feature on Mandrake/Mandriva installers through OpenMandriva 2014 was for the Installer user to set manually both user ID and group ID for 1st user. I wish Calamares had this feature.

2 Likes
10

First I should correct a typo in the commands :flushed: :

usermod -u new_uid USER
groupmod -g new_gid GROUP
find $HOME -uid old_uid -gid old_gid -exec chown new_uid:new_gid '{}' \;
find $HOME -uid old_uid -exec chown new_uid '{}' \;
find $HOME -gid old_gid -exec chown :new_gid '{}' \;

I apologize for this.

I only try to give to you a working solution for your problem. I may agree an automatic tool or a gui could be more user friendly but it is out of my knowledge. Usually this kind of problems were resolved by setting uid and gui manually at installation time. I don’t remember now, not according to @ben79, if Calamares allow to do this but in general it is too much user friendly to make smart customizations. I really hope it will in the future.

ASAIK Mandrake/Mandriva/OpenMandriva has never had such tools and for what I can remember update to a newer release has never been officially supported, even in some case it worked. I agree it’s a big (historical) miss and I hope it will be supported in the futures.

IMO systemd is just RedHat. RedHat/Fedora like distributions adopted it as a consequence. But also independent distributions like Debian adopted it after some not so friendly discussion. Most things has advantages and disadvantages and also systemd had, however personally I am not a fan of it.

If I understand well the fact it is not strictly related to systemd or some other technical decision made by developers. A normal user doesn’t care so much about systemd or any other init system also because usually a normal user even doesn’t know what a init system is. The fact is OpenMandriva has not an official supported procedure/tool to update the system in case the normal user, for any reason, had to reinstall the whole system. And it is not a so friendly operation even using cli. IMO it’s a bug, a BIG historical boring bug. My hope next major release could have a simple tool for this but we should request for it to developers and help them with tests.

I developers, which IMHO are all really smart guys, decided for that I guess there are some technical some reasons. Normal users doesn’t care so much about this matter.

Simply because SDDM of the official display manager for PLASMA5.

IMO lx3 is really more responsive with respect to 2014. I can’t say what changes in particular make it so, I guess it’s the combinations of the choices.

You’re right communication is not best point in OpenMandriva. However mailing lists meetings log are all public accessible so reason for most of choices can be searched there. It’s not user friendly, I know, but but, as you may know, it requires lots manpowers. I only stress not all distributions are too open and transparent to publish IRC meetings logs and keep them open to everyone would like to contribute.

I agree. It is the primary goal of a SO.

Noone because normal user doesn’t care about its uid and gid. It’s a technical matter @ben79 explained to you so well.

risky because I made a typo :flushed:.

1 Like