Forum rules
Do not post support questions here. Before you post read the forum rules. Topics in this forum are automatically closed 6 months after creation.
MintBean wrote: ⤴Tue Apr 24, 2018 5:14 pm
In Nemo you can browse to a folder, right click on the background in the file display area and select 'open as root.' Displaying a file from the window will then open the editor with elevated privileges.
This works in caja also.
Nope,
Just upgraded from 18.3 to 19 and this particular feature is gone. And I need it badly.
There are only few extensions installed by default. The one you are looking for is:
The edit as administrator function is hardcoded to use pluma as the editor though, so you'll either have to install that, modify the script or install caja-actions and just define your own menu entry to do that.
Last edited by gm10 on Thu Jul 05, 2018 8:56 am, edited 1 time in total.
"Could not parse arguments: can't open screen."
I've discovered that gksu is actually still installed. Nevertheless it's not working the way it was before.
The edit as administrator function is hardcoded to use pluma as the editor though, so you'll either have to install that, modify the script or install caja-action and just define your own menu entry to do that.
Thank you very much! This has saved me a lot of trouble. I suppose I can freely remove gksu altogether?
xenopeek wrote: ⤴Thu Jul 05, 2018 8:57 am
I really thought caja-admin was installed by default. Is this perhaps because of upgrading in place that it was missing?
Nope. Ubuntu MATE 18.04 has it by default, Mint 19 MATE does not, maybe that's what has you confused.
Last edited by gm10 on Thu Jul 05, 2018 9:20 am, edited 1 time in total.
xenopeek wrote: ⤴Thu Jul 05, 2018 8:57 am
I really thought caja-admin was installed by default. Is this perhaps because of upgrading in place that it was missing?
Nope. Ubuntu MATE 18.04 has it by default, Mint 19 MATE does not, maybe that's what has you confused.
You are incorrect. I just checked on a fresh install of Linux Mint 19 MATE and caja-admin is installed by default.
xenopeek wrote: ⤴Thu Jul 05, 2018 8:57 am
I really thought caja-admin was installed by default. Is this perhaps because of upgrading in place that it was missing?
Nope. Ubuntu MATE 18.04 has it by default, Mint 19 MATE does not, maybe that's what has you confused.
It's present and correct on a freshly installed Mate 19 over here...
For custom Nemo actions, useful scripts for the Cinnamon desktop, and Cinnamox themes visit my Github pages.
It's been removed by about every other distro as upstream it was discontinued years ago. The fact that Ubuntu still has it in the universe repo is more a symptom of that state of that repo than anything else.
xenopeek wrote: ⤴Thu Jul 05, 2018 9:15 am
You are incorrect. I just checked on a fresh install of Linux Mint 19 MATE and caja-admin is installed by default.
You are correct. Maybe it wasn't installed automatically in the beta version and that's what I was remembering? I don't have the beta iso anymore so can't check.
If he had it in Mint 18.3 and it went missing with the upgrade then I suppose there's a problem with the upgrade script.
xenopeek wrote: ⤴Thu Jul 05, 2018 8:57 am
I really thought caja-admin was installed by default. Is this perhaps because of upgrading in place that it was missing?
Maybe it's because it was not a fresh install. I don't know. All I know it works now.
MintBean wrote: ⤴Tue Apr 24, 2018 5:14 pm
In Nemo you can browse to a folder, right click on the background in the file display area and select 'open as root.' Displaying a file from the window will then open the editor with elevated privileges.
This works in caja also.
Nope,
Just upgraded from 18.3 to 19 and this particular feature is gone. And I need it badly.
Go to /usr/bin/ and make a symbolic link to pkexec. Call it "gksu":
cd /usr/bin
sudo ln -s pkexec gksu
ingeva wrote: ⤴Thu Jul 05, 2018 4:11 am
I copied /usr/bin/gksudo from an 18.3 distribution to my 19 distro. Works just fine.
You're taking risks, though... Note that pkexec is by design more secure than gksu (which is why gksu was abandoned in the first place), and furthermore: gksu doesn't get any security updates anymore.
I advise to go with the flow, and switch to pkexec and admin://.
You're right, of course. I have corrected my post.
I have fallen foul of the gksu removal, and none of the discussions I haver seen in this thread come anywhere near my use case AFAIK, so use of admin:// etc does not seem to work.
My use case is having a simple bash script to mount/unmount several windows shares using a command of the form "mount.cifs ${server}/${sleaf:-$remote} $Mount_point_root/$leaf -o $Options" which is invoked in a looper to mount several shares when I am on a particular network.
This bash script was itself invoked by a .desktop file using a line of the form 'Exec=gksu -S "/home/tim/bin/mounter/mount.sh woodentop"'
using admin:///home/tim/bin/mounter/mount.sh woodentop fails with a "no such file or directory" error
using pkexec /home/tim/bin/mounter/unmount.sh woodentop pops up a password window similar to gksu but then fails with a "Unable to init server: Could not connect: Connection refused"
I suspect this may be because some form of config file is needed somewhere in a policykit config folder but I cannot readily relate the man page example to my use case as it seems to refer to options that I have no equivalent for.
You can replace gksu with sudo and set Terminal=true in the .desktop file. That way the script will run in a terminal and you can enter your password on the terminal. You were only using gksu because it provided you with a dialog to enter your password I assume. So you can instead use the regular sudo password prompt on the terminal. This is the easiest and most future proof.
Alternatively you can install an askpass program and use that to provide sudo with a dialog to enter your password. A dialog similar to what gksu provided for your script. For example the package ssh-askpass-gnome provides an askpass program you can use for this. After installing it you can run a command like: SUDO_ASKPASS=/usr/lib/openssh/gnome-ssh-askpass sudo -A bash
and it will show a dialog prompt to enter your password, after which it will run bash as root. If you have just one command in your script that needs root, just prefix it in your script with that (replace bash in above with your command) and you can remove gksu from your .desktop file. If you have multiple commands that need root in your script you'll have to tinker with your .desktop file a bit. Likely you'll need to replace the Exec command with something like this to be able to set the SUDO_ASKPASS variable:
Exec=bash -c 'SUDO_ASKPASS=/usr/lib/openssh/gnome-ssh-askpass sudo -A "/home/tim/bin/mounter/mount.sh woodentop"'
xenopeek wrote: ⤴Sun Aug 19, 2018 4:12 pm
Alternatively you can install an askpass program and use that to provide sudo with a dialog to enter your password. A dialog similar to what gksu provided for your script. For example the package ssh-askpass-gnome provides an askpass program you can use for this. After installing it you can run a command like: SUDO_ASKPASS=/usr/lib/openssh/gnome-ssh-askpass sudo -A bash
and it will show a dialog prompt to enter your password, after which it will run bash as root. If you have just one command in your script that needs root, just prefix it in your script with that (replace bash in above with your command) and you can remove gksu from your .desktop file. If you have multiple commands that need root in your script you'll have to tinker with your .desktop file a bit. Likely you'll need to replace the Exec command with something like this to be able to set the SUDO_ASKPASS variable:
Exec=bash -c 'SUDO_ASKPASS=/usr/lib/openssh/gnome-ssh-askpass sudo -A "/home/tim/bin/mounter/mount.sh woodentop"'
to your ~/.profile and sudo will pop up the password question automatically without you having to change any command lines (once you log in the next time).
xenopeek wrote: ⤴Mon Aug 20, 2018 1:40 am
You still need to use sudo -A in that case to use askpass, right?
Another alternative is to reconfigure sudo so that the script is permitted to be run as root without a password prompt. That gets complicated though.
No, as long as sudo finds the environment variable it will pop the question automatically. I'm not sure if that's intentional (see manual seems to indicate otherwise) but it's how it works.
Your alternative has, of course, security implications.