Arch Linux User Repository

Since nomachine 7.1.3-2 the default behavior of the package is StartNXDaemon Manual and FirewallConfiguration 0 on a new installation, if you want to change this, you need to modify PKGBUILD build options with your desire behavior:

BUILD OPTIONS

Set to y to enable nomachine service autostart

_autoservice=n

Set to y to enable firewall autorules

_autofirewall=n

END BUILD OPTIONS

There are quite a few things that probably should be looked into in this package.

1. The postinst should be created in an appropriate environment before the package is created, not after it is created. If nxserver can't handle that, the postinst steps should be performed manually.
2. The postinst should not start or enable nxserver, this should be left up to the user. Starting and enabling services isn't an appropriate thing to do in a postinst.
3. Packaged files are removed after packaging, which means pacman -Qk fails.
4. The installer isn't given the appropriate XDG environment, so it creates a root directory, /applications-merged:

% ls -l /applications-merged
total 4
-rw-r--r-- 1 root root 593 Apr 13 14:18 NoMachine-dir.menu

Just a FYI. If your session terminates/crashes instead of locking it might be caused by this

https://knowledgebase.nomachine.com/TR02T10468

I had screen blacking enabled in nxserver settings and currently it seems to crash Xorg on session switch/lock.

% sudo pacman -Qk nomachine
warning: nomachine: /usr/NX/etc/NX/ (No such file or directory)
warning: nomachine: /usr/NX/etc/NX/server/ (No such file or directory)
warning: nomachine: /usr/NX/etc/NX/server/localhost/ (No such file or directory)
warning: nomachine: /usr/NX/etc/NX/server/localhost/server.cfg.sample (No such file or directory)
warning: nomachine: /usr/NX/etc/NX/server/packages/ (No such file or directory)
warning: nomachine: /usr/NX/etc/NX/server/packages/nxclient.tar.gz (No such file or directory)
warning: nomachine: /usr/NX/etc/NX/server/packages/nxnode.tar.gz (No such file or directory)
warning: nomachine: /usr/NX/etc/NX/server/packages/nxplayer.tar.gz (No such file or directory)
warning: nomachine: /usr/NX/etc/NX/server/packages/nxserver.tar.gz (No such file or directory)
warning: nomachine: /usr/NX/nxserver (No such file or directory)
nomachine: 13 total files, 10 missing files

Hi! If the "nxserver" does not listen to port 4000, then edit file "/usr/NX/etc/server.cfg", set "StartNXDaemon" to "Automatic", set "EnableFirewallConfiguration" to "1", then restart "nxserver". The problem should be fixed then.

Disregard. I had set the service to manual start (within the GUI settings) forever ago, uninstalled, and it remembered upon reinstalling.

