File Manager - Superuser mode

Sometimes some things are being missed here…

Some distros have context menu options, e.g. ‘Edit as Root’, etc. in Dolphin. Thus, for a distro like openSUSE 11.2 that does not have that, there is the Dolphin Super User, which one should be able to select files to edit, etc. from there - however, when that is attempted, it fails, and gives an error dialog, e.g.

"KDEInit can not launch <</usr/bin/kwrite>>".
“KDEInit can not launch <</usr/bin/kate>>”.

which makes the lacking feature in the regular user of Dolphin moot, when you can’t even get the Dolphin Super User to work without this error.

However, the “edit as root” and “copy as root” are selections in Krusader,
User Actions → File ->…


I too installed this via the Dolphin add on installer, along with my long used and favourite action ‘audiokonverter’. Neither appear in the actions drop down when selected with an appropriate file. In the Dolphin addon box there are two instances of both programmes indicating that they are installed but they do not appear in the services configuration section. So it seems that while they are installed they are not available. I have set up a suKate menu option to allow me to easily edit root text files, but I really think that the option to edit through the suDolphin needs to be fixed as it is a real PIA.

Type this in a terminal

xhost +local:0

If that fixes your problem, put it in a shell file and autostart it.

Problem opening files from Konqueror - Super User Mode - openSUSE Forums

Somehow you did not perform a default openSUSE 11.2 KDE Install to not get dolphin in both modes off the System>File Manager.

Use the Menu editor to create another Dolphin Icon and you can create one - It is important to have a root and non-root File Manager so make a copy of the non-Root Icon for Dolphin.

Then use the Menu Editor and edit the new Icon item you just created and tick the box "run inroot’ Mode. Now save it.
When you click on this mew item you will be promoted with a ‘runasroot’ password box - Add this and you will have your File Manager in Super User Mode

The Menu editor is a right click on the quickstart of KDE:)

This does fix the issue. I understand what it does. It imports roots environment so that root can perform the actions. Are there any negative ramifications to this? If not, why doesn’t openSUSE do this? What good is File Manager Superuser Mode without it. Back when I started with SuSE 9.1, this was not an issue. I am not sure when or why it changed, but I had not been able to use this feature for several years now.

This is an outstanding bug - we all face. We currently do not have a text editor than can open a file, once found via Dolphin as Dolphin does not retain any meta data one files.
The only work around is to use the same process as Using the Menu editor to create another Kwrite Icon - In Super User Mode - It is important to have root and non-root Editors for normal file maintenance.

Use the Menu Editor and edit the Icon of either Kate or Kwrite, and tick the box "run in root’ Mode. Now save it as a new Total File Name.
When you click on this mew item you will be promoted with a ‘run- as- root’ password box - Add this will give you a text editor, Super User Mode that ca open a file.

The Menu editor is a right click on the quickstart of KDE:)

Not the the meeta data link between file types and Dolphin in Super User Mode has no meta data linkage so you will not be able to open a file that Dolphin in Super User Mode has located.

Best workaround is to locate the Path of your New Dolphin- Super User
Icon, then copy the path!!! close Dolphin, open Kwrite or Kate in Super User Mode you have just created, and paste the location directory into the editor.

You should NOT copy the path that includes the file name you wish to open, only the directory path. Once you set the directory path in Kate/Kwrite you only need to open the file that will be on your screen via File>Open.

Will it get fixed before 11.3 - Dream on guys. - (I am starting hysterical, laughter at this point about bugs ever getting bugs like this fixed so I will sign off.

Please check that your KDE Installation has “Miscellaneous Tools - Group” I think that is what the group is called…under all the File-Server…etc list. The selection miscellaneous tools may account of the lack of admin tool that are installed by default. You need to tick this Grouping.

I didn’t like Dolphin when it first came out, but persevered in using it. I knew my first instinct was right.

zczc2311 wrote:

> As we all have the same or similar issues, why can’t this be fixed
> and published by online update - While the developers are there
> they might like to fix dolphin so you can click on any .rpm file
> which should then should invoke the Package Management
> Installation.
> Konqueror seems the only reliable way to install a .RPM file via
> the Package Management System.
> I am sure this bug sits somewhere in the 2,000 odd bugs
> reports.>:(
> If you think my expectations are not realistic please tell me:O
Note this bug has existed since 2004. I have tried all suggested
fixes in this thread and they don’t work on Dolphin in my KDE4.3.5
system. Maybe I’m doing something wrong.

The bug is on the KDE Bug Tracking System:

Mean while I use either Kate or Kwrite as super user when I need to
edit something.

| openSUSE 11.2 ( x86_64 | KDE 4.3.5 release 3
| Intel Core 2 Dual E7200 | 4 GB RAM | GeForce 8400 GS | 320GB Disc
(2) |

All my posts and default installations were completely defined to the openSUSE Products of 11.1-11.2. Although I mentioned 11.2 and 11.2 I am afraid that some may be thinking of native KDE - This is not my attention.
All work-around and fixes and comments refer to to products OPENsuse 11.1 AND 11.2 in a KDE Desktop Installation. Sorry If I have confused anyone here by noting making my reference’s to 11.1-11.2 clearly opensuse versions

For what it is worth: If you start the menu editor go into configure and set Show hidden, then you will see that there is a konqueror super user in the menu tick it to be not hidden and use this, You can start editor to edit files as root no problem from there.

You can also try another using File Manager, I have found pcmanfm to be a good FM.

Yes I can see the option, and it just expands, in my case, another 36 items - most of which are just directories of ‘System Settings’ that are Installed, but presented as a since menu item. There are no additional programs reviled by doing this and it is much a waste of time - unless the users before, could not find the menu item when it was there all the time???

I suppose the question for all user who cannot access a default KDE 11.2 who are not given a File Manager in Root Mode. ALL 16 of my PC’s all DO offer one. It may be that users have used a Non-Automated Installation, where you can easily add groups like ‘System Tools’ to Install.

Having Never Performed an automated Install of KDE 11.2, It may be that the default application Program selections is way off the point as ALL user MUST have a SU File Manager just to manage day to day events that occur, especially if we get a 2 and above Network

NO matter, we have got a workaround from yourself and others and this is the best we can hope for. No World Government has enough money to throw at the project to get its current bugs fixed from 2,000 to 100 last time I looked …let alone fix the massive Kernel) problems us X64 users deal with on a day to day basis with which we endure every time we turn on our PC’s on

For some time xhost by default limits access to X. Even though a superuser, root is no exception and requires permission to access X applications such as kwrite on your local machine under certain conditions:

  • you try to spawn another X process such as kwrite via an app “run as root” (other than via kdesu or gnomesu or similar, see below) or
  • you try to spawn an X app via an app (dolphin) started from a terminal with root privileges.

“Xhost +local:0” provides access to X for all users including root on the local machine but not to remote hosts. “Xhost +” allows remote host access to X via TCP/IP - not a good idea as keystrokes can be grabbed etc.

To utilize this security measure correctly there are several options, among them:

“xhost +local:0” (usually) or xhost +local:yourdisplaynumber (this can be in /home/user/.bashrc for example), or
“kdesu appthatspawnsX”, or
“gnomesu appthatspawnsX”

See for example the xhost man pages. Xauth is also relevant for secure remote access.

An OS that provides for any number of local or remote users to access “your” X must provide for secure access to “your” X. IMO this is not a bug, just a security provision to be aware of.

To check your xhost settings run xhost in a terminal. For root or any other local user to be able to spawn an X process from your login account you should see something like:
access control enabled, only authorized clients can connect