[winswitch] Various mountpoints (both /dev/sd* and NFSv4) readonly after xpra session created
mailinglist__shifter-users at compeuphoria.com
mailinglist__shifter-users at compeuphoria.com
Mon Aug 14 21:32:55 BST 2017
Hello there;
First-off, let me preface this by admitting I cannot tell if this a
strictly-xpra issue, strictly-Fedora 26 issue, silliness in Systemd,
operator-stupidity on my part, or some combination of the above. I've gone
back through 2-1/2 years of the mailing-list archives, and googled every
pertinent term I could think of, but I haven't had much luck.
Environment Details
-------------------
Host OS: Fedora 26 (x86_84)
xpra Server: 2.2-0.20170811r16688.fc26 (from WinSwitch beta repo)
Client OS: Windows 10 (yuck!)
xpra client: Xpra 2.2 (64-bit) revision 16657 (2017-08-08)
I'm using the repo-supplied 'xpra.service' unit file to start xpra on the
host. This works, properly bringing up an xpra proxy, and I can
successfully create a session through it from my client (with an existing
non-root account).
However, I have found that many of my filesystem mounts are (both /dev/sd*
and NFSv4 mounts) are read-only. This happens both in terminals (tested in
xterm and gnome-terminal), and with other apps (e.g. Calibre, brasero,
devedeng, etc.). If I directly ssh into the host from my client PC with
that same non-root account then the filesystems appear properly as
read-write. Same is true if I ssh from xterm (inside the xpra session) to
user at localhost - mounts are now read-write.
Also within that xterm, I can do things like "sudo mount -o remount,rw
<mountpoint>" successfully. However this won't work for non-terminal apps
without writing wrappers, etc. It also doesn't address whatever my
root-cause is.
I suspect this has something to do with how the user-session environment is
being set up, but I'm enough of a Systemd noob that I have no idea how to
troubleshoot the problem.
For what it's worth, here's 'ps -ef' output showing both the xpra proxy
process started by the Systemd unit file, and the processes that are spawned
when I start up the actual xpra session:
root 8105 1 0 16:05 ? 00:00:00 /usr/bin/python2
/usr/bin/xpra proxy :14500 --daemon=no --tcp-auth=allow
--ssl-cert=/etc/letsencrypt/live/example.com/cert.pem --bind=none
--auth=allow --socket-dirs=/run/xpra --socket-permissions=666
--log-dir=/var/log --pidfile=/run/xpra.pid --debug=
testuser 8156 1 2 16:05 ? 00:00:15 /usr/bin/python2
/usr/bin/xpra start --csc-modules=all --attach=no --start-via-proxy=no
--packet-encoders=rencode, bencode, yaml --video-decoders=all
--encodings=all --compressors=lz4, lzo, zlib --video-encoders=all
--env=XPRA_PROXY_START_UUID=f42ee27577b24606a04bf6dc3feeb251 --daemon=yes
--systemd-run=no --uid=1000 --gid=1000 --displayfd=17
testuser 8157 8156 0 16:05 ? 00:00:05
/usr/libexec/Xorg-for-Xpra-S8152 -noreset -novtswitch -nolisten tcp
+extension GLX +extension RANDR +extension RENDER -auth /root/.Xauthority
-logfile /run/user/1000/xpra/Xorg.S8152.log -configdir
/run/user/1000/xpra/xorg.conf.d/8156 -config /etc/xpra/xorg.conf -depth 24
-displayfd 8
testuser 8255 8105 1 16:06 ? 00:00:10 /usr/bin/python2
/usr/bin/xpra proxy :14500 --daemon=no --tcp-auth=allow
--ssl-cert=/etc/letsencrypt/live/example.com/cert.pem --bind=none
--auth=allow --socket-dirs=/run/xpra --socket-permissions=666
--log-dir=/var/log --pidfile=/run/xpra.pid --debug=
testuser 8317 8156 3 16:06 ? 00:00:22 /usr/bin/python2
/usr/bin/xpra _sound_record - - pulsesrc device=Xpra-Speaker.monitor
opus+ogg 1.0
testuser 9872 8441 0 16:17 pts/4 00:00:00 grep --color=auto xpra
I cannot find anything seemingly related to this in the xpra logs, but I can
provide if requested.
Any suggestions, or tips on how to better troubleshoot this, would be
very-greatly appreciated.
Thank you
More information about the shifter-users
mailing list