@galvez_65 Still nothing relating to 4000 :(

$ sudo netstat -tulpn | grep nx
tcp        0      0 127.0.0.1:7001          0.0.0.0:*               LISTEN      2636/nxnode.bin     
tcp        0      0 127.0.0.1:22171         0.0.0.0:*               LISTEN      2582/nxserver.bin   
tcp        0      0 127.0.0.1:12001         0.0.0.0:*               LISTEN      2636/nxnode.bin     
tcp        0      0 127.0.0.1:25001         0.0.0.0:*               LISTEN      2658/nxclient.bin   
tcp6       0      0 ::1:7001                :::*                    LISTEN      2636/nxnode.bin     
udp     8448      0 192.168.1.172:5353      0.0.0.0:*                           2582/nxserver.bin   
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           2582/nxserver.bin   
udp     1280      0 0.0.0.0:46956           0.0.0.0:*                           2631/nxexec   

@parkerlreed I ran sudo netstat -tulpn to list it. Interesting when I run sudo netstat -atu (which is supposed to list open ports) it's not listed

@galvez_65 that's the thing. That's all my open ports related to nx. Nothing else shows up.

nxsever.service claims it's running fine and no errors/warnings.

@parkerlreed look for nxd, on my machine that's how it's listed

Did something change? nxserver seems to no longer be listening on 4000.

nxserver. 2003     nx   20u  IPv4  39800      0t0  TCP 127.0.0.1:21277 (LISTEN)
nxnode.bi 2056 parker   14u  IPv4  38680      0t0  TCP 127.0.0.1:12001 (LISTEN)
nxnode.bi 2056 parker   16u  IPv6  39865      0t0  TCP [::1]:7001 (LISTEN)
nxnode.bi 2056 parker   17u  IPv4  39866      0t0  TCP 127.0.0.1:7001 (LISTEN)
nxclient. 2078 parker    6u  IPv4  39876      0t0  TCP 127.0.0.1:25001 (LISTEN)

I can't find any notes about a new port. The main nxserver seems to randomize.

I searched and didn't see. Is anyone else getting the perl library error. I find it strange since the file is package with NX. /usr/NX/bin/nxserver.bin: error while loading shared libraries: libperl.so: cannot open shared object file: No such file or directory

EDIT:: Nevermind. Everything seems now to be working despite the missing dependencies.

@blackhole, the popup can be turned off in the settings.

In the software world 2 updates late = getting serious

This is annoying because of nomachine popup at each boot asking to update...

"Seriously" out of date is a bit harsh, 7.5.2 just came out last week and 7.6.2 just came out yesterday.

@runnytu

Seriously out of date. 2 updates were released since.. Latest being 7.6.2. Kindly update...

Thanks ;)

4.6.2_4 is out! Please update

updating nomachine to 7.5.2:

diff --git a/PKGBUILD b/PKGBUILD
index f17ff7d..9071874 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -11,8 +11,8 @@ _autofirewall=n
 ### END BUILD OPTIONS

 pkgname=nomachine
-pkgver=7.4.1
-_pkgvermain=7.4
+pkgver=7.5.2
+_pkgvermain=7.5
 _pkgrel_i686=1
 _pkgrel_x86_64=1
 _pkgrel_armv6h=1
@@ -30,13 +30,13 @@ options=('!strip')
 conflicts=('nxmanager' 'nxwebplayer' 'nxserver' 'nxnode' 'nxclient')
 depends=('bash' 'openssh' 'nawk')
 optdepends=('xorg-xauth: allows logging into a headless machine')
-sha512sums_x86_64=('3e72109be04f594998ce750defd926d34d38dd1309e6953f36348d6a97479e27173f1aa1e75d7dcf95b157e16a0349e436c53006f2a240b3134ee83c89e487ed')
-sha512sums_i686=('497d0c1a4cfe822db07bbc008e64688be792e1543250db0384b55ba5cb783c14495014fc8150401d822d7d3c54981341751761b2c413d441bdc1f8047dd81026')
-sha512sums_armv6h=('b4d8aba4fa15d9e34dfaf79d72873e307e5acf8bef774b3a2c01f5d1fd380de17e0d811ff24427fb808104366ba7b92f5c798f8d6eaecb9a8e27c221d4dc6e42')
-sha512sums_armv7h=('c17858e079ff8b403c1f66704c4f234db7d7519522f0dc728a5a06a34e89ad34d9fe11c8d87a83bd7a8a294a5606da78366b222ce785fb1892f7207db0d0309c')
-sha512sums_armv8h=('ed8626ee4f9b7da650ee9d08847ff6abb23130717318556e1c7930fbc80aac80d163fa56c8f04732740f1137c9439d5d853827621b67c99d0f66f44527a67f00')
-sha512sums_aarch64=('ed8626ee4f9b7da650ee9d08847ff6abb23130717318556e1c7930fbc80aac80d163fa56c8f04732740f1137c9439d5d853827621b67c99d0f66f44527a67f00')
-sha512sums_pentium4=('497d0c1a4cfe822db07bbc008e64688be792e1543250db0384b55ba5cb783c14495014fc8150401d822d7d3c54981341751761b2c413d441bdc1f8047dd81026')
+md5sums_x86_64=('a194542d0a41628f85df0786e07f9543')
+md5sums_i686=('5cbd2ad4c493a227db3e0b65937216de')
+md5sums_armv6h=('de7abbf7817d7987e28f29e6e04e8a67')
+md5sums_armv7h=('c77416f9d11625717ec1f62e43ab2a19')
+md5sums_armv8h=('d2335fb175b664812f33c26b54e1abc3')
+md5sums_aarch64=('d2335fb175b664812f33c26b54e1abc3')
+md5sums_pentium4=('5cbd2ad4c493a227db3e0b65937216de')
 source_x86_64=("http://download.nomachine.com/download/${_pkgvermain}/Linux/${pkgname}_${pkgver}_${_pkgrel_x86_64}_x86_64.tar.gz")
 source_i686=("http://download.nomachine.com/download/${_pkgvermain}/Linux/${pkgname}_${pkgver}_${_pkgrel_i686}_i686.tar.gz")
 source_armv6h=("http://download.nomachine.com/download/${_pkgvermain}/Raspberry/${pkgname}_${pkgver}_${_pkgrel_armv6h}_armv6hl.tar.gz")

