April 16, 2020 at 17:14 #26807
I’m trying to figure out how to successfully get this working in our environment. The goal is to have students connect to 10 Mac lab workstations to use the programs on those computers from their homes off campus. They would install and use the client software to do this, not the web.
I’ve got a Linux box with ‘nomachine-enterprise-desktop_6.9.2_1_x86_64.rpm’ installed on there and ports 4000, 7001 to 7011 open. Also added a user on here, too. I’ve tried to follow these instructions: https://www.nomachine.com/DT02O00125 but I’m missing some pieces. I have ssh access to the server, but not GUI.
I have installed the Enterprise Client on a test iMac in the lab. Client setup https://www.nomachine.com/DT04O00140 (These machines are bound to Active Directory for authentication). OS in the lab is 10.14.6 at the moment.
The firewall is turned on for the client computer. I have seen no prompts while running the client to open any firewall ports. Nothing in the Firewall list shows NoMachine.
I would think I could run a command line to add that client machine via IP or something from the server but that doesn’t appear to be the case while I look at the instructions.
To attempt to create a connection from the lab iMac to the server, clicking on the New button and putting in the Linux box IP address, prompts for Password, Private key or Kerberos. I would think the Kerberos option is what I would want so they can authenticate with their AD credentials, but that is unclear if I am setting that connection for the linux box to the client or from the client to the linux box. I would assume clicking on the Forward authentication is what I want.
Doing the connection that way just ends up in no connection to the server, but if I choose password and then put in my test account on the server, it just tries to open a window that says Oops. I’m not trying to create a session where I view the server, so I’m just thoroughly confused.
Any help is appreciated.April 16, 2020 at 18:00 #26817
Firstly, can you tell me what Linux distro it is and version, and what desktop environment is running there?
Let’s leave ‘Password’ as the way you are going to connect for now. This is the default setting. If you want to use a kerberos ticket the appropriate ticket needs to be already generated and placed either on the server or the client device. This will need configuring before you set up your session via ‘New’. This can be done later (and by consulting this document here: https://www.nomachine.com/DT10O00150)
Click New, add your IP, choose NX as the protocol, and leave Password as the way you are going to access.
So you create your session, double click on its icon in the UI and you are asked to authenticate on the Linux server, you use your account credentials when prompted. Are you the owner of the desktop you want to access? Can you show me a screenshot of what the error message is?
You also write “I’m not trying to create a session where I view the server”. What do you mean exactly? Can you show a screenshot of this as well? Enterprise Desktop will give you access to the physical display of the computer. It won’t create multiple desktop sessions on the same host. That feature is offered in the Terminal Server for Linux range (just to clarify the difference).April 17, 2020 at 07:33 #26825
First, thanks for replying and trying to help me sort this out!
The server is RHEL 8. I only have ssh access to the machine, so will need to stick to the command line for any setup. Are you telling me that this won’t work unless I have access to the Desktop Environment on the linux box? I would think I could just use command-lines to set up the connection with the iMacs I want to use in the lab as long as they have the enterprise client on them. Maybe this is not the case?
The Desktops are lab machines. No individual owners. I just want the users to be connected to some kind of visual where they can choose one of 10 iMacs available to connect to and then a visual of the iMac desktop login window where the user can authenticate with their AD credentials like they normally would if sitting in front of it. If I need to create some kind of NoMachine account to get to that login screen I can create a local account on each lab machine for that purpose, but I’m not sure why that would be necessary.
Furthermore, if we can at least get this working, we want to add Duo as an MFA for the authentication process. But right now, I just want one of the professors to be able to log in and test the connection out to see if the lag is just too much to even attempt having the students do this.
When I mean I don’t want to create a session where I view the server, I mean the server is just the gateway, as I understand it, for the off campus users to reach the lab computers.April 17, 2020 at 14:26 #26866
‘Gateway’ was the keyword to allow me to understand what you’d like to achieve. I missed that from your original post. So you should be installing Cloud Server on your Linux host. This will be the entry point or gateway. On each of the Macs you need to install Enterprise Desktop. It will look something like the last diagram you can see in this document https://www.nomachine.com/DT03O00131 . That document illustrates how to set up two Cloud Servers in failover, HA is an optional. You can just have one Cloud Server if you prefer, like in the illustration at the bottom.
Adding child servers (your Macs) to the main Cloud Server is the next step. It can be done via the user interface of the Cloud Server. See this tutorial for the steps on how to do that: https://www.nomachine.com/adding-servers-to-nomachine-cloud-server-via-the-user-interface. If you prefer to do it via the command line, then see https://www.nomachine.com/AR04R01082.
This should be enough to get you started 🙂
Futher references:April 17, 2020 at 15:37 #26867
Thanks. That is what I was thinking as well, but when I called to originally discuss this with a NoMachine rep. I explained exactly what I was wanting to do and was thinking Cloud too, as looking at the website this seemed to be the option, but he said we could use the Enterprise product with our own Linux server to do this.
Yes, following the https://www.nomachine.com/AR04R01082 guide on that page, I had tried to add a client on the command line and it said it would not work. I think their terminology of using the word server in some of the documentation, for what I would describe as a client, was confusing me.
I’ll run the uninstaller and then try and install the cloud server option and see how it goes.
Much appreciated!April 17, 2020 at 15:59 #26871
Just to clarify, when documentation mentions ‘client’ it means connecting client. In the case of the Cloud Server, there are three components: client (the user/device connecting), Cloud Server (Linux for you, child server (in your case Enterprise Desktop on Mac).
If there is anything in the documentation which is not clear, by all means forward your comments directly to forum[at]nomachine[dot]com and I will make sure they are passed on 🙂April 17, 2020 at 23:35 #26878
Thanks for your help. That got me on the right path and in a few minutes I had some new errors :-).
To back up a little (and on a good note!), I have a connection working and can remote in when I have a local user account set up on the cloud server that matches a local account also on the lab machine/child servers. For our initial testing to see if this connection will provide a fast enough fps for this lab, this should suffice (although audio doesn’t seem to be working – which is a key thing to sort out. Do I need Pulse Audio installed on the Cloud Server?
But I do get an error when I don’t use that local account. I would like to authenticate using our Active Directory credentials and I’ve been looking at this page: https://www.nomachine.com/DT10O00150 for help. Right now, the cloud server is not bound to AD, but I figured the username/password would be passed through and use the iMac/child server to sort this out, but maybe not? My account on the cloud server is tied to AD (I’ve got a question into another sysadmin who set up the linux box. I’m not sure how my account is on there and tied to AD, but it doesn’t recognize the realm command – so I’ll be waiting until next Monday to get that answer). When I use my AD account in the username and password field when I try and connect, it properly shows the iMac/child server I have added, but then immediately errors out by saying:
The session negotiation failed.
Error: Cannot create session directory: /var/empty/.nx
Error is: Operation not permitted
As an aside, the permissions on the cloud server for /var/empty were 755. For kicks I changed them to 777 and I still get the error. I’m not sure if this error is from the cloud server or the child server/iMac. The /var folder on the iMac is protected due to SIP.
This error seems similar to this thread: https://forums.nomachine.com/topic/cannot-create-session-directory-2#post-23053 but not quite the same.
When I try and use any other Active Directory account it just asks for the username and password again, so like I said I need to sort that out on our end.
Thanks for the all the help so far, I am finally making some progress!April 22, 2020 at 08:28 #26946
Do I need Pulse Audio installed on the Cloud Server?
No you don’t. Check audio kext files on the Mac host. NoMachine needs to install KEXTs to manage services like audio support, disk sharing and USB forwarding. If KEXTs are not approved, the software will install and work correctly but such services will be not available.
kextstat | grep nx
If it shows nothing you need to change our file permissions and load kexts to the system
sudo chmod -R 755 /Applications/NoMachine.app/Contents/Frameworks/bin/drivers/nxaudio.kext
sudo chown -R root:wheel /Applications/NoMachine.app/Contents/Frameworks/bin/drivers/nxaudio.kext
sudo kextutil /Applications/NoMachine.app/Contents/Frameworks/bin/drivers/nxaudio.kext
More about this is here:
And you can get some background reading on how Apple’s new security measures here: https://www.nomachine.com/AR10P01001 (although this was explicitly written for users installing earlier versions of NoMachine).
Error: Cannot create session directory: /var/empty/.nx
The error you see refers to ‘/var/empty/.nx’ on your Mac host. Directory ‘.nx’ needs to be created inside user’s home directory. As you most likely noticed, ‘/var/empty/.nx’ looks unusual for a home directory path. Is it the way your system is configured?
On the Mac machine, log on with the account you are using during NoMachine connection, open terminal, type ‘pwd’ and press enter. What’s the output of this command?April 23, 2020 at 07:49 #26972
The kextstat | grep nx command showed nothing. We approve our kexts via our MDM and if you know the Team Identifier, I can put that in and whitelist the company. We do that for quite a few other vendors Kernel Extensions and now System Extensions.
As for the /var/empty/.nx, each user account is not created until they actually log into the GUI, so NoMachine trying to resolve before that login happens doesn’t work unless it is using a local account, which we don’t want to use if we can actually get this working. For these lab machines the accounts are created on log in and removed on log out. After they are created they will have a /Users/accountname path.
But right now I’m struggling getting this connection to work off campus. Using a local account works on campus, but as soon as I go home to test that same local account connection off campus, NoMachine connects to our Linux Box/Cloud server and then seems to forward that connection to the child server/enterprise desktop client/lab iMac, but then says it can’t connect on port 4000. I would think it would keep all traffic routed through the cloud server/linux box, but that doesn’t appear to be what is happening? For testing purposes I have turned off the Firewall on the iMac, but that doesn’t seem to resolve the issue.
I’m assuming I don’t have something configured properly for this issue to appear.
Here are the sanitized logs: (attachment)
Attachments:April 27, 2020 at 09:51 #27037
This is happening because indeed NoMachine tries to access a home directory in order to create the .nx directory but the directory doesn’t exist yet and so NoMachine receives a permission denied message. If it’s dynamically created after that, the user can then log in to the GUI.
A way round this is to edit the NoMachine cfg file on each Mac server:
Find there line:
#UserNXDirectoryPath ""uncomment it by removing “#’ and in “” put the path to some directory which is permitted for all users. It could be /tmp for example or any other created directory with permissions at least 666 or even 777.
UserNXDirectoryPath “/tmp”April 28, 2020 at 15:55 #27072
Thanks, I made that change to the UserNXDirectoryPath, but can you tell me how I can configure the Cloud Server so when I try and connect from my home it tunnels the connection through the Cloud Server instead of trying to make a direct connection with the client/lab iMac? We only want the Cloud Server open through our firewall, not all the lab computers.April 28, 2020 at 16:59 #27076
NoMachine Cloud Server – Installation and Configuration Guide
Par. 3.3. Advanced Configurations for NoMachine Servers’ Hierarchy
Add Enterprise Desktop to Cloud Server by forcing the ‘tunnel’ method. To do that, execute on the Cloud Server host:
nxserver --serveradd IP_of_ED --forward-nx-methods tunnel nxserver --serveradd IP_of_ED --forward-ssh-methods tunnel
Does this help?April 29, 2020 at 17:11 #27095
We’ve opened a Trouble Report which contains the workaround I provided earlier:
AD mobile accounts cannot create sessions on macOS at the first login if they cannot access their home
https://www.nomachine.com/TR04R09659May 2, 2020 at 08:22 #27116
Yes! I had to use a slightly different variation
--serveraddbut that worked! (I only did it for the nx option as I’m not utilizing ssh for this setup)
I still did not hear any sound from the client machine. Do you have any suggestions on what I can do to get that working?May 4, 2020 at 15:30 #27141
Did you run “kextstat | grep nx” before the sudo commands or after having executed the sudo commands?
You must be logged in to reply to this topic.