xed warnings

[scrognoid]

Clean install of PIA did not fix.

[Cosmo.]

The 2 outputs for the systems A and B show some special details:

System A, which is said to be a LM 17.3 system:
The suspicious line there is the first for .cache//dconf. The permission denied error would be expected in Mint 18 and above (a update manager bug), but not in LM 17.x. So there must have been run more graphical programs than pluma in the past via sudo.

System B, which is said to be a LM 18.3 system:
There are (near the end) 2 lines regarding pluma. Was this system originally installed with any LM 17.3 and later been upgraded to LM 18.x?

For System B try to create a fresh new user account. Run in the new account gksudo xed. The same output as shown in the starting post?

[Penn]

This is only a guess. I am assuming the changing of permissions in your home folder not only happened just before the PIA issue but guessing it did cause it. If not, this really isn't the same topic at all. If so, the standard way things work in the the home folder, if an app or service needs something in your home folder (personal app preferences or history) and it isn't there, that app will create it. Perhaps rename the hidden folder of .pia_manager to something else such as .pia_manager.old (rename and not delete in case you need it later). I'm not sure when the components a loaded for PIA since I haven't used it so it may now be necessary to reboot or log out. You might have to set it up all over again when connecting.

If that fixes it, check the permissions of both the folder and the contents created for permission, both owner and group, and if they aren't user, let us know for future reference when helping other fix permission issues. If it doesn't fix it, I would venture to guess the issue is unrelated to the permissions.

[Termy]

WARNING! - The following has the potential (albeit unlikely, depending on your setup) to cause problems.

Now that's out of the way, I wanted to suggest something here, since I keep seeing these permission issues with HOME, when it's quite an easy fix to have your HOME files and directories in a very security-conscientious way, but also fix many typical permission errors.

The reason for the warning above, is that it's possible someone will have set up something like ~/bin with executables within, or Steam via your HOME, which this would break. There may be other cases wherein you install bizarre software or write scripts which require executable files in your HOME. If this is okay on your end, then this one-liner will follow suit of the RHEL-recommended umask of 0077, which basically means files will be 600 and directories 700, the minimum permissions needed for you (and only you) to deal with your files and directories.

WARNING! - Just to be absolutely clear, there is no undo feature for this command. It works recursively on ALL files and directories in your HOME.

By the way, this assumes you're the actual owner of your own files in your own HOME, ... just to get the obvious out of the way. xD

Code: Select all

/usr/bin/find $HOME -xdev \( -type f -exec /bin/chmod 600 "{}" \+ -o -type d -exec /bin/chmod 700 "{}" \+ \) -printf "FIXING: %p\n" 2> /dev/null

Taken from my alias below, although I added the $HOME to ensure that you don't accidentally run it in the wrong place. I use this very regularly and have done for a good while now.

Code: Select all

# Fix all CWD file and directory permissions to match the safer 0077 umask.
if [ -x /bin/chmod ]; then
        alias fixperms='\
                /usr/bin/find -xdev \( -type f -exec /bin/chmod 600 "{}" \+ -o\
                        -type d -exec /bin/chmod 700 "{}" \+ \)\
                        -printf "FIXING: %p\n" 2> /dev/null
        '
fi

Source for RHEL claim: https://wiki.archlinux.org/index.php?ti ... edirect=no

.lmscrot.jpg

[greerd]

This is a known issue when PIA is installed using their install script, (not the pia-manager app available in the repos). You will have to change the ownership of /home/jennifer/.pia_manager/openvpn_launcher.64<br/> and /home/jennifer/.pia_manager/openvpn_launcher.32<br/> to root.

[Termy]

Lol Weird. I'm guessing the script checks for root access.

[greerd]

Lol Weird. I'm guessing the script checks for root access.

Not sure what pia does but after it's installed, you run pia as normal user, but the app can modify iptables when 'Network lock' (or what ever they call it) is checked. (setuid?) (sudores or sudoers.d hasn't been modified by pia)

[scrognoid]

