Fedora 41 KDE unable to connect from Win 11

[Joe_Wulf]

I’ve recently upgraded a RHEL 8.3 (running KDE) system to Fedora 41 KDE spin.  Everything on the Fedora side is excellent.  Current with patches/updates.  My primary desktop is Win 11.  However, leveraging NoMachine to go from my Win 11 desktop to the Fedora 41 (running KDE) has been impossible.  I either receive endless connection restart messages, there is no desktop to connect to, etc…

I am running the latest version of free NoMachine on both systems, at version 8.14.2.  The problem is going from a physical Win 11 system to a freshly installed Fedora 41 (KDE Spin); on a Dell T5500 with dual Intel Xeon CPUs with 72GB RAM.

My Win11 Desktop is a custom tower, with a Supermicro x11-DAI-n with dual Intel Xeon Silver 4214 CPUs, 256 GB of RAM.

Additionally, what is being done to provide active support in the Linux world for Wayland?

Thank you.

R,

-Joe Wulf

[Britgirl]

Hi,

I either receive endless connection restart messages, there is no desktop to connect to, etc…

There is a known issue https://kb.nomachine.com/TR05V11141 and the workaround is to use x.org rather than Wayland. This is of course a temporary workaround whilst developers work on a solution. It would be useful to see the logs from both the NoMachine Windows client and the NoMachine Fedora server. You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243. This would allow us to check if it is indeed the same issue as the TR I linked or something else (you mention multiple problems but without any other details about when they occur).

Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!

[Joe_Wulf]

Subj: My nomachine status update (ID 50858/50868)

I compared the MD5sum of the NoMachine v8.14.2_1 Linux installer I have, and matched it to what the NoMachine web site is currently providing. The Linux system is not the computer at my desk, but across the room; thus I want to access it ‘remotely’ via NoMachine. So, NoMachine, on this Linux Fedora 41 KDE system, is intended to ‘serve’ up the desktop to my Win11 NoMachine client. My Win11 client, as of the time I’m writing this, is current with Windows patches and been rebooted. The Win11 system also has the latest version of NoMachine (8.14.2_2), which is intended to be the client served by the Linux computer, as I verified the md5sum for that one, too.

I started off by first completely removing NoMachine from the Fedora Linux 41 KDE installation I have on the physical Dell T5500 host, as follows:

[root@server:]# dnf remove nomachine
Package Arch Version Repository Size
Removing:
nomachine x86_64 8.14.2-1 @commandline 55.7 MiB

Transaction Summary:
Removing: 1 package

Is this ok [y/N]: y
Running transaction
[1/2] Prepare transaction 100% | 0.0 B/s | 1.0 B | 01m01s
>>> Running pre-uninstall scriptlet: nomachine-0:8.14.2-1.x86_64
>>> Finished pre-uninstall scriptlet: nomachine-0:8.14.2-1.x86_64
>>> Scriptlet output:
>>> NX> 702 Starting uninstallation at: Sun, 08 Dec 2024 10:57:55.
>>> NX> 702 Uninstallation log is: /usr/NX/var/log/nxuninstall.log.
>>> NX> 702 Uninstalling nxserver version: 8.14.2.
>>> NX> 702 Uninstalling nxnode version: 8.14.2.
>>> NX> 702 Uninstalling nxplayer version: 8.14.2.
>>> NX> 702 Uninstalling nxrunner version: 8.14.2.
>>> NX> 702 Uninstallation completed at: Sun, 08 Dec 2024 10:58:53.
>>>
[2/2] Removing nomachine-0:8.14.2-1.x86_64 100% | 4.0 B/s | 10.0 B | 00m02s
Complete!

[root@server:]# rm -rf .nx /usr/NX /etc/NX /var/NX

[root@server:]# ll /etc/systemd/system/nxserver.service
lrwxrwxrwx. 1 root root 9 Dec 8 10:54 /etc/systemd/system/nxserver.service -> /dev/null

[root@server:]# unlink /etc/systemd/system/nxserver.service

I ensured the Linux system was currently/fully patched (dnf -y update); I then did ‘touch /.autorelabel’ and rebooted it.

On my Win11 desktop, I first did:

C:\Windows\System32>%ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe –debug –disable all
NX> 900 Debug mode disabled for: server
NX> 900 Debug mode disabled for: node
NX> 900 Debug mode disabled for: agent

