xpra doesn't start, in the logs I have (++) Log file: "/run/user/1000/xpra/100/Xorg.log", Time: Sat Nov 8 09:45:00 2025 (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Fatal server error: (EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied) (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org xpra-5.1.1-5.fc43 If I install xpra from the official repo, version xpra-6.4-10.r39535.fc43 everything works as expected. Reproducible: Always Steps to Reproduce: 1. run xpra 2. 3. Actual Results: Doesn't start Expected Results: Start as expected.
If it helps others, I had the same problem. As mentioned in: https://wiki.archlinux.org/title/Xpra#Troubleshooting I created an new empty file at: /etc/X11/Xwrapper.config and added the following in that file: allowed_users=anybody I also added the following to the end of my xpra command: --xvfb=/usr/bin/Xorg eg. xpra start ssh://$USER@$SERVER/100 --start-child=xterm --xvfb=/usr/bin/Xorg Xpra 6.3.4 (from fedora42 updates repo - it has only just been pushed to stable!) started working again normally for me with the above. YMMV
FEDORA-2025-529dfd0426 (xpra-6.3.6-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-529dfd0426
@srh Thank you for your feedback. Please, try the new release in testing that automatically installs /etc/X11/Xwrapper.config and let me know if it works.
FEDORA-2025-529dfd0426 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-529dfd0426` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-529dfd0426 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-5ac5e7d7ca (xpra-6.3.6-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-5ac5e7d7ca
FEDORA-2025-5ac5e7d7ca has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-5ac5e7d7ca` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-5ac5e7d7ca See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
When I run the dnf upgrade ... I have this No advisory found matching the requested name: "FEDORA-2025-5ac5e7d7ca" Nevertheless I installed the update with sudo dnf upgrade --enablerepo=updates-testing --refresh '*xpra*' And I have the xpra-6.3.6-1.fc43 but this doesn't solve the problem, I have /etc/X11/Xwrapper.config with allowed_users=anybody Works if I add --xvfb=/usr/bin/Xorg in the command line but it seems this is a workaround that no one will know that should be add
FEDORA-2025-5ac5e7d7ca (xpra-6.3.6-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-529dfd0426 (xpra-6.3.6-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
Dear maintainer, 1. Please REMOVE /etc/X11/Xwrapper.config from this package, as it's irrelevant to xpra on Fedora and it could unwittingly compromise security on any system it's installed on. (It's irrelevant because xpra 6.x comes with a script called xpra_Xdummy whose purpose is to find the non-suid Xorg binary and execute it - therefore xpra does not go via the Xorg wrapper.) 2. This bug is a regression from 5.0.10 (I'm using the Fedora 42 version at the moment) and the bug is still present. The reason why it fails to start can be seen in the output of 'xpra --help', specifically this bit: --xvfb=CMD How to run the headless X server. Default: 'xpra_Xdummy +extension GLX +extension RANDR +extension RENDER -extension DOUBLE-BUFFER -nolisten tcp -noreset -novtswitch -auth $XAUTHORITY -logfile ${XPRA_SESSION_DIR}/Xorg.log -configdir ${XPRA_SESSION_DIR}/xorg.conf.d/$PID -config ${XORG_ CONFIG_PREFIX}build/bdist.linux-x86_64/wheel/xpra- 6.3.6.data/data/etc/xpra/xorg.conf'. and also in 'strace' output where Xorg tries to open the config file with the invalid path that starts with 'build/bdist.linux'. I've not debugged the build to find out where that path is being inserted, but the path should simply be '${XORG_CONFIG_PREFIX}/etc/xpra/xorg.conf'.
(In reply to Ian Collier from comment #10) > Dear maintainer, > > 1. Please REMOVE /etc/X11/Xwrapper.config from this package, as it's > irrelevant to xpra on Fedora and it could unwittingly compromise security on > any system it's installed on. (It's irrelevant because xpra 6.x comes with > a script called xpra_Xdummy whose purpose is to find the non-suid Xorg > binary and execute it - therefore xpra does not go via the Xorg wrapper.) Okay > > 2. This bug is a regression from 5.0.10 (I'm using the Fedora 42 version at > the moment) and the bug is still present. The reason why it fails to start > can be seen in the output of 'xpra --help', specifically this bit: > > --xvfb=CMD How to run the headless X server. Default: > 'xpra_Xdummy +extension GLX +extension RANDR > +extension RENDER -extension DOUBLE-BUFFER -nolisten > tcp -noreset -novtswitch -auth $XAUTHORITY -logfile > ${XPRA_SESSION_DIR}/Xorg.log -configdir > ${XPRA_SESSION_DIR}/xorg.conf.d/$PID -config > ${XORG_ > CONFIG_PREFIX}build/bdist.linux-x86_64/wheel/xpra- > 6.3.6.data/data/etc/xpra/xorg.conf'. > > and also in 'strace' output where Xorg tries to open the config file with > the invalid path that starts with 'build/bdist.linux'. I've not debugged > the build to find out where that path is being inserted, but the path should > simply be '${XORG_CONFIG_PREFIX}/etc/xpra/xorg.conf'. Just '/etc/xpra/conf.d/55_server_x11.conf' file contains "build/bdist.linux*" paths, i'm removing them. Please, try next build release and let me know if xpra works fine
FEDORA-2025-0c313180c6 (xpra-6.4-2.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2025-0c313180c6
FEDORA-2025-98cabc115f (xpra-6.4-2.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-98cabc115f
FEDORA-2025-443e19e4bb (xpra-6.4-2.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-443e19e4bb
FEDORA-2025-d47c335be1 (xpra-6.4-3.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2025-d47c335be1
FEDORA-2025-e5d2f2f869 (xpra-6.4-4.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2025-e5d2f2f869
FEDORA-2025-e5d2f2f869 (xpra-6.4-4.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-443e19e4bb has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-443e19e4bb` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-443e19e4bb See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-98cabc115f has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-98cabc115f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-98cabc115f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-98cabc115f (xpra-6.4-2.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
Many thanks for the fix. xpra-6.4-2.fc42.x86_64 does indeed start correctly.
FEDORA-2025-443e19e4bb (xpra-6.4-2.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.