sha512 to md5 checksum is a downgrade, but that is what is provided in the download page

Since nomachine 7.1.3-2 the default behavior of the package is StartNXDaemon Manual and FirewallConfiguration 0 on a new installation, if you want to change this, you need to modify PKGBUILD build options with your desire behavior:

BUILD OPTIONS

Set to y to enable nomachine service autostart

_autoservice=n

Set to y to enable firewall autorules

_autofirewall=n

END BUILD OPTIONS

@cheezsteak, It's working ok, nxserver.service is always starting, and you see the icon on your desktop, but if you look in server status/ports you'll see the service in port 4000 are stopped and "Start the automatic service at startup" checkbox is disabled, even if you search devices in your LAN can see the PC but if you attempt to connect it will be rejected because is no NX service running.

I updated the package with update script when it's updated, and with disable autostart by default, I'll pin a warning and info for changing this behavior.

@galvez_65 sorry I was looking at the server.cfg.sample file not the server-fedora.cfg.sample file in nxserver.tar.gz. The config file is being edited correctly and is installed on my system with both StartNXDaemon Manual and EnableFirewallConfirguration 0 set.

However, the nxserver.service is still running and enabled after installing the package. I'm suspecting it's a problem with the upstream script nxserver not repsecting it's own configuration rules. If someone else can confirm this is true, I'd just give up on offering PKGBUILD options and just have the package scream "REMOTE DESKTOP ACCESS IS ENABLED FOR YOUR MACHINE" as loud as possible.

@cheezsteak not sure I follow, I just checked the and the sample config file is present and contains the comments listed in the PKGBUILD that sed is looking for. I've not recently tested that changing the defaults works so I can't comment on that yet

Th upstream package stopped providing a full config file with commentted out defaults to just one option and copyright. The sed commands in the PKGBUILD were looking for the comments to replace them but not making any changes. The PKGBUILD should now use the commands below instead of the sed commands.

echo "EnableFirewallConfiguration 0" >> NX/etc/server-fedora.cfg.sample
echo "StartNXDaemon Manual" >> NX/etc/server-fedora.cfg.sample

The flags not working is definitely an issue that should be addressed. I wonder what changed in the config files ?

@galvez_65 a sticky would be better than nothing but I just don't understand the merit defaulting to enabling the service over not. Saying "users should be reviewing the PKGBUILD" doesn't justify being insecure by default. If the maintainer were to switch they could still say "users should be reviewing the PKGBUILD" if any users complain about the service not being automatically.

Also the flags don't seem to work. I changed them to n as instructed, stopped and disabled nxserver.service , uninstalled nomachine, and reinstalled with makepkg -si. The warning message didn't print but nxserver was started after the install finished.

