The NX Client from NoMachine is a client that provides desktop connections to Linux hosts from Windows clients in a good way but it has always had a nasty bug that affects user data directories.
Some of the data folders that are created in the user profile by the client during connections are given totally weird NTFS ACL’s. These folders are not inheriting the permissions as they should. Instead, they are created with full permissions for the user and read attributes/read permissions permission for everyone but no extra permissions for SYSTEM or Administrators as normally is the case.
There are probably some other incorrect flags set in the ACL too because these folders are listed as shared folders in Explorer in Vista and newer operating systems.
The folders I’m talking about are %userprofile%\.nx\cache-unix-gnome, %userprofile%\.nx\cache-unix-kde and similar as well as %userprofile%\.ssh.
The result of these permissions is that the user profiles look like this on a shared system:
To add to this weirdness, probably as a result of lazy Windows porting, the locations of the user folders in the client are all pretty bad.
There are two folders created directly in the %userprofile% directory: .nx and .ssh. The ssh folder contains ssh keys and stuff while the nx folder contains everything else.
This means that both folders are roaming if you’re use roaming profiles. It’s nice that the ssh folder is roaming and it’s nice that the configuration files under the nx folder are roaming too but the cache files shouldn’t be part of a roaming profile. They are just too large and unnecessary to move between systems.
A better design would have been to place the ssh stuff under %appdata%\Roaming\NX Client\.ssh and the configuration files under %appdata%\Roaming\NX Client\config
Everything else (cache and logs) should be placed under %appdata%\Local\NX Client.
I guess asking for redesign is to ask too much from a company that don’t even care to fix their known bugs.
At the time of writing, the latest available NX client version was 3.4.0-10 but the permission problems exists in all 3.3 and 3.4 versions of the NX client that I’ve tried and it seems to be related to Cygwin rather than the NX client itself.
I’ve seen other posts about bad NTFS permissions caused by older versions of Cygwin and there have been different options available with Cygwin to control folder permission mode on the Cygdrive but these are not possible to control by the user in the case of NX client.
Newer versions of Cygwin have a changed default behavior so while I’m waiting for NoMachine to start solving bugs, I’ve solved my problems by upgrading some of the Cygwin DLLs distributed with the NX client to newer versions. I haven’t seen any problems caused by this but of course it isn’t supported in any way.
The DLL that needs to be updated is cygwin1.dll placed in the bin directory in the NX installation directory.
I’ve just downloaded the latest version of cygwin1.dll from the cygwin package.
The newer cygwin1.dll have some added dependencies so you’ll also need cyggcc_s-1.dll from the libgcc1 package and cygz.dll from the zlib0 package.
The DLL versions I’ve tried are cygwin1.dll v1.7.7, cyggcc_s-1.dll v4.5.0 and cygz.dll v1.2.5 but I bet most of the newer versions will work.
Replacing the DLL-files doesn’t take care of permissions on folders that have already been created with weird permissions. It only prevents future folders from being created with the wrong permissions. You will have to repair the permissions on all existing NX profiles manually or using a script.
NoMachine are referring to NX client version 4 as the solution to all their problems. That includes bug reports about this problem but they have been doing it for years and there’s no sign of that client yet so don’t hold your breath.