C:\Windows\System32>
C:\Windows\System32>
C:\Windows\System32>%ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe –logrotate
NX> 900 Starting log rotation procedure.
NX> 900 Created compressed file ‘C:\ProgramData\\NoMachine\\var\\log\\logrotate\\nxserver.log-2024.12.08-12.22.49.gz’.
NX> 900 Created compressed file ‘C:\ProgramData\\NoMachine\\var\\log\\logrotate\\nxserver.log-zzAdmin-2024.12.08-12.22.49.gz’.
NX> 900 Log rotation procedure for ‘nxserver.log’ has finished successfully.
NX> 900 Created compressed file ‘C:\ProgramData\\NoMachine\\var\\log\\logrotate\\nxd.log-2024.12.08-12.22.49.gz’.
NX> 900 Log rotation procedure for ‘nxd.log’ has finished successfully.
NX> 900 Created compressed file ‘C:\ProgramData\\NoMachine\\var\\log\\logrotate\\nxservice.log-2024.12.08-12.22.49.gz’.
NX> 900 Log rotation procedure for ‘nxservice.log’ has finished successfully.

Next I cleanly installed nomachine on the Fedora Linux 41 KDE physical system, as follows:

[root@server:]# dnf -y install nomachine_8.14.2_1_x86_64.rpm

Updating and loading repositories:
Repositories loaded.
Package Arch Version Repository Size
Installing:
nomachine x86_64 8.14.2-1 @commandline 55.7 MiB

Transaction Summary:
Installing: 1 package

Total size of inbound packages is 53 MiB. Need to download 0 B.
After this operation, 56 MiB extra will be used (install 56 MiB, remove 0 B).
Running transaction
[1/3] Verify package files 100% | 7.0 B/s | 1.0 B | 00m00s
[2/3] Prepare transaction 100% | 0.0 B/s | 1.0 B | 00m02s
[3/3] Installing nomachine-0:8.14.2-1.x86_64 100% | 1.0 MiB/s | 52.8 MiB | 00m52s
>>> Running post-install scriptlet: nomachine-0:8.14.2-1.x86_64
>>> Finished post-install scriptlet: nomachine-0:8.14.2-1.x86_64
>>> Scriptlet output:
>>> NX> 700 Starting installation at: Sun, 08 Dec 2024 12:26:28.
>>> NX> 700 Using installation profile: Fedora.
>>> NX> 700 Installation log is: /usr/NX/var/log/nxinstall.log.
>>> NX> 700 Installing nxrunner version: 8.14.2.
>>> NX> 700 Installing nxplayer version: 8.14.2.
>>> NX> 700 Installing nxnode version: 8.14.2.
>>> NX> 700 Installing nxserver version: 8.14.2.
>>> NX> 700 Installation completed at: Sun, 08 Dec 2024 12:27:12.
>>> NX> 700 NoMachine was configured to run the following services:
>>> NX> 700 NX service on port: 4000
>>>
Warning: skipped OpenPGP checks for 1 package from repository: @commandline
Complete!

I checked the status of the Linux NoMachine nxserver daemon:

[root@server:]# sstatus nxserver
sStatus nxserver
20241208_134642_EST
● nxserver.service – NoMachine Server daemon
Loaded: loaded (/usr/lib/systemd/system/nxserver.service; enabled; preset: 5:185mdisabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf, 50-keep-warm.conf
Active: active (running) since Sun 2024-12-08 13:29:06 EST; 17min ago
Invocation: 4a7027e6cb174f74b76c7c2c2b9290de
Main PID: 1628 (nxserver.bin)
Tasks: 31 (limit: 86846)
Memory: 123.8M (peak: 134.8M)
CPU: 6.325s
CGroup: /system.slice/nxserver.service
├─1628 /usr/NX/bin/nxserver.bin –daemon
└─1763 /usr/NX/bin/nxd

Dec 08 13:29:06 server systemd[1]: Started nxserver.service – NoMachine Server daemon.

I made no configuration changes to nomachine at this point.

Following the instructions at “https://kb.nomachine.com/DT07S00243”, I began to gather the server and client logs, per your request above, for first the server then the client.

[root@server:/var/log:]# nxserver –debug –enable all
NX> 900 Debug mode enabled for: server
NX> 900 Debug mode enabled for: node
NX> 900 Debug mode enabled for: agent

C:\Windows\System32>%ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe –debug –enable all
NX> 900 Debug mode enabled for: server
NX> 900 Debug mode enabled for: node
NX> 900 Debug mode enabled for: agent

Next, I attempted to reconnect from my Win11 client to the Linux Fedora 41 KDE Server. A connection ‘seems’ to have been made, but my local Win11 client nomachine window remained black/blank. After 20-25 seconds, the client displayed “Attempting to reconnect to server; error was: connection timed out”, then blanked out again. The cycle of a blank screen and reconnecting messages continues until I close the Win11 client of nomachine.

The problem has been reproduced; now to collect logs.
I start with generating the Linux Server logs:

[root@server:/var/log:F41:]# /etc/NX/nxserver –debug –collect
NX> 900 Procedure to collect logs started.
NX> 900 Creating log archive.
NX> 900 Log archive successfully created.
NX> 900 Archive is: /usr/NX/var/log/archives/NoMachine-log-2024.12.08-16.17.31.zip
NX> 900 Procedure to collect logs finished successfully.

I then generate the Win11 client logs:

%ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe –debug –collect
C:\Windows\System32>%ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe –debug –collect
NX> 900 Procedure to collect logs started.
NX> 900 Creating log archive.
NX> 900 Log archive successfully created.
NX> 900 Archive is: C:\ProgramData\\NoMachine\\var\\log\\archives\\NoMachine-log-2024.12.08-16.19.19.zip
NX> 900 Procedure to collect logs finished successfully.

Then, I tar up the Linux logs:

[root@T5500vmsrvr:/var/log:F41:]# cd; tar -cvp –exclude ‘cache*’ –exclude ‘images’ –exclude ‘temp’ -f /root/.nx; gzip -9 nxdir.tar
cd; tar -cvpf nxdir.tar –exclude ‘cache*’ –exclude ‘images’ –exclude ‘temp’ /root/.nx; gzip -9 nxdir.tar
tar: Removing leading `/’ from member names
/root/.nx/
/root/.nx/M-T5500vmsrvr.ScrtyHrdn.net-13001-671A55BC991435639E5F735F743B8C58/
/root/.nx/M-T5500vmsrvr.ScrtyHrdn.net-13001-671A55BC991435639E5F735F743B8C58/options
/root/.nx/M-T5500vmsrvr.ScrtyHrdn.net-13001-671A55BC991435639E5F735F743B8C58/authority
/root/.nx/M-T5500vmsrvr.ScrtyHrdn.net-13001-671A55BC991435639E5F735F743B8C58/session
/root/.nx/fonts/
/root/.nx/fonts/6a1c6e33-8a63-4e84-b677-5273b01a75b3-le64.cache-7
/root/.nx/fonts/c7d7503c-e60b-4163-9911-834e7d34447e-le64.cache-7
/root/.nx/fonts/a92f8521-d4b6-4e55-a46d-f458963b3708-le64.cache-7
/root/.nx/fonts/de88e1e0-aa22-4e9d-819a-a943e0005d8a-le64.cache-7
/root/.nx/fonts/73dfee93-2c7b-490d-a8f6-5156e626cb38-le64.cache-7
/root/.nx/fonts/cd1b2603-5711-4ce1-8c56-e7453f45346b-le64.cache-7
/root/.nx/fonts/af93e267-382a-4d9e-a404-d5d3ca1ccd59-le64.cache-7
/root/.nx/fonts/29a5e2a5-22ac-4b6c-94dc-f195bd53ad42-le64.cache-7
/root/.nx/fonts/68ceafee-4b6b-442f-b86a-a30b68d1bf76-le64.cache-7
/root/.nx/fonts/15ee7675-5429-40bd-bb09-12b80f02f043-le64.cache-7
/root/.nx/fonts/a7f0d55f-0bcc-4302-884a-69923836b260-le64.cache-7
/root/.nx/fonts/eb10d203-9150-4902-bd57-183c2938742b-le64.cache-7
/root/.nx/fonts/1b03c8fb-3bf3-4eab-8418-6089f0facae8-le64.cache-7
/root/.nx/fonts/bcd3232b-a35e-41c2-94af-504f33761bf1-le64.cache-7
/root/.nx/fonts/f1119854-c527-4f46-9900-7ca10ea12b91-le64.cache-7
/root/.nx/fonts/b3d36cb2-daf4-45aa-ad03-ce28172de07f-le64.cache-7
/root/.nx/fonts/CACHEDIR.TAG
/root/.nx/fonts/9e5298c2-0d52-451e-b039-8e0a99301de5-le64.cache-7
/root/.nx/fonts/2bd03298-6bc8-4656-943a-a24e06805e4f-le64.cache-7
/root/.nx/fonts/04dc6ac6-9131-40d9-9f90-0449701dfff8-le64.cache-7
/root/.nx/fonts/8b3f2c1b-f090-44aa-b450-fdc77867458a-le64.cache-7
/root/.nx/fonts/49b2f44a-f4ba-4574-9626-fb6db2ce91c0-le64.cache-7
/root/.nx/fonts/8d6dc8cb-96b4-470a-9426-feb22a5dcdda-le64.cache-7
/root/.nx/fonts/c0d38d07-812d-4c56-8968-74f8002f9efa-le64.cache-7
/root/.nx/fonts/0a2379e4-82d2-4f53-8129-5da8dd499282-le64.cache-7
/root/.nx/fonts/f3c6dd35-8cec-421a-bb9b-8977be10b792-le64.cache-7
/root/.nx/fonts/b636cd81-d1cb-4e31-8cf0-d746a5edb072-le64.cache-7
/root/.nx/fonts/73e065ce-6e81-4c27-8645-b4cf9a190a86-le64.cache-7
/root/.nx/fonts/2ff945f5-d130-41e5-a56e-2381ee663d81-le64.cache-7
/root/.nx/fonts/ebc28a55-1cb8-4531-8b35-18e5779a20ec-le64.cache-7
/root/.nx/fonts/fcaa62bd-8fbb-4ca5-b5c0-24fc61dd480b-le64.cache-7
/root/.nx/nxegl/
/root/.nx/nxegl/18137.log
/root/.nx/nxegl/2190.log
/root/.nx/M-T5500vmsrvr.ScrtyHrdn.net-13001-0FF4B3EC0044D5D50BD9419611BBA811/
/root/.nx/M-T5500vmsrvr.ScrtyHrdn.net-13001-0FF4B3EC0044D5D50BD9419611BBA811/options
/root/.nx/M-T5500vmsrvr.ScrtyHrdn.net-13001-0FF4B3EC0044D5D50BD9419611BBA811/authority
/root/.nx/M-T5500vmsrvr.ScrtyHrdn.net-13001-0FF4B3EC0044D5D50BD9419611BBA811/session
/root/.nx/nxdevice/
/root/.nx/nxdevice/D-1002-14E774225FC771EA1920F376BEC4224E/
/root/.nx/nxdevice/D-1002-14E774225FC771EA1920F376BEC4224E/cups/
/root/.nx/nxdevice/D-1001-5101A923F3831C1A400F2954F4581D46/
/root/.nx/nxdevice/D-1001-5101A923F3831C1A400F2954F4581D46/audio/
/root/.nx/nxdevice/D-1001-5101A923F3831C1A400F2954F4581D46/audio/emergency
/root/.nx/config/
/root/.nx/config/player.cfg

mv nxdir.tar.gz nxdir_20241208.tar.gz

md5sum Nomachine_IncidentReport_20241208.tar.gz
64844e44e331e58bd35c6d0c5df890dd Nomachine_IncidentReport_20241208.tar.gz

Lastly I’ve emailed nxdir_20241208.tar.gz to you, and referenced IDs 50858/50868.

I sincerely hope this helps.
Thank you.
R,
-Joe Wulf

[Joe_Wulf]

To have a chance of pace—I decided to attempt this with the latest CentOS 9 Stream and see what can be achieved.

I booted a USB already pre-staged with the Centos 9 Stream on it, and installed from it. Partitioning consisted of /biosboot at 2MiB, /boot at 3GiB, swap at 32GB (Physical RAM is 72GB) and / (root partition) got all the rest which is plenty. I selected the Minimal OS installation, as I will be putting KDE Plasma on it for the GUI desktop and window manager. Once the OS installation finished, I logged in on the console and performed ‘dnf -y update’ and then rebooted once that was completed.

I then ssh’d into this host from my own desktop to accomplish the bulk of the remaining steps.

I ‘generally’ followed these procedures to upgrade my system with KDE Plasma, and specifically just the listed numbered items here:
– https://www.redhat.com/en/blog/install-epel-linux
1. dnf -y config-manager –set-enabled crb
2. dnf -y install epel-release epel-next-release
# Seems ‘epel-next-release’ did not get installed here.

– https://docs.fedoraproject.org/en-US/epel/epel-about-next
1. dnf -y install epel-next-release

– https://www.server-world.info/en/note?os=CentOS_Stream_9&p=desktop&f=4
1. dnf –enablerepo=epel,epel-next,crb group -y install “KDE Plasma Workspaces”
# At this time, 1247 RPMs were installed, and took a hot-minute. YMMV!
a. Next I did:
1) touch /.autorelabel
2) reboot
3) Logged in again as root to continue this process
2. export XDG_SESSION_TYPE=”wayland exec dbus-run-session startplasma-wayland”
startx
# At this time the KDE graphical desktop GUI started. What’s noteworthy here:
a. It took 20’ish seconds for the KDE desktop to appear.
b. I hit ‘X’ to close out of the KDE-Desktop window, which in this case is superfluous.
c. Several pop-up windows appeared complaining that KDE-Connect had an error.
This can be somewhat ‘normal’ on hardware that isn’t connected to WIFI.
One of the first things I do at this point is completely disable KDE-Connect.
# dnf -y remove kde-connect kde-connectd kde-connect-libs kde-connect-nautilus –noautoremove
d. At this time I fix a couple things, while at the console, to prevent other problems from occurring:
1) I start “System Settings” from the icon on the KDE Task Manager bar at the bottom of the window.
2) I select “Power Management” and then ‘uncheck’ the boxes for ‘Screen Energy Saving’ and ‘Suspend Session’.
3) Next I hit ‘Apply’ at the bottom right corner of the window.
3. I followed the link for ‘Change setting like here’ at this point to establish a permanent graphical login.
Link is: https://www.server-world.info/en/note?os=CentOS_Stream_9&p=runlevel
1. systemctl get-default # it reported:
multi-user.target

ls -l /etc/systemd/system/default.target # it reported this:
lrwxrwxrwx. 1 root root 41 Dec 10 19:09 /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target

ll /lib/systemd/system/multi-user.target # it reported this:
-rw-r–r–. 1 root root 540 Oct 31 2022 /lib/systemd/system/multi-user.target

2. systemctl set-default graphical.target # it reported this:
Removed “/etc/systemd/system/default.target”.
Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/graphical.target.

systemctl get-default # it reported this:
graphical.target

ll /etc/systemd/system/default.target # it reported this:
lrwxrwxrwx. 1 root root 40 Dec 10 20:51 /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target

At this time, I again touched /.autorelabel and rebooted:
touch /.autorelabel; reboot

Once the system is back up, I again login as root, open a terminal and enter: dnf -y install firefox.

Once that is installed, I open firefox and browse to ‘https://www.nomachine.com’ and download the latest version of nomachine for Linux, the one for Linux RPM x86_64, version 8.14.2_1. I also then verify the md5sum against what the download page says it should be, and it matches.
-rw——-. 1 root root 55580022 Dec 10 21:14 nomachine_8.14.2_1_x86_64.rpm

md5sum nomachine_8.14.2_1_x86_64.rpm
d096cbdb388fa717e13e3c5d5f2bded9 nomachine_8.14.2_1_x86_64.rpm

Next I install it:
dnf -y install nomachine_8.14.2_1_x86_64.rpm
Last metadata expiration check: 1:20:21 ago on Tue 10 Dec 2024 07:57:49 PM EST.
Dependencies resolved.
============================================================================================================================================================
Package Architecture Version Repository Size
============================================================================================================================================================
Installing:
nomachine x86_64 8.14.2-1 @commandline 53 M

Transaction Summary
============================================================================================================================================================
Install 1 Package

Total size: 53 M
Installed size: 56 M
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Running scriptlet: nomachine-8.14.2-1.x86_64 1/1
Installing : nomachine-8.14.2-1.x86_64 1/1
Running scriptlet: nomachine-8.14.2-1.x86_64 1/1
NX> 700 Starting installation at: Tue, 10 Dec 2024 21:18:20.
NX> 700 Using installation profile: Red Hat.
NX> 700 Installation log is: /usr/NX/var/log/nxinstall.log.
NX> 700 Installing nxrunner version: 8.14.2.
NX> 700 Installing nxplayer version: 8.14.2.
NX> 700 Installing nxnode version: 8.14.2.
NX> 700 Installing nxserver version: 8.14.2.
NX> 700 Installation completed at: Tue, 10 Dec 2024 21:19:00.
NX> 700 NoMachine was configured to run the following services:
NX> 700 NX service on port: 4000

Verifying : nomachine-8.14.2-1.x86_64 1/1

Installed:
nomachine-8.14.2-1.x86_64

Complete!

Next I again touched /.autorelabel and rebooted:
touch /.autorelabel; reboot

Once it comes back up, I login as root and verify the nomachine server is up and running via the desktop interface.

Next, I use Nomachine from my Win11 desktop attempting to connect to this newly built computer… and it works.
The remote desktop comes up right away.

I sincerely hope this helps.
Thank you.
R,
-Joe Wulf

[Joe_Wulf]

For what it is worth, I could revert back to the Fedora 41 KDE spin, and document all the exact steps I take and provide that input here, and a new/fresh set of logs (I had previously emailed the logs based on your request above).

Thank you.
R,
-Joe Wulf

[Britgirl]

Hi, thanks for the additional information. We confirm what we said before. Use this link to monitor the bugfix, https://kb.nomachine.com/TR05V11141. For the time being use x.org rather than Wayland.

[Author]

Posts