PIA is working again. I don't know why. Maybe the clean install worked but I failed to connect at first due to a coincidental network problem.
Checking home permissions again:
>>> find $HOME ! -user $USER -type f
/home/tim/.pia_manager/log/openvpn.pid
/home/tim/.pia_manager/openvpn_launcher.64
/home/tim/.pia_manager/openvpn_launcher.32

And
>>> ls -l .pia_manager
total 12232
...snip...
drwxr-xr-x 2 tim tim 4096 Feb 13 11:20 openvpn-64/
-rwsrwxr-x 1 root tim 6241581 Feb 13 11:20 openvpn_launcher.32*
-rwsrwxr-x 1 root tim 6247691 Feb 13 11:20 openvpn_launcher.64*
drwxr-xr-x 5 tim tim 4096 Feb 13 11:20 pia_manager/
...snip...
drwxr-xr-x 2 tim tim 4096 Feb 14 16:57 tmp/

From greerd it sounds like I want those to be owned by root.

I think I'm good here unless there is more penance for years of sudo pluma.

This is System A 17.3. Will report back later on System B suggestions.

[scrognoid]

Tried

Code: Select all

   gksu xed

from new user tim:

Code: Select all

tim@jenXPS13 ~ $ gksu xed

** (xed:6109): WARNING **: Set document metadata failed: Setting attribute metadata::xed-spell-language not supported

** (xed:6109): WARNING **: Set document metadata failed: Setting attribute metadata::xed-encoding not supported

** (xed:6109): WARNING **: Set document metadata failed: Setting attribute metadata::xed-position not supported

Those warnings appeared on exit after saving Unsaved Document 1.
Checking:

Code: Select all

tim@jenXPS13 ~ $ find $HOME ! -user $USER -type f
/home/tim/Desktop/Unsaved Document 1

tim@jenXPS13 ~ $ ls -l Desktop/
total 4
-rw-r--r-- 1 root root 2 Feb 15 16:30 Unsaved Document 1
tim@jenXPS13 ~ $

Meanwhile back with the original user:
I did the ownership shuffle thing for the original user jennifer and broke PIA again. Changing owner to root on the three pia files did not fix it

Code: Select all

jennifer@jenXPS13 ~ $ find $HOME ! -user $USER -type f
/home/jennifer/.pia_manager/log/openvpn.pid
/home/jennifer/.pia_manager/openvpn_launcher.64
/home/jennifer/.pia_manager/openvpn_launcher.32

Clean install of PIA fixed it but not until after a shutdown; logout, restart did not do it. That explains the "PIA magically started working again" before.
Original user jennifer gets same warnings from gksu xed.

I am functional except for gksu xed warnings.

[JeremyB]

Use xed to create a new file named org.gnome.xed.policy in your /home directory, enter the following

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>

  

 <vendor>xed</vendor>
 <vendor_url>http://linuxmint.com/</vendor_url>
 <icon_name>text-editor</icon_name>


 <action id="org.gnome.xed">
 
 <description>Run Xed as root</description>
 
 <defaults>
 <allow_any>no</allow_any>
 <allow_inactive>auth_admin</allow_inactive>
 <allow_active>auth_admin</allow_active>
 </defaults>
 <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/xed</annotate>
 <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
 </action>

</policyconfig>

Save and then in terminal

Code: Select all

sudo cp org.gnome.xed.policy /usr/share/polkit-1/actions/

Then you can open xed as administrator with pkexec xed or open a file using the same command followed by the file name. The gksu package hasn't been updated in a long time and pkexec is the preferred replacement, however many apps don't have the policy file in /usr/share/polkit-1/actions/

Edit to add: Even with using pkexec, there are some warnings in terminal

Code: Select all

(xed:17049): Gtk-WARNING **: Calling Inhibit failed: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files

** (xed:17049): WARNING **: Set document metadata failed: Setting attribute metadata::xed-spell-language not supported

** (xed:17049): WARNING **: Set document metadata failed: Setting attribute metadata::xed-encoding not supported

** (xed:17049): WARNING **: Set document metadata failed: Setting attribute metadata::xed-position not supported

