Yeah, I know. I installed it when googling this problem. I was just interested if the inability to open file manager as root is a bug.
no these are some security measures as coming with latest updates, prior to that I was able to run Thunar as root, but now this is blocked too. Still you can start many programs such as KDevelop, Thunar I think, … and many others that see if you need root privileges to handle those files and would than prompt for root password. These feature could also come to Dolphin in future, I hope.
I have added polkit rules to open other partitions without a password. Would that allow files to saved without asking for a password? But, I can’t open the rules.d folder anyway, just by clicking on it in Dolphin.
Install kde-servicemenus-rootactions. That will add menus to dolphin to modify permissions as root.
Perhaps it is a side effect of your changes to the rules.
Then, Dolphin is not that secure. I have the same polkit rules in other Arch installs, but I can’t save any file without a password in Thunar, Nautilus or Nemo, though I can open them as root. It is even strange that I can’t open with sudo kate in konsole, but kate would save without password.
But, if I do su in konsole, and then write kate it opens, and I can open any root’s files. It is puzzling.
I have it installed. So I clicked on ‘onwership to’ there was ‘owner:read’, ‘owner:write’ and ‘owner:execute’ options already highlighted, so I just clicked ‘yes’. Still no luck with opening the terminal.
Am I missing something, what does your ability to save files using kate have to do with dolphin?
Of course you can. At that point, kate is running as root.
I am not sure what you are referring to here? If this is about resetting permissions, I was referring to doing this on every file in your home directory including all the hidden ones. Like this:
sudo chown -R username:username /home/username
Replace all the usernames with your actual username.
1 Like
I did that. Still can’t open terminal from dolphin.
maybe remove those “dot” config-files in your home directory then restart, or create a new user, that the config files come with default settings
Try creating a new user and logging in with it and see if it works there. If it does, you know it something in config.
Is it safe to remove all these dot folders? Aren’t they contain browser extensions for example?
Erasing all your dot files and directories is not a good idea if you want to keep any of your config.
That is why I recommend creating a new user. It will test the same thing.
I created a new user, restarted and opening terminal works in the new user. But funny thing, it now works with my old user. Should have started with a restart first.
not entirely, emails and browser data are stored in those dot folders also, but things like .config and .local and .basrc and so on, are safe to delete, but now you already have the solution, I’m glad it worked out fine.
This is why aliases exist. Add this to your .bashrc.
export SUDO_EDITOR=kate
alias se='sudoedit'
FWIW Krusader has a Root mode, although I can’t recall last time I used it.
I’m sure some valid use cases exist, but it is not a good idea.
3 Likes
There are good reasons why people are saying “do not to run GUI programs with sudo.”
Not only does that give elevated privileges to millions of lines of code which was not designed to be run with elevated privileges (most of which were not written by the authors of the program you’re running, but by the various authors of various libraries and dependencies), you are also polluting your user space with files owned by the root (which is what likely happened here), which can cause all sort of difficult to spot breakages since processes that were run without elevated privileges will not be able to write to these files.
If you find yourself having to edit files outside your home directory so often that you need the convenience of a GUI file manager, you’re using your system in a wrong way. Keep your user stuff in your user space.
3 Likes
I get the theory on this - but it seems the system still insists on putting things in /etc and /boot and /usr/share/applications where root access is required. Often one can fire up a root-enabled text editor from the terminal - but sometimes the multi-tab GUI is a big help with moving settings files from one system to another, or doing a quick edit in a root dir.
I work in XFCE, so a Thunar config to enable a ‘root Thunar’ is very easy - and my text editor started from there is root by default - but as I understand it, if Kate is used to load a root-owned file, when saving it asks for sudo privileges if needed - thus not requiring a root version of Dolphin to get the job done in those cases…
It is Linux - and using it wrong is part of your rights! 
So is fixing the consequences!
2 Likes
The problem is that increasingly GUI applications are not written to be safe to be run under root. They often aren’t developed that way anymore.
I don’t know if it is safe to run Thunar or whatever text editor you are using as root but for many applications it simply isn’t safe.
So is advising people they are putting their systems at risk for no apparent reason. 
2 Likes
It is not often that you have to edit a config file in /etc, but when you do, you can use one of a million terminal-based text editors (or if you need the GUI, use a text editor with polkit support, like Kate – without sudo, of course).
The other two directories you mention, /boot and /usr/share/applications, you should probably leave these alone (not once have I encountered the need to edit anything in there, in about a decade of using Linux).
Regarding the latter (for example, if you want to change the icon of some application), just copy the file you want to edit to ~/.local/share/applications and edit it there. A file there will take precedence over the one in /usr/share/applications, but only for the intended user (and if you mess something up, you have the original as a backup, so you only need to delete the copy in the user space).
2 Likes