Looking into server.cfg.sample, there's only ServerRoot = "/usr/NX" and no commented out configurations. So these commands from the PKGBUILD make no changes to the package.

sed -i 's/#EnableFirewallConfiguration 1/EnableFirewallConfiguration 0/' NX/etc/server-fedora.cfg.sample
sed -i 's/#StartNXDaemon Automatic/StartNXDaemon Manual/' NX/etc/server-fedora.cfg.sample

@cheezsteak While I won't argue that this package breaks with Arch norms, this is the AUR and users should be reviewing the PKGBUILD along with .install files to understand what they are doing. If this package were in the main repos, then yes what you describe would be the norm, but here I'm just thankful that someone put this together and is maintaining it. The same thing recently happened with tailscale, in the AUR it enabled the service automatically, once it was moved to the main redo that behavior was changed. Perhaps a sticky note should be added here to indicate that the default behavior is to enable by default and can be changed in the PKGBUILD file?

I would like to relitigate the default behavoir of enabling nxserver and opening the ports by default. While I appreciate the maintiner providing configuration variables and warning notices, those settings ought be secure by default.

It's particularly egregious because this package provides both the server and the client software. So users installing the package on their home machine to remote into work could inadvertently expose remote desktop access to their home machine.

I understand the upstream package is insecure by default but that doesn't justify this package continuing that irresponsibility. I'm also not entirely sure that changing the default behavior will break anyone's existing setups. New installers must enable the service and open the ports, but that's standard behavior for arch packages and can be addressed with a pinned comment and/or different warning message. Users with this package already installed, who want the service enabled, will already have it enabled.

This may be caused by not updating correctly. I edited nomachine.install removing the pre_upgrade stanza and changed the post_upgrade stanza to be:

post_upgrade() {
    echo "Running NX update script..."
    /usr/NX/nxserver --update fedora
}

which seems to fix the issue. I'm not sure why --uninstall and --install are used rather than --update so there may be other unintended consequences, but unless there is a reason I would suggest or at least explore changing the upgrade procedure.

With the last versions nomachine will start correctly only if removed completely first explicitly

@Groumpf I can confirm I had to do the same thing to attach to my wayland session on gnome as well

For people upgrading to 7.1.3, I had to do this to recover the ability to attach to a running X session.

sudo /etc/NX/nxserver --addtoredis
sudo systemctl restart nxserver

Not sure if it's something that should make it into the PKGBUILD or if it's a hiccup with upgrading.

Is anybody else having trouble getting the nxserver to start? I'm getting errors that there is no valid subscription files.

SOLVED removing completely nomachine, checking that all files was removed, deleting yay cache and reinstalling

With last version I cannot connect any more to a lxqt desktop.

The package has been upgraded to 7.0.211 and the download links don't seem to work any more.

Package seems to miss the sha keys (installed via yay)

==> Making package: nomachine 7.0-1 (Wed 23 Dec 2020 04:20:50 PM CET) ==> Retrieving sources... -> Found nomachine_7.0.209_9_x86_64.tar.gz ==> Validating source_x86_64 files with sha512sums... nomachine_7.0.209_9_x86_64.tar.gz ... FAILED ==> ERROR: One or more files did not pass the validity check! error downloading sources: nomachine

Right mouse click on tray icon does not show saved connections any more. I need to restore main window first.

Anyone has problems with starting the nx node in the latest version? I've tested on cinnamon and gnome, nxserver.service can't start the node in either DE, and the server hangs in place.

On KDE 5.20.1 and NoMachine has been failing to work for me consistently for the past one month or so. Running it from the command line makes it immediately segfault. Removing the directory ~/.nx makes Nomachine take longer to segfault, but it still segfaults. Interestingly enough, on another Arch system that runs Awesome which is up-to-date, NoMachine starts just fine. This is probably a NoMachine problem, so I should probably ask elsewhere, but is anyone else having the same issue?

