- This topic has 17 replies, 5 voices, and was last updated 2 years, 8 months ago by
.
-
Posts
-
Several other threads exist where individuals are able to authenticate from the NoMachine client to a remote system running NoMachine but are subsequently unable to authenticate to do things such as restart the service on Mac OS. I’m creating this thread to seek a canonical resolution to this issue as previous threads seem to have been prematurely closed.
Background
I connect from a Windows 11 client running NoMachine 7.7.4 for Windows
I connect to a Mac OS 11.6.1 server machine running NoMachine 7.7.4 for Mac OS X
On the Mac OS system, my user is part of a Windows domain
uid=1974106972(redacted) gid=1987437277 groups=1987437277,12(everyone),20(staff),61(localaccounts),80(admin),702(com.apple.sharepoint.group.2),33(_appstore),98(_lpadmin),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae),701(com.apple.sharepoint.group.1)
When using the Server Settings interface to restart the server, I’m prompted with an authorization dialog under Mac OS and enter my credentials. The NoMachine user interface then displays an error (see the attached image)
Correlated to the user interface error above is the nxerror.log entry (which repeats per-attempt):
12506 259 11:53:45 396 nxexecGetUser: Got error 0.
12506 259 11:53:45 396 nxexecGetUser: The given uid was not found: 1974106972.
12506 259 11:53:45 396 main: ERROR! Failed to get current username.
The contents of my ${HOME}/.nx directory are as follows:
drwx—— 30 redacted 1987437277 960 Dec 15 17:19 ./
drwxr-xr-x+ 53 redacted 1987437277 1696 Dec 15 17:26 ../
drwx—— 5 redacted 1987437277 160 Nov 29 23:43 F-M-M-C02VM1UTHV2Q-13001-16C5E828945BC04D4157ADB4654682F7/
drwx—— 5 redacted 1987437277 160 Nov 23 13:57 F-M-M-C02VM1UTHV2Q-13001-48CC57B41CEDAB1C3C2B08C42AF59B8E/
drwx—— 5 redacted 1987437277 160 Nov 23 13:53 F-M-M-C02VM1UTHV2Q-13001-AA38D38B9A21DAA4E8B29E68E40B2345/
drwxr-xr-x 3 redacted 1987437277 96 Nov 4 10:49 K-localhost-1397-325C473C95161FE80AA79667B12959D6/
drwxr-xr-x 3 redacted 1987437277 96 Dec 15 16:21 K-localhost-1816-AB3142AD4586A2CBE7B6E7CDCACA5EF9/
drwxr-xr-x 3 redacted 1987437277 96 Nov 30 00:01 K-localhost-782-CF018146AF5DDC0916219AE68B9E8F5E/
drwxr-xr-x 3 redacted 1987437277 96 Nov 30 12:24 K-localhost-783-2ED70CB4E5FD4D994B426855FE1A2571/
drwx—— 5 redacted 1987437277 160 Nov 3 13:22 M-F-M-C02VM1UTHV2Q-13002-5D0589BCA2AEBCE5FD31B1EFD21C580C/
drwx—— 5 redacted 1987437277 160 Nov 30 12:24 M-F-M-C02VM1UTHV2Q-13002-A74D63E07EDF5DC18D491C39DCCC0FB0/
drwx—— 5 redacted 1987437277 160 Nov 4 10:49 M-F-M-C02VM1UTHV2Q-13003-5955A2F26C17C45422D9C23E8B96260F/
drwx—— 5 redacted 1987437277 160 Dec 15 11:19 M-M-C02VM1UTHV2Q-13001-BC92A9E6121A453EB870CDB6C449143D/
drwx—— 3 redacted 1987437277 96 Nov 30 10:16 M-localhost-11708-1307761C8086854D9A3F6F02E08EC581/
drwx—— 3 redacted 1987437277 96 Nov 30 10:16 M-localhost-13088-1E7E303DAAAB64AC5DB867D40D6812F6/
drwx—— 3 redacted 1987437277 96 Nov 30 10:16 M-localhost-19176-02414D3AA65CE8ADB86718621EA22E07/
drwx—— 4 redacted 1987437277 128 Nov 4 10:49 R-localhost-1479-C778117D1309932C5BD7ED5B126EF86E/
drwx—— 4 redacted 1987437277 128 Nov 30 00:01 R-localhost-1858-64EC01DFAA87333FF156EBBD9118B5E1/
drwx—— 4 redacted 1987437277 128 Dec 15 16:21 R-localhost-26933-CC2EE6A05F71BBED8060425D275A9C72/
drwx—— 4 redacted 1987437277 128 Nov 30 12:24 R-localhost-850-D20FDE951863502C7CA69BF3C8C2A650/
drwx—— 4 redacted 1987437277 128 Dec 15 17:20 S-localhost-59996-FA832D44CE55772AB44502B13FC4D2BE/
drwx—— 4 redacted 1987437277 128 Dec 15 16:21 S-localhost-63145-08194DE2AC0E7E58A7B2B9AE193E1369/
drwx—— 4 redacted 1987437277 128 Dec 15 16:40 S-localhost-63853-0149A08862DA6C578C0BA5B31307C2EC/
drwx—— 2 redacted 1987437277 64 Nov 3 12:36 cache/
drwx—— 3 redacted 1987437277 96 Nov 30 10:31 config/
drwx—— 27 redacted 1987437277 864 Dec 15 17:24 node/
drwx—— 3 redacted 1987437277 96 Dec 15 17:24 nxdevice/
-rw——- 1 redacted 1987437277 11962 Dec 15 17:22 nxerror.log
-rw——- 1 redacted 1987437277 11141 Dec 15 16:13 nxserver.log
drwxr-xr-x 6 redacted 1987437277 192 Nov 30 12:25 temp/
The contents of /Applications/NoMachine.app/Contents/Frameworks/bin are as follows:
drwxr-xr-x 20 root wheel 640 Nov 30 10:17 drivers/
-rwxr-xr-x 1 root wheel 48368 Oct 19 10:26 nxagent*
-rwxr-xr-x 1 root wheel 61168 Oct 19 10:23 nxauth*
-rwxr-xr-x 1 root wheel 906 Jan 7 2021 nxclient*
drwxr-xr-x 3 root wheel 96 Nov 30 10:18 nxclient.app/
-rwxr-xr-x 1 root wheel 142160 Oct 19 10:26 nxcodec.bin*
-rwxr-xr-x 1 root wheel 36672 Oct 19 10:26 nxd*
-r-sr-xr-x 1 root wheel 278784 Oct 19 10:23 nxexec*
-rwxr-xr-x 1 root wheel 765744 Oct 19 10:23 nxfs*
-rwxr-xr-x 1 root wheel 92864 Oct 19 10:23 nxfsserver*
-rwxr-xr-x 1 root wheel 246192 Oct 19 10:23 nxkb*
-rwxr-xr-x 1 root wheel 37920 Oct 19 10:23 nxkeygen*
-rwxr-xr-x 1 root wheel 40752 Oct 19 10:26 nxlocate*
-rwxr-xr-x 1 root wheel 71568 Oct 19 10:23 nxlpd*
-rwxr-xr-x 1 root wheel 849 Oct 19 10:26 nxnode*
drwxrwxr-x 3 root wheel 96 Nov 30 10:18 nxnode.app/
-rwxr-xr-x 1 root wheel 126768 Oct 19 10:26 nxnode.bin*
-rwxr-xr-x 1 root wheel 153760 Oct 19 10:23 nxpost*
-rwxr-xr-x 1 root wheel 5663 Nov 30 10:17 nxprint*
-rwxr-xr-x 1 root wheel 539 Oct 19 10:27 nxserver*
drwxrwxr-x 3 root wheel 96 Nov 30 10:18 nxserver.app/
-rwxr-xr-x 1 root wheel 128192 Oct 19 10:27 nxserver.bin*
-rwxr-xr-x 1 root wheel 36304 Oct 19 10:23 nxsh*
-rwxrwxr-x 1 root wheel 32864 Oct 8 15:14 nxsign*
-rwxr-xr-x 1 root wheel 444912 Oct 19 10:23 nxssh*
-rwxr-xr-x 1 root wheel 174896 Oct 19 10:23 nxssh-add*
-rwxr-xr-x 1 root wheel 154144 Oct 19 10:23 nxssh-agent*
-rwxr-xr-x 1 root wheel 1028784 Oct 19 10:23 nxusbd*
Attachments:
To clarify what’s written above, when using the terms client and server that refers to the use of NoMachine. The Mac is not running a Mac OS server operating system.
This might only be an error for me, but I’m unable to load the error in my browser on the forums. Attaching it once again here. And hoping for some replies to my thorough post.
Attachments:
We’ve not been able to reproduce. We would like to send you a debug package in order to understand why authentication is failing. Would you be able to install it and send us the logs? (we’ll send you instructions).
Happy to run a debug version and assist in debugging it. One problem you may have in reproducing it is having Macs configured to resemble corporate deployments with various profiles.
In other posts related to this issue (which I believe were prematurely closed) the uid was similarly a large integer that indicated active directory users
Hi. I’m having a problem that seems like it may be similar. It has the same symptoms, and also involves connecting to a mac OSX, and also started with upgrade to 7.7.4. The error given on client machine is:
“A connection timeout has occurred while trying to connect to ‘XX.XXX….’ on port ‘NNNNN’.
I’ve been connecting between two macs, 10.15.7. After upgrading to NoMachine 7.7.4 (from 7.6.x) on both machines, the server no longer responded to the client’s mouseclicks or keyboard entries. After restarting the server, the client was no longer able to connect at all. I’m using nx protocol over internet and have limited access to the server. I have reset permissions (system preferences> security & privacy > privacy > accessibility) on both machines with no change.
On client machine, nxerror.log reads (for latest login attempt):
1342 775 12:18:39 641 nxexecGetUser: Got error 0.
1342 775 12:18:39 642 nxexecGetUser: The given uid was not found: 501.
1342 775 12:18:39 642 main: ERROR! Failed to get current username.Hello @skibbidypaps and @PB,
We sent you both an email with a debug package.
Please check your mailboxes and follow the instructions.
Thanks!
Hi,
A gmail search for in:all nomachine debug doesn’t return any results in my inbox. A search for in:all nomachine only returns results related to this thread.
Would you please share the subject and/or from address of the email that sent the debugging packages?
Hi, I’ve just forwarded it on to you again. It was originally issued from the Forums backend. I’m not sure what happened there. Let me know that you got it.
The tag currently associated with this is a bit of a misnomer, and since I had more to add it was the perfect opportunity to add a tag.
Under Mac OS, the uid_t type is an unsigned 32-bit int: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types/_uid_t.h:
#ifndef _UID_T
#define _UID_T
#include <sys/_types.h> /* __darwin_uid_t */
typedef __darwin_uid_t uid_t;
#endif /* _UID_T */
And from /usr/include/sys/_types.h:
typedef __uint32_t __darwin_id_t; /* [XSI] pid_t, uid_t, or gid_t*/
I wrote a little test program that uses getuid() to get the pid of the running process and then uses both getpwnam (for my user) and getpwuid(). It prints out the entries from the returned passwd structure just fine for both calls. I repeated this for root and it too works just fine.
It appears as though all but one of the running NoMachine processes are running as my local user, and the outlier is nxexec.
I’m not sure where NoMachine’s code has gone wrong, and there are many interfaces to these syscalls that are language dependent, but I’m able to retrieve the data using the most obvious and POSIX compliant interfaces.
#include <sys/types.h>
#include <uuid/uuid.h>
#include <pwd.h>
#include <stdio.h>
#include <unistd.h>
int
main(int argc, char *argv[]) {
uid_t this_uid = 0;
struct passwd *u_mypw, *i_mypw;
char *who = “root”;
uid_t whos_uid = 0;
this_uid = getuid();
u_mypw = getpwnam(who);
i_mypw = getpwuid(whos_uid);
printf(“uid is %d\n”, this_uid);
printf(“%s’s UID is %d via getpwnam()\n”, who, u_mypw->pw_uid);
printf(“UID %d’s name is %s via getpwuid()\n”, whos_uid, i_mypw->pw_name);
}
$ ./test
uid is 1974106972
root’s UID is 0 via getpwnam()
UID 0’s name is root via getpwuid()
Yes, the problem persists in the debugging package. The debugging package just appears to just have all the debugging options turned on (refer to https://knowledgebase.nomachine.com/DT11R00182)
It wasn’t an actual new release – so I wasn’t expecting a resolution to my issue. And when I tested it, the issue still presented itself in the package I was sent.
This topic was marked as closed, you can't post.