Forum / NoMachine for Linux / NxFrameBuffer error while starting
- This topic has 30 replies, 4 voices, and was last updated 3 months, 4 weeks ago by Britgirl.
-
AuthorPosts
-
May 31, 2024 at 18:11 #48350JustAnotherLinuxGuyParticipant
I did look through the previous posts, but I wasn’t able to find anything relevant to our setup. I sent over an email with some more info
June 3, 2024 at 10:43 #48364fishermanModeratorUpon reviewing our system configurations, I’ve noticed an issue with the permissions in the /rhome directory. Specifically, the home folder of DV9G49 appears to be owned by root with only root having write access.
Here’s a snapshot of the permissions:
root@workstation-analyst3:~# ls -la /rhome/ total 736 drwxr-xr-x 15 root root 4096 May 31 14:36 . drwxr-xr-x 1 root root 4096 May 31 13:26 .. drwxr-xr-x 2 root root 4096 May 23 16:03 DV9G49
However, upon further inspection, it seems that the correct permissions are applied in your home directory /home/DV9G49:
root@workstation-analyst3:~# ls -la /home/DV9G49 total 28 drwxr-xr-x 2 DV9G49 DV9G49 4096 Feb 27 14:52 .
To resolve this discrepancy, I recommend checking if your NFS mounting, if used, correctly applies permissions. If not, please ensure that the folder /rhome/DV9G49 is owned by the user DV9G49 and has write permissions for the same user.
Thank you for your attention to this matter. If you require any assistance or further clarification, please don’t hesitate to reach out.
June 3, 2024 at 14:03 #48367JustAnotherLinuxGuyParticipantPerhaps I haven’t been very clear…
We do not care to set a default home directory. The frame buffer issue was appearing before we had any sort of permission errors.
Furthermore, I have attempted to disable the configuration for setting a default home directory. Despite numerous attempts, the permission error still remains. Is there a setting I can adjust to prevent the system from making these changes? Please refer to my previous post where I noted the server.cfg change I made in regards to the default directory.
June 3, 2024 at 18:16 #48372fishermanModeratorI have never tried to use and setup gnome to be started using docker containers. I feel that your issue is related to the docker configuration and not at all to the NoMachine. I have tried installing gnome in my docker container and could not start a gnome-session unrelated to the NoMachine. I used xvfb-run, and the session was failing with something related to dbus, I did not explore and debug more.
While I can confirm that I have tested xfce and Mate and they work very well.
sudo apt install xfce4 xfce4-goodies
and then edit /usr/NX/etc/server.cfg and set that NoMachine will start xfce4
DefaultDesktopCommand /usr/bin/startxfce4
June 3, 2024 at 18:43 #48373JustAnotherLinuxGuyParticipantYou need to set the default desktop to gnome-classic in the config file in order for it to launch properly. Or at least that’s the case for GNOME 42.
I cleaned up that VM and started over with a brand new install. I am still seeing a permission error, I think this is being generated because we have set NoMachine to create its own X11 display. Which requires
CreateDisplay 1
andDisplayOwner "DV9G49"
. If I understand correctly, this causes a directory to be set up in/rhome/
but due to the permissions of this directory, NoMachine can’t and therefore we see an error.However, this time it is not a frame buffer error as before. Can you take another look at the logs to see if there is something different occuring this time around?
June 4, 2024 at 08:36 #48377BritgirlKeymasterCan you forward those logs to forum[at]nomachine[dot]com?
June 4, 2024 at 09:14 #48385fishermanModeratorRemoving the NoMachine software from the picture entirely, we were NOT able to launch Debian Gnome desktop from a docker file. So, this is something that we cannot investigate further. Whilst, as we mentioned, XFCE runs fine.
Putting NoMachine back into the picture with XFCE, again everything works as expected. So you could possibly try with XFCE as well, as we recommended earlier.
However, the issue you are having with the /rhome/ folder is not clear to us. For NoMachine to work properly, the user which is connecting must have write permissions to the user’s specific home folder. We suspect that there is a system misconfiguration, but we cannot know where. So it might be that even with XFCE, you will not be successful because of the misconfiguration of user permissions.
We will wait for the logs in any case and check them.
June 5, 2024 at 18:55 #48398JustAnotherLinuxGuyParticipantThis time I was able to resolve the permissions error. But I think we are running into the issue you were referring to with GNOME 46.
Using the
gnome-classic
command, enabled us to “launch” the VM but it errored out statingfalling back to default session
and then force closes. I changed the command tognome-session
and that gives us the option to “select a desktop” but none were listed. I have forwarded the logs to your email. Would you be so kind as to take a look and confirm if this is in fact due to using GNOME versus XFCE?June 6, 2024 at 15:39 #48414fishermanModeratorIt looks as if the application stderr is redirected so would be good if you could provide a .xsession-errors file from the user home /DV9G49/. In the logs, we can see that the application closes unexpectedly during startup.
Please also add localhost to the /etc/hosts file of the docker container as:
127.0.0.1 localhostCheck if starting the container with
--cap-add=SYS_PTRACE
can make any difference.Then, please enable logs by executing
sudo /etc/NX/nxserver --debug --enable all
, reproduce problem and collect logs as well as including .xsession-errors file.June 6, 2024 at 22:20 #48422JustAnotherLinuxGuyParticipantWe don’t user
docker run
to start the VM; it’s managed by Cloud WorkstationsSo we use a
gcloud
command to start it, another gcloud command to start a tcp tunnel, then NoMachine to log into the VM.We switched to XFCE as you suggested and we still run into an error. I have sent over the logs for review.
June 10, 2024 at 17:35 #48452BritgirlKeymasterLogs show:
1945 2016 2024-06-06 21:05:11 234.255 TcpConnector/TcpConnector: ERROR! Error is 99 ‘Cannot assign requested address’.
Error: Connection to ‘localhost:25001’ protocol ‘TCP’ failed.Did you add localhost to the /etc/hosts file as suggested by Fisherman? We will be checking installing NoMachine on GCP/Docker, also to make sure our current documentation is kept up-to-date (https://www.nomachine.com/accessing-your-remote-desktop-on-google-cloud-platform-via-nomachine) and extended.
June 10, 2024 at 22:30 #48453JustAnotherLinuxGuyParticipantYes, localhost is in the /etc/hosts profile by default. I verified, and it is there.
June 20, 2024 at 12:25 #48597BritgirlKeymasterOur initial tests show that it’s necessary to uncomment the “DefaultDesktopCommand” key in the node.cfg.
#For GNOME session:
DefaultDesktopCommand "env XDG_SESSION_TYPE=wayland dbus-run-session /etc/X11/Xsession gnome-session"
#For XFCE:
DefaultDesktopCommand "dbus-run-session startxfce4"
Maybe you could try these.
June 20, 2024 at 15:47 #48603JustAnotherLinuxGuyParticipantThanks for the info, we have decided to pursue a different route but I will keep this in mind if we decide to come back to this option.
July 9, 2024 at 03:36 #48733CRCinAUParticipantWas there ever any kind of followup for this? In my current testing with the KDE Spin of Fedora, I’ve found the following:
1) F39 clean install from the Live ISO -> NoMachine works fine
2) After running updates on F39, NoMachine no longer works with a similar error
3) F40 doesn’t work from a fresh install, or after updates have been installed.
-
AuthorPosts
This topic was marked as solved, you can't post.