- This topic has 12 replies, 3 voices, and was last updated 22 hours, 26 minutes ago by
.
-
Posts
-
I just upgraded NoMachine on my Mac, from 9.1.24_6 to 9.2.18_1 (free version), and since the upgrade, I’ve lost the ability to make remote access to that computer through NoMachine.
This particular box is a 2020 Mac Mini with an M1 processor that is running Sequoia 15.7.1
On the client machine I have a pre-defined connection point defined for the server, although there is also an auto-detected connection offered. Prior to the upgrade, I could use either of these to connect to the server.
Since the upgrade, if I use either of these contact points, NoMachine reports “no available desktops on this server”. Right now, my suspicion is that I’m seeing a structural issue with NoMachine, rather than a MacOS permissions issue. I’ve checked and all the system permissions I can find are OK.
From a command line I ran nxserver –status, and it reports that nxserver and nxd are active, but that nxnode is disabled, and I think that’s the source of my problem. I ran nxserver –shutdown and the nxserver –startup and the result still reports that nxnode is still disabled.
On a whim, I did another shutdown and then disabled the permissions for screen recording, but when I re-ran a startup, I didn’t get a prompt for enabling screen recording permissions.
There’s probably something small here that I’m missing, but I don’t see what it is. Any clues of how to resolve?
Other potentially relevant information:
– I’m seeing the same behavior with access attempts from NoMachine 9.1.24_6 free version from connection attempts from both Win 11 and Linux Mint 21.3 (with Cinnamon desktop), although both of these connections were working reliably before the upgrade of the Mac.
– For the Mac, the display is set up with a KVM connection, and where remote connection attempts are happening when the KVM is switched to a different display (namely, the computer attempting to connect).
Any chance that downgrading the Mac back to 9.1.24_6 would resolve this problem?
TIA
It seems that Accessibility permissions were lost during the update. Go to the affected macOS host and shut down the NoMachine server – you do it from the UI in Server settings or from a terminal (in that case
nxserver --shutdown). Proceed to Screen Recording and Accessibility panels and remove all NoMachine permissions. Then go back to Server settings and restart the NoMachine server (nxserver --startup). Then add the permissions again in Screen Recording and Accessibility. Does that help?Process makes sense, but no progress.
I did a shutdown of nxserver via Terminal, and from there, I found only 2 permissions for NoMachine in Privacy & Security. One in Accessibility, the other in Screen & System Audio Recording, and I disabled those. When I restarted nxserver, I’m still getting a report of “NX> 162 Disabled Service: nxnode.” (both nxserver and nxd both report that they’re enabled). And no change after I reenable the permissions in Privacy & Security.
I did some further checking of permissions, and did another shutdown (I notice that nxnode reports that it’s already disabled), and I also found NoMachine permissions in Local Network and Microphone, and closed those, as well. Still, the same results, where reenabling nxserver activates nxserver and nxd, but not nxnode.
Thus, the problem seems to be getting nxnode to start. At the moment, I can’t find a reason why it’s not starting or how to get it to start.
Can you send us the logs from the affected macOS server? Go to Settings > Server > Security, scroll down and click “Take logs”.
“Any chance that downgrading the Mac back to 9.1.24_6 would resolve this problem?”
We aren’t aware of similar problems after updating to 9.2 and that’s why we need to take a look at the logs first. Then you can try going back to the previous version. If you don’t have a backup of the package of the earlier version, we can send a temporary link so you can download it.
Logs uploaded. The full .ZIP exceeds allowed file size, so I’m uploading just the most recently touched files: server.log, daemon.log, history and install.log. I can upload the update.log file and time-relevant contents of the Users and node folders, if necessary.
If you can, it would be better to enable debug, restart, reproduce (so check that the nxnode is not running) and retake the logs (if you do it from Server settings > Security , Take logs), it will make sure we receive everything we need from the server side. Thanks!
I’m happy to do that, but I don’t see where the setting is to enable debug, even if I can find the Take Logs.
In the meantime, it is worth noting that I’m finding both Windows and Linux clients are able to discover this machine as active.
As for logs, it looks like my size problem comes from the dump covering multiple years of accumulation. When I do a dump again, I’ll exclude everything older than about a week before my upgrade attempt (allowing seeing activities before the upgrade, if needed). However, in that context, is it safe to discard logs that are older than that?
I’m happy to do that, but I don’t see where the setting is to enable debug, even if I can find the Take Logs.
Apologies I should have pointed you to the instructions (https://kb.nomachine.com/DT08U00298?s=logs#1.1).
On the Mac Mini, where you find the Take logs button in Server settings, there should be a level you can set as well. Set it to level 9, then restart the server (see the attached image). Pasting in the first few steps that apply to you from the document mentioned above.
Step 1 – Open the UI on the server host -> Settings -> Server -> Security
Step 2 – Scroll down the Security panel till the end to find section ‘Server logs’. Set there the log level as requested by the Support Team. Restarting the server is requested to make change effective, this will terminate all sessions. If this is not an option, use the manual procedure from command line.
Step 3 – Reproduce the problem.
Step 4 – Click on the ‘Take logs’ button: you will be requested to provide username and password of the administrator. Logs will be saved in a .zip archive.
However, in that context, is it safe to discard logs that are older than that?
Yes.
it is worth noting that I’m finding both Windows and Linux clients are able to discover this machine as active.
So you can see the Mac Mini when you are on the Windows and Linux clients, but you cannot connect from either?
OK, I found the setting for debugging data. I forgot that that’s a function of how much data is included in logs.
From there, I restarted the server, and then attempted remote access from both Windows and Linux. Both of them are able to discover the Mac, but access attempts still produce the “no available desktops available on this server” error.
I should have both of those in the logs.
However, when I do a Take Logs, the resulting file comes out to 17.5 MB, and even if I discard older logs, I can only get that down to 14 MB, and still way in excess of your server’s 1 MB upload limit. How do I get around that problem?
I have the same problem with the latest macOS update and the current NoMachine version.
Attachments:
Xlear, when that happens, click Save the connection logs and send that to us: attach it here or send via email to forum[at]nomachine[dot]com. Make sure you use the title of this topic as the subject of your email.
You must be logged in to reply to this topic. Please login here.