Update: my issue seems resolved with 3.38.2, not sure what the issue was but it just started working again after the recent updates

Any one having issues with nomachine connecting to the display with gnome and wayland? Since the gnome update to 3.38 nomachine has not worked for me with wayland.

@runnytu, enjoy your holiday. That's more important in these days... and in general ;-) Cheers

Updated PKGBUILD and uploaded it to my github.

please update this AUR repo! https://github.com/Taekus/nomachine

I'm on holidays without a pc access until 13/10/2020, until then no update availability.

When this will be updated?

Confirmed 6.12.3_5 ARMv7l working flawlessly on RPI4, 5.4.69-1-ARCH.

regards,

Hi runnytu, could be that something is wrong with nomachine_6.11.2_1_x86_64.tar.gz. My systems tells me that the sha512sums checksum is wrong.

@lateparty

Thank you very much. I will try it.

Looks like nomachine dont store old versions of their software (there is an official forum post of theirs that backs this up)

I manually edited the PKGINFO file to point to the latest version and release, and I did the sha512sum and it installed fine. Working fine too. Last version was broken.

NoMachine is failing to check nomachine_6.11.2_1_x86_64.tar.gz checksum. I don't known if this is the correct site to inform about this.

Thanks

@hcjl, @heavysink

yeah, I received the email too. Ye Lo and Behold !... this took upstream a "mere" three and a half months to solve. It seems that there are not many users out there using nomachine for ARMv7, since they haven't exactly rushed this fix.

But well, that's spilled milk under the bridge. What's important is that it seems we're back on track again and we'll be able to continue using nomachine.

@heavysink, @Le_Birlante, just received this from NoMachine. Seems like there is hope ;-)

TROUBLE REPORT: Updates to TR06R09747 on 2020-09-29 Cannot run NoMachine sessions on ARMv7 devices with kernel 5.4.42 or later Reason was: TR solved in version 6.12.3.

@heavysink, @Le_Birlante, for me the problem still persists in 6.11.2 with the armv7h version. I also registered to get notifications about the mentioned bug, but never got notified ;-)

@Le_Birlante

I have already reported this issue at June and there is a ticket about it. Now the ticket is still open. Could you check if 6.11.2 still have the pow_infinite problem?

https://www.nomachine.com/TR06R09747

@jichu4n, Done.

Hi runnytu!

Would it be possible to also add pentium4 as a supported architecture? This architecture is used by Arch Linux 32 for Pentium 4 and later 32-bit Intel CPUs, and so can just use the same NoMachine binaries as i686.

Here's a patch I tested on Arch Linux 32: https://gist.github.com/jichu4n/75bd2ad2a485cf1f4785908a1772a3b6

Thanks in advance!

I have a problem in which, under the bspwm window manager, all of the Unity and XFCE specific .desktop files are still shown. I don't know if this has something to do with my menu application (rofi) or if the configuration inside the .desktop is invalid.

Is it possible to install only nxserver and necessary daemons on my remote machine I want to access into? I don't need the client there since I'm gonna use from the client to access the remote machine.

@LoopBack It's documented in the PKGBUILD file, you need to edit it to turn that off.

Recently with every update , the service is started and enabled at startup. I keep having to stop it and disable autostart with PC.

How do I stop this insecure behavior?

Thank you!

@Le_Birlante, thanks for addressing this to NoMachine. I am also waiting for the fix.

$pkgver needs to be updated to 6.11.2. 6.10.12 is producing a webpage AFAICT.

You can work around the out-of-date package by downloading http://download.nomachine.com/download/6.11/Linux/nomachine_6.11.2_1_x86_64.tar.gz (or as appropriate for your $arch), running sha512sum on that file, updating the $pkgver and appropriate sha512sum_$arch line in the pkgbuild, then running makepkg -si.

checksums failing for anyone else?

I don't know if this is a joke or not. Just go search through settings, man.

Does anyone know how to configure this to use a different port than the default 4000?

