I used Dnfdragora to install Rootactions for Dolphin. Before creating folders in /mnt/ for my secondary partitions and drives I rightclicked in /mnt/ and used Rootactions to give ownership to the active user. I then proceeded to create my folders for mounting my secondary partitions and partitions to. I then proceeded to mount the various partitions and drives to their corresponding folders in /mnt/. I tested by copying files to the desktop from my Docs partition to make sure I had proper permissions. There was no issue copying to the desktop. Shortly thereafter I rebooted and went into Arch. I had new files that I needed to file away and was promptly told I didn’t have permission, so I rightclicked in /mnt/ in Arch and create was greyed out. I took ownership again in Arch using Rootactions and all was good. After moving the files I needed to I rebooted and booted into Garuda when I ran into the same issue. I fixed the issue and rebooted into OM Rome and sure enough I no long had my permissions under /mnt/. I fixed it, booted back into Garuda and as I suspected I had to fix the permissions again.
I know the issue is something with OM Rome cause with just Garuda, Arch, Manjaro this never happens. My permissions set using Rootactions stay as I have them. Garuda had this particular a good while back and has since corrected it.
There may well be an issue with ROME. I do not understand this myself perhaps our developers will. I have not used rootactions in Dolphin for years.
I use multi-booting as well as data partitions. Anything I want mounted at boot I add an entry in /etc/fstab and that is done.
In Dolphin you can open any partition by selecting it and entering root password. You will then be able to open any partition in the list. Granted this permission does not last forever, but it works well for me.
Of course in Konsole (terminal) it super easy to open anything, but you would have to mount things not already mounted.
I can and do copy or move things from one operating system/data partition to another frequently with no problem.
It is definitely possible I am missing something though…
Edit: You might get a quicker answer asking a developer at OpenMandriva Chat.
I know not part of the issue but here’s how I do my mounts:
Add Rootactions to Dolphin cause once I give ownership to active user I never have to reenter my password to get full access to data drives / partitions.
Open Dolphin to /mnt/ and take ownership.
Create my folders for mounting.
Use Gnome Disk Utilities to mount my data partitions / drivers to their folder in /mnt/ and set it for automount.
Recheck ownership once mounts are moved.
Now as for what might be the issue Garuda tried to do the main user as 1001 instead of 1000, but I’m sure there are other things that can cause the same issue. I say the later cause I vaguely remember seeing in Rome the main user is 1000.
May be worth mentioning but it is possible that no one in OM contributor group has thought about rootactions in Dolphin. I do not recall hearing it mentioned anyway. Bug report good.
For mounting data partitions adding them in /etc/fstab would accomplish not having to enter password. I actually add my data partitions using Manual Partitioning when I am installing OMLx in Calamares installer. That automatically correctly adds them to /etc/fstab. The rest of what you are talking about should probably be answered by a developer or someone more knowledgeable. This may happen quicker at OpenMandriva Chat. And I am aware that just because I do things a certain way does not mean that works for other folks.
I am seeing the main user in OM ROME created as 1001. Easy to check in KUser.
I bet correcting that from 1001 to 1000 would solve the issue. It should never be 1001. Garuda learned that the hard way. As for how one mounts their data partitions yes to each their own. I do my way cause I have a tendency to do typos and not willing to take the chance of screwing up the mounts by hand typing the fstab information.
I just checked on the Garuda forums for my thead there from when they had the issue and it sounds like I can just do a fresh install of Rome and once on the desktop change from 1001 to 1000 for my user. Sounds like from what they are saying yes this is exactly what is causing the issue. I’ll search for a tutorial and link it here.
I found the below til your fix is pushed in a new ISO cause the current ISO will still install with 1001. Please let me know if this will for me without issue. Thanks
The use of rootactions is meant within the system not for transferring/modifying between two systems.
This is always very dangerous.
I use rootactions in OMA and ROSA, but if I have to transfer files from one system to another I copy them from source to destination and nothing breaks.
OMA uses userid 1001, ROSA 500. It’s not a bug it’s a system construction choice.
Changing the userid now would break backward compatibility between OMA installations.
No one said ANYTHING about transferring files between two systems. Rootactions when used should give the rights to those files and folders to the particular user in that OS and not affect other installed OS’s. As for 1001 vs 1000 1001 should not have been a choice that was made by the devs. I am willing to bet using 1001 instead of 1000 is the issue, after all it was the issue in Garuda til they went to 1000 on their next release and the issue no longer existed. Using 1001 affects more than just Rootactions permissions, it also at least affects Emby’s permissions. Check Emby’s forum and you will see plently of post in regards to Garuda and proper permissions for Emby.
@rugyada you’d be right it’s not a Rootactions issue it is a OM Rome issue.
This needs some kind of documentation. Is there some published rule somewhere that says all LInux distros must use xxxx of xxx as first user created ID? I am not saying this does not exist, rather that I am not aware of it. I am genuinely curious. Other than Linux man pages I am not sure where to look. Edit: As someone on the Technical Committee and the governing council of OMA I am genuinely curious about this.
Edit:
Backward compatibility is a valid issue. I would think otherwise it is a system construction choice myself. If not I am willing to learn.
The default should of been left along. As is pretty obvious not using the default causes issues. I honesty wouldn’t be surprised that the Deluge not launching issue which has been confirmed by someone else in the the issue ticket I created for Deluge on the github pages for OM is due to this. As for backwards compatibility I don’t believe it’s an issue. I say this cause after Garuda changed it from 1001 to 1000 I have yet to see anyone having issues with there installed system with the change, even those that backup their home folder before reinstalling.
You may be right. I wonder if one can drop down to a tty before landing on the desktop for the first time after install and edit the user, in my case locutus. Supposedly one can create a second user that does have 1000 instead of 1001, but with that I worry that not all the permissions the main user has will be given to the secondary user. If they are then one should be able to login as the secondary user and remove the initial user I would think.
You can probably do this anytime. After installs on hardware I always add dummy user for testing purposes with this example:
$ sudo useradd -c "Happy User" -u 1000 hapu
$ sudo usermod -a -G network,storage,sambashare,lpadmin,users,video,audio,wheel,lp hapu
That is all the groups first user is added to. I think that makes the new user equal to first user but am not sure. The root passwd would still be what you set it but that is easy to change if desired. I believe wheel group would give you equal permissions.
Yea maybe if they would answer in the forums instead of chat only. Chat only doesn’t preserve any solution for others that might want / need it. Tech support for a OS or any application has always been a bad idea.
