User permissions restricted when running headless

[calinb]

I’m using the free version for ARM64 Linux 8.2.3 server and client. If I use the NoMachine remote client (“player”) to access my Quadra computer (“server”) when it is connected to an HDMI monitor, the user permissions are exactly as set and expected and the user can logon, reboot, configure the network using net-manager, etc.–the same as when the user is physically present at the Quadra’s console.

However, when I run the Quadra headless and stop the X server manually, in order to make NoMachine use its own display service, as described in option #3 at https://kb.nomachine.com/AR03P00973, then the user permissions are restricted (shutdown and reboot options are greyed-out in the panel applet and the network-manager applet also does not authenticate and hangs). Running Sudo works to shutdown or reboot without requiring authentication, just as specified in the Sudoers file.

When I attempt to run Sudo nm-connection-editor from a terminal in the headless case, I get:

Unable to init server: Could not connect: Connection refused

(nm-connection-editor:4428): Gtk-WARNING **: 18:51:21.624: cannot open display: :0

The user is the same user in both HDMI and headless cases and is logged-on automatically at boot using

autologin–user=pi

in the /etc/lightdm/lightdm.conf file.

Thanks!

-Cal

[katpan]

Hello Cal

Thank you for your topic.

The difference between the physical display and the NoMachine virtual display might be in the environment.

Can you please provide the output of the ‘env’ command run in both cases, so we can compare?

Thanks

[calinb]

I can’t send a message of useful size or attachments. That seems to be the problem.

[calinb]

and the output from env, though not being very long, is too long for this forum.

[Britgirl]

You can send any attachments to forum[at]nomachine[dot]com. Make sure you use the title of this topic as the subject of your email. Thanks!

[calinb]

Thanks, Britgirl! I emailed the attachments with the results of env.

I’ve very much like to get to the bottom of this. The lack of permissions, in addition to failure of the network-mgr GUI applet to accept authentication at all in headless mode (the GUI crashes/locks up) causes a big system maintenance issue for me. The network-mgr applet works fine when I have an HDMI monitor attached to the system but is 100% unusable when run headless.

Sure–I might be able to use the cli net-mgr tools, but I’m not terribly good with them and that’s why we have GUIs and nomachine in the first places, instead of just ssh!

Regards,

-Cal

[Britgirl]

We don’t see many differences in your environment settings between the two. You could try editing /usr/NX/etc/node.cfg on the server side:

DefaultDesktopCommand "env XDG_DATA_DIRS=/usr/share/xfce4:/usr/local/share/:/usr/share/:/usr/share /usr/bin/startxfce4"

and connect again to your “headless” machine (on the server first stop X server and then sudo /etc/NX/nxserver --restart and then connect)

If the problem is still there, tell us what distro is and how you installed xfce.

[calinb]

Thanks for your suggestion, Britgirl.

I tried your suggestion but nothing changed.

I have an Inovato Quadra. It runs an Armbian OS which is pre-installed with the XFCE desktop:

https://www.inovato.com/

I learned about nomachine from the owner of Inovato.

I also run the Quadra version of Hampi, which is built on the Quadra Armbian OS:

https://sourceforge.net/projects/hampi/files/

https://github.com/dslotter/HamPi/wiki

It turns out that neither system works with nomachine as expected. I purchased a “fake monitor” HDMI dongle and…

1. nomachine does not work at all with the dongle plugged in after booting the Quadra OS (no display found) but it DOES work with your frame buffer when nothing is connected to the HDMI port (and the permissions permit full system administration in this case).

2. The Hampi system works as expected with the dongle (permissions are full, as expected, so system management can be performed) but, without the dongle, I have the permissions problem that I reported in my OP.

I prefer the nomachine virtual frame buffer to the dongle, because the nomachine VFB supports 1600×960 (the native resolution of the “Ham Clock” application on my Hampi system, which the dongle EDID codes does not support, though it has a nice selection of modes otherwise.

Thanks,

-Cal

[Britgirl]

I have an Inovato Quadra. It runs an Armbian OS which is pre-installed with the XFCE desktop:

To be honest we’ve not tried NoMachine on  a Quadra. It’s one of many of these small devices on the market that to test all of them becomes impossible 😉 The same also applies to Armbian OS and Hampi. Systems and distributions we have tried and tested are listed in the dedicated article here, they are the most popular ones:

Installation & configuration notes for NoMachine Linux ARM packages
https://kb.nomachine.com/AR03M00842

You say changing the DefaultDesktopCommand key suggestion didn’t work. You didn’t say what the result was, but nevermind.

You could try the command:

grep ^Exec /usr/share/xsessions/*

You will see a list of commands which start all DE which you have installed on the system
You could choose one and set it in DefaultDesktopCommand key and see if with an alternative DE it works. More examples are here: https://kb.nomachine.com/AR04K00667

However, to cut to the chase (your original OP), and now that we have more info about what is installed on the Quadra

2. The Hampi system works as expected with the dongle (permissions are full, as expected, so system management can be performed) but, without the dongle, I have the permissions problem that I reported in my OP.

 

only logs would help us to identify what is happening. Enable debug, reproduce the problem with Hampi and zip up the logs. We can take a look. To do that follow the instructions here :

https://kb.nomachine.com/DT07S00243#2

Send to forum[at]nomachine[dot]com making sure you use the title of this topic as the subject of your email.

[calinb]

You say changing the DefaultDesktopCommand key suggestion didn’t work. You didn’t say what the result was, but nevermind.

The behavior didn’t change and the permissions problem persisted.

It’s understandable that you cannot test your software on all these little niche products. BTW, I tried to install your installation file on my arm64 Pinebook Pro running Manjaro but it failed with some kind of “unsupported” message so I installed the Arch (parent OS of Manjaro) repository package and it seems to work just fine but I’ve not done anything close to comprehensive testing.

I’ll try to get some logs to you. Thanks for the help!

Cal

[Author]

Posts