Dolphin not working

[geezer]

Never change permissions/ownerships on system directories unless you are really really really sure you know what you are doing (and even then it's usually a bad idea).
You can do it with sudo or with file manager as root (or with the root actions menu), but you can seriously hose a system that way, especially if you do it recursively (applying changes to all sub-folders and files, which I assume you did because of the sudo error that suggests the ownerships/permissions of /usr/bin/sudo have been changed).

The correct way to copy a file to a system directory (like /usr/bin) is to copy it with (kde)sudo (or with the menu)...or to start the file manager as root with kdesudo (or with the menu) and drag-and-drop the file as you are running the file manager with elevated privileges...not changing ownership/permissions of /usr/bin so you can copy files as your normal user.

Depending on what exactly you changed, the easiest/only real fix might be to reinstall...because while the majority of files in usr/bin have ownership "root root" and permissions 0755 "rwxr-xr-x", there are some files that have different ownerships/permissions for different reasons (including /usr/bin/sudo which has permissions 4755 "rwsr-xr-x"), and if you change the ownerships/permissions en masse there is no easy way to get back these different ownerships/permissions.

While you might be able to boot into recovery mode (to get a root shell) and change ownerships/permissions for /usr/bin and the files to "root root" and "0755" (and /usr/bin/sudo to "4755"), there would be other files with incorrect ownerships/permissions which will likely cause problems later on.

If you tell me exactly what you changed in /usr/bin with the menu...and if you wish to try the recovery mode route, I can give some guidance on the commands to change ownerships/permissions in the recovery shell, but this is likely going to be an incomplete fix (you could get sudo back, but other programs in /usr/bin might experience problems).

So my recommendation is reinstalling, unfortunately (but see EDIT below).

EDIT: If the only thing you did was to add write access to "others" in /usr/bin recursively, you should be able to undo the change (and dodge the bullet) by running "chmod -R o-w /usr/bin" in the root shell of the recovery mode.

Ok - I changed the ownership of the folder /usr/bin ONLY. Not the contents of the folder.

So what you are telling me is that root access broke the system and reinstalling is my only recourse of action.

No offense, but I will re-install. I will not use "Root Access Services" in Dolphin again. It is just not ready for prime time.

[kubicle]

Ok - I changed the ownership of the folder /usr/bin ONLY. Not the contents of the folder.

So you didn't click "yes" on the dialog that asks whether you wish to apply changes to sub-folders and files? Then the menu won't change the permissions of the contents, which makes the sudo error quite strange.

So what you are telling me is that root access broke the system and reinstalling is my only recourse of action.

This depends on what exactly was changed, can you post the output of "ls -l /usr /usr/bin/sudo /usr/bin/mlocate"

No offense, but I will re-install. I will not use "Root Access Services" in Dolphin again. It is just not ready for prime time.

None taken. Root actions can be dangerous, like using (kde)sudo or using dolphin as root, but in the 10 years of it's existence I haven't gotten a single report of it doing things that the user didn't instruct it to do...so I'd be extremely interested in (and grateful for) all the details you can provide of the exact steps you did with the menu, so I can examine this possibly very serious issue (I can't reproduce it on my end, if I answer "no" on the recursive dialog...the contents of directories are unaffected).

[Qqmike]

re kubicle's Root Actions ... Well, many of here can vouch that it works! I always use it, and I use it sometimes for rather complicated-delicate-involved tasks. No problems.

[geezer]

So you didn't click "yes" on the dialog that asks whether you wish to apply changes to sub-folders and files? Then the menu won't change the permissions of the contents, which makes the sudo error quite strange.

No I did not. I specifically looked and made sure that only the folder was changed and not the contents. I have done this before and years back made the mistake of chnaging the contents also. That time the mistake was very benign since it didn't involve a "system" folder and was easy to correct. But I have been cognizant of that "error" ever since.

This depends on what exactly was changed, can you post the output of "ls -l /usr /usr/bin/sudo /usr/bin/mlocate"

No can do. I have just finished reinstalling and am in the process of upgrading from 15.04 to 15.10 now. The count down indicates 5 hrs for the upgrade to finish.

None taken. Root actions can be dangerous, like using (kde)sudo or using dolphin as root, but in the 10 years of it's existence I haven't gotten a single report of it doing things that the user didn't instruct it to do...so I'd be extremely interested in (and grateful for) all the details you can provide of the exact steps you did with the menu, so I can examine this possibly very serious issue (I can't reproduce it on my end, if I answer "no" on the recursive dialog...the contents of directories are unaffected).

It is most likely then that the mistake was on my part in some manner or other and not the "Root Actions Service". But I think either way I will refrain from using them in the future. 99% of the time I use "sudo cp" in the terminal to move files that are owned by root. Occasionally I run into situations that require moving 3 and more files, usually more. In those situations I use kdesudo dolphin to change a folder (ONLY) and then copy and paste files or copy and paste without changing the folder and then change the ownership of the pasted files (only). In this case I had "Root Actions" in Dolphin, it was a new tool for me and I decided to use it since that would skip the step of

1. Alt-F2,
2. entering the desired command line (kdesudo dolphin),
3. then the password and
4. then maneuvering through Dolphin, etc.

But I have decided that "Root Actions" in Dolphin is too dangerous for me.

The other method I use is to run jedit as root and modify the needed files (usually fstab, export, host allow, host deny, apcupsd.conf, etc) directly.

Also, I learned many years past that one of the first things I do after an install is to run Dolphin as root and change the ownership of /usr/local/bin to my user name and that allows me to add, delete and change files there without being root. But that is a one time action and since the folder is empty right after an install, doing so has no side effects.

[geezer]

Just remembered something else. When I used the Root Actions menu to change the permissions, the dialog was radically different from the Dolphin dialog to do the same thing. That threw me for a second or 2 and after studying the dialog for 15 to 20 seconds, I did what I thought was right. In Dolphin, I have to explicitly check a box to have the changes applied recursively to the contents of the folder. The default is to apply to the folder only.

Does Root Actions follow that philosophy also or does it apply the action to the the contents by default? If the later, then I made a mistake. Also, how easy would it be under the Root Actions dialog to apply to the contents also? If it is to easy, I may have made that mistake.

Either way, I think it will be better for me to stick with Dolphin without Root Actions since the dialog windows seem to be radically different. Since I use Dolphin regularly daily, the dialogs are familiar to me and so I am considerably less likely to make a mistake. Since the Root Action dialogs are radically different (NOT better or worse, just different), I will be less likely to make a mistake in the future by sticking to Dolphin (as in kdesudo dolphin) without Root Actions.

[kubicle]

Just remembered something else. When I used the Root Actions menu to change the permissions, the dialog was radically different from the Dolphin dialog to do the same thing. That threw me for a second or 2 and after studying the dialog for 15 to 20 seconds, I did what I thought was right. In Dolphin, I have to explicitly check a box to have the changes applied recursively to the contents of the folder. The default is to apply to the folder only.

Does Root Actions follow that philosophy also or does it apply the action to the the contents by default? If the later, then I made a mistake. Also, how easy would it be under the Root Actions dialog to apply to the contents also? If it is to easy, I may have made that mistake.

Either way, I think it will be better for me to stick with Dolphin without Root Actions since the dialog windows seem to be radically different. Since I use Dolphin regularly daily, the dialogs are familiar to me and so I am considerably less likely to make a mistake. Since the Root Action dialogs are radically different (NOT better or worse, just different), I will be less likely to make a mistake in the future by sticking to Dolphin (as in kdesudo dolphin) without Root Actions.

It does in fact use it's own dialog (different from dolphin) and there's no tick box for applying to contents. Just a simple yes/no confirmation for applying to contents (with yes being the default). So it is easier to apply the changes to contents by mistake (even though there is a warning included in the dialog), especially if you're not familiar with the dialogs of the menu.

This has been by design as the menu doesn't really do anything you can't do with a root dolphin, it's sole purpose is to make root actions faster/easier which is of course a double-edged sword...you can shoot faster, but it's also easier to shoot yourself in the foot by mistake. I'll take into consideration changing the default answer to "no" on the apply to contents to make it a tad harder to make critical mistakes.

[Teunis]

This can be caused by a general service menu bug [https://bugs.kde.org/show_bug.cgi?id=350769].

The bug is fixed upstream, but I don't think the fix has arrived in kubuntu yet.

1. Check whether your machine has the file /usr/share/kservicetypes5/konqpopupmenuplugin.desktop
2. If not, link the the kde4 version with "sudo ln -s /usr/share/kde4/servicetypes/konqpopupmenuplugin.desktop /usr/share/kservicetypes5/konqpopupmenuplugin.desktop"
3. Restart dolphin and the service menus should show up (if installed correctly)

Thanks for this one, the menu wouldn't show up after my reinstall, this was the problem and solution.

[geezer]

It does in fact use it's own dialog (different from dolphin) and there's no tick box for applying to contents. Just a simple yes/no confirmation for applying to contents (with yes being the default). So it is easier to apply the changes to contents by mistake (even though there is a warning included in the dialog), especially if you're not familiar with the dialogs of the menu.

This has been by design as the menu doesn't really do anything you can't do with a root dolphin, it's sole purpose is to make root actions faster/easier which is of course a double-edged sword...you can shoot faster, but it's also easier to shoot yourself in the foot by mistake. I'll take into consideration changing the default answer to "no" on the apply to contents to make it a tad harder to make critical mistakes.

Ahhhh - so it does apply to the contents by default. I probably missed that when I changed things and changed all of the contents of /usr/bin by default. My mistake. I have still decided to not use root actions though - too easy for me to make a mistake like that with unfamiliar an dialog.

I thank you for the explanation on kf5 though. Education does help.

[Qqmike]

kubicle: the menu doesn't really do anything you can't do with a root dolphin, it's sole purpose is to make root actions faster/easier

Hi geezer. Boy there are so many examples where the Root Actions menu is really nice to have. One simple, common example is editing configuration files: Dolphin --> locate the file --> Rt-click, Root Actions --> Open as Text. Do the edit, close THAT file, and you are done and clear of any danger of a spillover of your root privileges to another action you take next in Dolphin. OTOH, when you kdesudo dolphin, boy, you sure gotta remember you are in Dolphin with root privileges all the way (until you close Dolphin). IMO only. You can tell that I like kubicle's program. When I mess with boot configurations, I use that Root Actions menu all the time, on the run, and it sure is handy and safe (for me).

[geezer]

Hi geezer. Boy there are so many examples where the Root Actions menu is really nice to have. One simple, common example is editing configuration files: Dolphin --> locate the file --> Rt-click, Root Actions --> Open as Text. Do the edit, close THAT file, and you are done and clear of any danger of a spillover of your root privileges to another action you take next in Dolphin. OTOH, when you kdesudo dolphin, boy, you sure gotta remember you are in Dolphin with root privileges all the way (until you close Dolphin). IMO only. You can tell that I like kubicle's program. When I mess with boot configurations, I use that Root Actions menu all the time, on the run, and it sure is handy and safe (for me).

I totally agree with you. It makes doing one-off things much easier and faster and if I did those things daily and was totally familiar with the root action menus, then I would be using it also.

But that is exactly my point. I don't do those things daily. In fact rarely. But I do use dolphin many times a day to accomplish folder and file manipulations that do not require root privileges and that is the "root" (pun intended) of my problem.

The root action menus accomplish the same things that the Dolphin menus accomplish and that is part of the problem. I am very familiar with the dolphin menus and when I used root action, I assumed that I would be accomplishing the same end result, but I wasn't. For example, as I just found out, dolphin assumes by default that changing a folder does not extend to the contents. Root Action assumes exactly the opposite. Yet the intention of both s/w is the same and that leads somebody like myself to be a little lax in paying attention and thus making a fatal mistake. As I did.

If the assumptions behind the dolphin and root actions menus and the menus themselves were identical, then there would be no problem. But as kubicle explained, he is writing for multiple platforms and the platforms differ probably greatly in their means of accomplishing the same thing. Thus, it is unreasonable of me to expect him to match the dolphin way of doing things.

So one fatal mistake that costs me two whole days cannot justify saving seconds or maybe a minute of two on something that I do rarely, maybe once a month at the very most and more likely once every 2 or 3 months. In fact I can go for several months without requiring root privileges to accomplish my task on files/folders. That is one reason why one of the first things I do after a new install is to change the /usr/local/bin folder ownership to my user name. I do a fair amount of work with the files in that folder and making that change once saves me having to use root.

As another example: I have a folder that I install in /usr/local/share. Now I manipulate files there often and have the whole folder backed up on my backup disks (4 totally physically separate disks). So after a new install, I use dolphin as root and change the permissions on /usr/local/share to allow others to write to and change the contents of the folder. I then use another dolphin running under my user name to copy the folder over with my ownership and permissions. When the copying is finished, usually much less than a minute, I switch to the dolphin running under root and revert the permissions to what they were originally and exit that dolphin. I end up with a folder under /usr/local/share that I own and that filled with files that I can manipulate and that I can copy new files to and delete files as needed. All without root privilege. Why there and not under my user HOME folder. Because it is available to all users. I also change the permissions of /usr/local/bin to allow everybody to write and change the contents of the folder.

Now all of that is accomplished running 2 separate versions of dolphin on separate desktops. It takes maybe as much as 2 or 3 minutes. I end up with a new folder in /usr/local/share and with a vastly more useful folder for everybody in /usr/local/bin.

And that is what lead to my fatal mistake. I had a new installation, and was having problems with running dolphin as root (problems that later resolved themselves anyway). I needed to be able to write a program file to /usr/bin. I thought about reverting to the command line, but it has been 20 years since I was proficient at using all of those command line programs to do what I wanted. I was looking at several hours of memory refresh to accomplish the needed task using a command line. So root actions seemed like a desirable alternative. I can think of about 4 alternative methods to accomplish what I needed to do, but Root Actions seemed like a good one and one that I could use in the future.

Now I am not saying that there is anything wrong with Root Actions, only that for my very occasional use I am better off running dolphin as root for the rare times I need it. The subtle differences in Root Action can lead to serious mistakes when used rarely.

[kubicle]

Drifting a bit off topic here, but since the original issue seems solved, I hope you don't mind

I also change the permissions of /usr/local/bin to allow everybody to write and change the contents of the folder.

World writable /usr/local/bin is a bit of a security hole, since /usr/local/bin is commonly before /bin /sbin /usr/bin and /usr/sbin in every users $PATH. It would be, for example, somewhat trivial to "trick" another user to run malicious code.

Example:
1. Malicious user A writes malicious script named /usr/local/bin/nano (no root access needed if /usr/local/bin is world writable)
2. User B (an admin in this example) tries to edit a file with nano editor using "sudo nano"
3. Since /usr/local/bin is before /usr/bin in his $PATH, instead of the editor /usr/bin/nano the malicious script /usr/local/bin/nano is executed with elevated privileges (because of sudo).
4. System owned

Of course the threat is mitigated if you only have trusted users, but even if there aren't actual malicious users, even trusted users can (by mistake or ignorance) run malicious code that looks for weaknesses like this (world writable /usr/local/bin).

[oshunluvr]

To glob onto what kubicle says: I would never advise a new user to do anything in the system area unless it was absolutely necessary. I think over the last 3-4 years the amount of userspace tools to do tasks previously requiring system edits has increased dramatically. Like Network Manager, nVidia Settings, and others. The Root Actions menus aid in this by allowing a relatively inexperienced user to use a GUI tool to do necessary system tasks while minimizing the exposure of the system area.

Having said that; no different than Windows tool like regedit or very powerful but unfettered Linux tools like dd, all system tools must be used with thought and deliberation or disaster may be the final result.