[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