Anyone having issues connecting to a server running GDM? with GDM 3.36 if I try to remote into a machine which I am not already logged into I get a white screen. If I am physically logged in I can remote in without issue. Rolling GDM back to 3.34 resolved the issue for me.

I am getting:

==> Validating source_x86_64 files with sha512sums... nomachine_6.9.2_1_x86_64.tar.gz ... FAILED

@Le_Birlante, I have exactly the same problem (RPI4, Archlinux ARM, XFCE). So unfortunately just a confirmation, not a solution :-(

Hi there,

I think this is upstream territory, but anyway, here it goes in case someone here could confirm this one.

Scenario : Raspberry PI 4 running Arch Linux for ARM, KDE+Plasma, NoMachine 6.9.2 package. Eeverything runs flawlessly for weeks, not even a single problem.

The problem: latest arch/arm kernel updates (over the past week there have been two linux-raspberrypi4 updates, latest is 4.5.35-1) seem to have broken NoMachine. It will simply refuse to start.

If you go to nxserver.log, you can see NX is trying to get an instance up and running, but to no avail:

2020-05-04 22:58:09 254.556 21823 NXSERVER WARNING! Process '/usr/NX/bin/nxexec --node --user xxx --priority realtime --mode 0 --pid 16' with pid '23454/23454' finished with exit code 127 after 1,453 seconds. 2020-05-04 22:58:09 255.262 21823 NXSERVER WARNING! FBA3ED947BAD40D54C4D64B030FDC4BA nxnode died with exit code 127.

2020-05-04 22:58:09 372.189 21823 NXSERVER WARNING! Session FBA3ED947BAD40D54C4D64B030FDC4BA crashed on display 0.

2020-05-04 22:58:10 916.236 21823 NXSERVER WARNING! Process '/usr/NX/bin/nxexec --node --user xxx --priority realtime --mode 0 --pid 14' with pid '23601/23601' finished with exit code 127 after 1,528 seconds.

2020-05-04 22:58:10 916.821 21823 NXSERVER WARNING! AE162AD84888CEDA4DC8F1DB456033EB nxnode died with exit code 127.

2020-05-04 22:58:11 007.321 21823 NXSERVER WARNING! Session AE162AD84888CEDA4DC8F1DB456033EB crashed on display 0.

I inspected one of those crashed sessions ( /usr/NX/var/log/node/F-C-session_hex_code_here/session ) and this is the only suspect I could see :

Session: Starting session at Mon May 4 22:58:16 2020. Info: Agent running with pid 24113. Info: Slave server running with pid 24186. Info: Display running with pid 24187. Info: Listening to slave connections on port 12003. Info: Audio client started with pid 24195. Info: Audio server started with pid 24194. Info: Display server started with pid 24196.

=======>>>>>> /usr/NX/bin/nxnode.bin: symbol lookup error: /usr/NX/lib/libnxdifb.so: undefined symbol: __pow_finite <<<<<<=====

Thing is, I am not sure whether the 'pow_finite' symbol failure was already present as a simple warning before the rpi4 kernel update, or whether it's indeed the culprit of NX crashing. Turns out, I had never before had to look at these logs, since everything was working ok, so perhaps the pow_finite thingie was always there and it has nothing to do with the current problem. Go figure...

Long story short: Nomachine for RPI4 is broken since two kernel updates ago (more or less a week ago, talking in days). If you use NX with your PI4 like me, try not to upgrade the kernel.

regards !

@smekkleysa, both are in the base package, that is the minimum you should have installed, and never are in the depends part of an aur package.

For super minimal setup, tar and hostname command are needed.

@runnytu Awesome, thank you!!

@jichu4n, done with the same version to avoid other users to upgrade.

First, thanks a lot for making & maintaining this package! I use it all the time on x86_64 and it works great.

However, would it be possible to add aarch64 as a supported architecture? I'm not sure what the difference between the two are, but Manjaro ARM uses aarch64 instead of armv8h, and trying to install this package as-is fails. However, just adding a few lines into the PKGBUILD to make aarch64 behave the same as armv8h seems to work fine for me.

Here's a patch I tested on Manjaro ARM on the Pinebook Pro: https://gist.github.com/jichu4n/535876118f9935ad658e3113c745caec

Thanks!

For some reason it installs and fails when starting "nxserver" systemctl service.

And for some reason this seems to fix that? I'm not sure if this is a solution or not in those cases. sudo mv /etc/NX/nxserver /etc/NX/nxserver.bak && sudo ln -s /usr/NX/bin/nxserver /etc/NX/nxserver

to use with gnome and wayland I had to follow these instructions: https://www.nomachine.com/TR10Q09420

Excelent package

@blackhole, Server preferences/Updates, uncheck Automatically check for updates checkbox and apply.

Is possible to get rid of nomachine update message?

@liberodark, it's already supported as armv8h.

Please use that for support RPI4

https://paste.yunohost.org/sowixolomo.bash

edit: a word of caution

The patch works perfectly, but only when a kde/plasma session has been started.

i.e., sddm , for example, isn't available for NM. Not until you manually log on and spawn a Kde/plasma session.

regards,

Damn... it worked like a charm.

runnytu: thank you a lot.

regards,

@jnko, @Le_Birlante & all plasma users, Added the fix for Plasma 5.17 on X86_64 with the same version to avoid non X86_64/plasma users to reinstall, and don't use "development" packages.

Here's the link for the patched package fixing the KDE 5.17 issue. I can validate that it's working fine. https://download.nomachine.com/44bef5297fe9efb3430b9fd47ad18b01/downloads/temporary/forum/nomachine_6.8.1_32_x86_64.tar.gz

https://download.nomachine.com/44bef5297fe9efb3430b9fd47ad18b01/downloads/temporary/forum/nomachine_6.8.1_32_x86_64.rpm

Update: nomachine devs have opened a thread here <https://forums.nomachine.com/topic/nx-wont-work-with-recent-kde-5-17> where they're discussing the kde5.17+NM problem.

They have come up with a patch which seems to fix the problem, and they're offering it via email to the users who are on that thread.

runnytu, do you think you could grab that patch and integrate it in your NoMachine arch package ? That would save the day for a few of us xD

regards,

@jnko & @galvez_65, added nawk as a dependency.

I second adding nawk as a dependency

With last plasma update nomachine tray icon missing. Any idea?

It's far worse than that. Latest plasma update (5.17) has changed the usual KDE plasma startup procedure, from /usr/bin/startkde to /usr/bin/startplasma-x11.

This has broken nomachine (at least, if you were using it with KDE plasma, which is my case) since NM will try to start a session by calling /usr/bin/startkde, which in turn will fail, leaving you without being able to connect to your remote host via nomachine.

I've tried modifying nomachine's node.cfg (namely, DefaultDesktopCommand and CommandStartKDE directives) to point to /usr/bin/startplasma-x11 instead of /usr/bin/startkde, but to no avail.

It should be noted, though, that startkde was a shell script, while startplasma-x11 is a full-fledged ELF binary, so I take it for granted that such a simple fix as changing "startkde" for "startplasma-x11" in node.cfg wasn't going to work...

As for now, I do not know what else to do. KDE-plasma + NoMachine seems to be plain broken, and I think this should be fixed upstream, but right now I've run out of ideas.

Advice: do not upgrade to plasma 5.17 if you are using nomachine and you depend on it for accessing your servers !

regards,

Please add "extra/nawk" as dependency, otherwise every call of nxserver or tools will produce "/usr/NX/bin/nxserver --version awk: cmd. line:1: warning: regexp escape sequence `\"' is not a known regexp operator "

With last plasma update nomachine tray icon missing. Any idea?

Open the PKGBUILD and change the checksum to "SKIP" to bypass checksum

Any solutions to checksum fail?

The link <http://download.nomachine.com/download/6.6/Linux/nomachine_6.6.8_5_x86_64.tar.gz> redirects to <https://www.nomachine.com/download> causing sha512sum check to fail.

@greyltc, optdepends added with the same version to avoid users to reinstall, the other question is the default config on nomachine, and I don't want to change that, for that reason, I created these options to anyone can disable if he/she wants, but keeping the original behavior of the package for default.

Can we please have _autofirewall=y and _autoservice=y both set to n by default? Having the PKGBUILD do these things by default is very unexpected and potentially dangerous.

Also please add xorg-xauth to optdepends that allows one to log into a headless machine (with a supported window manager).

This is generally considered bad practice but it will make nxserver.service run

ln -s /usr/NX/lib/libavcodec.so /usr/lib/libavcodec.so.57 ln -s /usr/NX/lib/libavutil.so /usr/lib/libavutil.so.55

FYI: This comes with nxplayer (/usr/NX/bin/nxplayer) which can be used to connect to nxservers. For some reason arch wiki on nx does not mention this and only says about nxclient.

The latest NoMachine isn't compatible with the version of ffmpeg in the main repos. As a result, h264 isn't working at all. I tested a couple of the ffmpeg-compat packages with no success. Any ideas?

update* Cool, installing the compat package and symlinking '/usr/lib/libavcodec.so.57 > /usr/NX/lib/libavcodec.so' and '/usr/lib/libavutil.so.55 > /usr/NX/lib/libavutil.so' worked like a charm.

@mrfabjr, try again, it was outdated.

Getting the following errors:

curl: (22) The requested URL returned error: 404 Not Found

==> ERROR: Failure while downloading http://download.nomachine.com/download/6.1/Linux/nomachine_6.1.6_9_x86_64.tar.gz Aborting... ==> ERROR: Makepkg was unable to build nomachine.

Tried installing using:

pamac-manager

$ yaourt -S nomachine

I've done the following:

Updated system

Refreshed Databases

no luck.

Thanks

@meriops, fixed.

makepkg complains that the "conflict" entry contains illegal characters. This entry should be: conflicts=('nxmanager' 'nxwebplayer' 'nxserver' 'nxnode' 'nxclient') rather than the current:<br> conflicts=('nxmanager nxwebplayer nxserver nxnode nxclient')

Hi, is there a way to fix this problem permanently please? https://bbs.archlinux.org/viewtopic.php?pid=1727671#p1727671

Ahh cheers, missed that.

@parkerlreed, there is an option in the PKGBUILD to disable nomachine service autostart, you only need to change it to no, also there is a banner during installation informing you "No Changes To Automatic Service Start And Firewall Automatic Rules" if you don't touch the variable.

@brittyazel, fixed.

The post install command enables the service automatically...

Might want to make a note of this in the post install script in case the user installing it only wants to use it as a client.

For anyone having issues with NoMachine not using h.264, it's an issue with the libstdc++.so.6 included in /usr/NX/lib. Just rename this to libstdc++.so.6.old or something, and restart NoMachine and h.264 should work (granted you need to have everything else set up correctly too). This error is common when a software program comes bundled with a verseion of libstdc++ that is out of date compared to the one in Archlinux. (looking at you MATLAB and Steam)

@runnytu, perhaps it might be usefull to add a command to the build script that renames this file so that people won't run into this issue.

thanks huitseeker

Please consider this diff for an update: https://github.com/huitseeker/nomachine/commit/dfedac0a363b117c4c4a3af9af397c20bc98b2ea

Somehow after the installation I ended up with bad licenses and service wouldn't start, had to get the *.lic files from a proper 6.0.66 installation.

Anyone know how to fix the typing slowness when connected to another linux machine? Really it is not the typing that is slow, but the refresh of little areas of the screen. Sometime I see the typed letter only if I drag the window a little. Very strange...

Here's a patch to enable x264 for a much better experience over the default VP8: https://pastebin.com/uGN7TbA2