[FreedomTruth]

Not really a "fix" but you can suppress these kind of warnings. The code is based on the post at https://askubuntu.com/questions/505594/ ... 827#572827. I put it in ~/.bashrc

Code: Select all

_suppress() {
  eval "$1() { \$(which $1) \"\$@\" 2>&1 | while read b; do
    if [ ! -z \"\$(echo \\\"\$b\\\" | grep -Ev '"$2"')\" ]; then
      echo \"\$b\"
    fi
    done; }"
}

# to suppress each warning individually:
#_suppress xed "The name org.gnome.SessionManager was not provided|Setting attribute metadata::xed-spell-language not supported|Setting attribute metadata::xed-encoding not supported|Setting attribute metadata::xed-position not supported"
# or, to suppress them all at once (and any other warnings)
_suppress xed "WARNING"

I got gnome sessionmanager warning just running "xed filename" from terminal, once I start editing. No file permissions issues here. Bonus: you can use the same code to suppress other message(s) from other program(s)
for example, (same problem) add _suppress gedit "Gtk-WARNING" to get rid of the terminal warning messages from gedit.

[scrognoid]

These types of warnings are typical when running Gtk applications as root. It shouldn't be preventing Xed from working but simply warning you that certain functionality isn't. For example, xed-position is the bit of info in the metadata that xed uses for it's "Restore cursor position" functionality. It's just letting you know that it wasn't able to write that part of the metadata so your cursor won't be restored to the same position as it was when you last worked on the file.

You could also just use

Code: Select all

SUDO_EDITOR=xed sudoedit /etc/auto.sambashares

That creates a temporary version of the file you can edit as your own user and only overwrites the original once the editor is closed.

I tried this but sudoedit involves nano.

[JosephM]

These types of warnings are typical when running Gtk applications as root. It shouldn't be preventing Xed from working but simply warning you that certain functionality isn't. For example, xed-position is the bit of info in the metadata that xed uses for it's "Restore cursor position" functionality. It's just letting you know that it wasn't able to write that part of the metadata so your cursor won't be restored to the same position as it was when you last worked on the file.

You could also just use

Code: Select all

SUDO_EDITOR=xed sudoedit /etc/auto.sambashares

That creates a temporary version of the file you can edit as your own user and only overwrites the original once the editor is closed.

I tried this but sudoedit involves nano.

What? The first part of that command SUDO_EDITOR=xed tells sudoedit to use xed. You can set it to the editor of your choice.

[scrognoid]

I tried this but sudoedit involves nano.

What? The first part of that command SUDO_EDITOR=xed tells sudoedit to use xed. You can set it to the editor of your choice.

I meant 'invokes'. I execute

Code: Select all

SUDO_EDITOR=xed sudoedit /etc/auto.sambashares

but sudoedit still call nano.

[Termy]

--snip--

I'd recommend this instead:

Code: Select all

_suppress(){ $1 |& while read b; do [ "${b/$2}" ] && printf "%s\n" "${b/$2}"; done; return ${PIPESTATUS[0]}; }

Or more spaced out:

Code: Select all

_suppress(){
	$1 |& while read b; do
		[ "${b/$2}" ] && printf "%s\n" "${b/$2}"
	done

	return ${PIPESTATUS[0]}
}

It's simpler, faster, and more efficient. Can even use echo if you want, to make it shorter. (I always use printf for it's consistency) This method also has the bonus of allowing specific strings to be removed, and not just the lines with the match. It'll also allow the exit status to function properly.

[scrognoid]

What? The first part of that command SUDO_EDITOR=xed tells sudoedit to use xed. You can set it to the editor of your choice.

Doh! Got confused going back and forth between systems. No xed on System A.

Code: Select all

SUDO_EDITOR=pluma sudoedit /etc/auto.sambashares

works nicely.
Can I permanently set SUDO_EDITOR?

[dlazerka]

Hi, is there a recommended way now for Linux Mint 20.1 Cinnamon? Because there's no more `gksudo` anymore.