I reinstalled EOS KDE on to it’s own drive so I could make it’s file system BTRFS instead of Ext4. Once on the desktop I checked for updates and there wasn’t any. I then proceeded to try to add services to Dolphin as I had in the previous EOS install and they failed to install. Two fresh installs on two different drives and right out of the gate I can’t add services to Dolphin. On top of this in the second install I could not use the back or forward arrows on Dolphin’s toolbar to navigate, they just simple did nothing. I cannot say if the buttons had a issue in the first install simply because I hadn’t done anything in Dolphin in that install except to try to install services. I especially need to be able to add Root Actions it’s so much easier than using chown, especially when some of the folder I need to take ownership of have a space in their names. Any help and or suggestions would be greatly appreciated. Thanks
What do you mean? What is the output of
yay -S kde-servicemenus-rootactions
OK that did the trick from the looks of it. I’ll test on one of my partitions that I know will be locked to me till I take ownership and report back if there is still a issue. Now the other part of this still remains, and that is going into Configure Dolphin, services, and trying to install services from there. Since I just booted back in to EOS I’ll Try one more time and report back. @dalto thanks for the quick fix.
OK root actions work like a charm nowe, thanks
Still cannot install Dolphin services from within Dolphin. I get “Failed to execute install script” every time.
Do not install Dolphin services from within Dolphin. Find the service you want in Dolphin, but do not install it there, look it up on aur.archlinux.org and install it from the AUR. Almost all of them worth anything are in the AUR.
It’s much more reliable that way.
If you want to open a folder as root do you use root actions ownership to root?
For my purpose I use Ownership To Active User. Wonder though if I use Ownership To Root if that woiuld get rid od an issue that’s bothered me since Manjaro 18.1.4. And that is when taking ownership in one OS of a drive or partition I lose it in the other, and have to take it back again. There must be a way to maintain ownership by the active user in both OSes. If you have any idea on how to do this I’d really be grateful. Thanks
This is why i like Cinnamon because it has open as root.
I like Cinnamon too, but too many things in Dolphin I can’t do without.
I have seen this when the ‘originating user’ has a different uid. Something I have to watch for as I use a data drive across many multiples of distros! I would check /etc/passwd on each distro, and see if the uid’s match up - and if not I would log in to one of them as root and change the uid to match the other distro’s.
Assuming no conflict with another user (if so - change them first to something unused)
usermod -u 1000 username groupmod -g 1000 username
(example only - and I assume you don’t operate as ‘username’!)
Hope this helps…
OK I believe it’s 1001 on Garuda. I can’t swear to that right now. I’m in Garuda now, do you have a command I can use to check it here then I can boot EOS to check it there as well. Thanks
Garuda does that, for sure… Here’s the command sequence for that one…
fresh boot - log in as root - then the following (in order). usermod -u 1002 guest groupmod -g 1002 guest usermod -u 1000 username groupmod -g 1000 username and, optionally usermod -u 1001 guest groupmod -g 1001 guest
The guest account get wiped and recreated every boot - but if you as ‘main user’ are already safely at uid 1000, it will have no adverse effect.
I’ve already gotten rid of the guest account in Garuda. There must be a terminal command I can use or a file I can check since I have both OSes set to auto-login.
I’m sorry I completely missed that. Tooooooooooo manly pans in the fire right now.
Now you are just bragging…
All you need is the ‘reset’ for your username then - just make sure you log in first as root (on a fresh boot) so it doesn’t start any services in your username before you change your uid!
For that matter - if you want to install the guest user package over there, it wouldn’t cause any trouble after that uid change. Guest is useful if other people are over occasionally - much better than setting them loose as you!
OK I have the below from each OS. I’m also going to ask someone from Garuda to look at this thread so there aren’t accidental surprises.
Garuda alienprober:x:1001:1002:AlienProber:/home/alienprober:/bin/zsh EOS alienprober:x:1000:1001:AlienProber:/home/alienprober:/bin/bash
Slightly odd - here’s what I have on both:
I would do the usermod AND the groupmod on Garuda to set to 1000:1000 - and just the groupmod on EnOS to 1000:1000 as well. Don’t know how it got that way, but could lead to all kinds of odd behaviours with settings if left that way…
so in a nutshell in both OSes uncheck automatic login, login as root, and from Konsole do the below(even if I don’t have a guest account in either OS?):
usermod -u 1001 guest
groupmod -g 1001 guest
usermod -u 1000 username
groupmod -g 1000 username