Forum Replies Created

Viewing 15 posts - 91 through 105 (of 124 total)
  • Author
  • in reply to: Cannot create virtual xdm session to Solaris 10 #21145


    It seems that we need to do more debugging.

    Please edit the file:


    and add following lines:


    before the last line, so the end of this file look like:

    export NX_SYSTEM


    exec “$NXPath/bin/nxclient.bin” “$@”

    Then please reproduce the problem with connection to Solaris and send us the nxclient
    logs. This logs will be under the:


    directory, where will be a new F-M-* directory created.


    in reply to: Cannot create virtual xdm session to Solaris 10 #21099


    Unfortunately there are not really any clues in the logs, nothing specific, so we would require
    additional help to solve this problem.

    It does not seem the problem is connected directly with the target Solaris OS, but it is local.

    First there is the failure of client –monitor, could you provide with logs from the nxclient?

    For the session in your previous logs they will be in the

    /home/domain/pozard/.nx/F-M-<hidden hostname>-13002-1B89DA468E176ABD25A2E2829A087C7F

    then we would need agent logs, for the same session they should be in:

    /usr/NX/var/log/node/F-C-<hidden hostname>-1002-FE980136BA5DA062CC519F72B5CBC494

    Then some questions:

    1. It seems that there is Kerberos configured on this system, could you check if there are any errors for the user ‘pozard’?

    In the logs we have an error regarding that ticket, but the user directory access seems to be working so it may or may not be related.

    2. When you say the XDM to Ubuntu server works, did you also use user ‘pozard’? If no, please check what happens.

    3. When you try the failed session, are there any other NoMachine sessions for user ‘pozard’ running?


    in reply to: Always create a new display on this server #19651


    Unfortunately it is impossible to do what you described on the free version. We only allow for one session to run, so to be able to switch users sessions you would need to terminate before logging out, log in with another user and click “Yes”, or have the proper desktop environment running, where desktop manager can take care of user switching.

    “Always create a new display on this server” is also not an option, because it will only allow for one user to have this session, and it will be always started when the NoMachine is starting.



    So from the messages file there is this from NX:

    Jun 27 06:18:43 rgs05 nxnode[40980]: WARNING! Process ‘/bin/bash -c exec -a – /bin/bash -c ‘/etc/gdm/Xsession gnome-session” with pid ‘41015/41015’ finished with exit code 1 after 12,906 seconds.
    Jun 27 06:18:43 rgs05 nxnode[40980]: ERROR! Session application terminated abnormally

    So we can rule out NX processes generating problem on their own.

    There can be two things to cause problems here:

    1. The session wrapper ‘/etc/gdm/Xsession’. Please check if there was any modifications done to this file that could point to any problems.

    2. User ‘vr044’ configuration. Could You check any unorthodox changes in this user configuration files? Especially if they are connected with gnome-session, so around in .config/gnome* or /.gnome* in this user home directory.


    in reply to: Connection with Microsoft account #18926

    Hello hastur18.

    Unfortunately we cannot help here without the logs from server side.
    You can find instructions about debug and collecting logs here:

    Please enable the logs in server.cfg and node.cfg, then just to be sure we have everything
    covered restart the NoMachine server: You can do it from NoMachine Monitor GUI. Then please
    repeat the connection and send the logs to forum[at]nomachine[dot]com referring post topic in mail subject.


    in reply to: NoMachine refuses to re-attach to physical session #18902


    Sorry for the late answer…
    Yes indeed it should be working just with that, there have to be something more.

    So first things, there are two different problems there:

    1. NX cannot make physical session available.
    2. NX fails to run desktop on demand (virtual session).

    we need to handle both of those problems separately.

    Problem one I’ve only seen once in the logs, then every other attempt was only NX trying to
    start desktop on demand, so to reproduce this, please do the following:

    1. Please make sure the key ‘CreateDisplay’ in server.cfg file is set to 0 and uncommented.
    2. Please make sure the key ‘SessionLogLevel’ in both server.cfg and node.cfg is set to 7 and uncommented
    3. Do

    # /etc/NX/nxserver –restart

    4. When connecting with player and asked if it should create new desktop, please select “No”.
    5. If the session list is empty, please wait a moment in case it takes longer to run.
    6. Please send us the logs in /usr/NX/var/log/ directory. Preferably all of them.
    7. Please check the system logs in the case the nxnode process is crashing, we would like to
    receive what is logged or backtrace if present.

    I hope this will give us some hint on both problems, so we would tackle the starting of virtual session next.




    So the nxserver.log is empty because of the configuration key EnableSyslogSupport
    is set to 1 in both configuration files.
    If this is the case, please provide us with the logs from the system log file accessible
    via the standard syslog interface (e.g. in /var/log/syslog, can depend on configuration).

    This logs can be identified by nxnode and nxserver nametags.




    I do not know what happened, but the nxserver.log file inside the archive you sent us
    is completely empty. Can you check what happened there and send us the logs again
    with reproduced problem?

    Please also send us the configuration files server.cfg and node.cfg from the server machine
    to help investigating. Also if this user that is experiencing problems have his own
    node configuration file (<username>.node.cfg), please send it too.

    And question: is this user having any other processes running on this server that
    can interfere with starting desktop environment? Like another desktop environment inside
    a virtual frame buffer? If yes please tell us which ones.




    Free version of NoMachine does not support creation of virtual session except for creating one
    default on demand where no physical sessions are available, but according to the logs you provided in
    it also fails in your environment, so please continue with the previous topic.


    in reply to: NoMachine refuses to re-attach to physical session #18766


    Unfortunately there are still more questions and no answers there in logs.

    From nxerror.log most notable entries are:

    free(): invalid pointer
    nxnode.bin: malloc.c:4030: _int_malloc: Assertion `(unsigned long) (size) >= (unsigned long) (nb)’ failed.

    so it looks like the nxnode process is crashing.

    It seems to be something caused by operating system specific reason. Maybe you can think of some
    specific configuration there that can interfere with starting processes? Maybe something in pam.d
    configuration or user-specific limits? We are using pam.d/nx configuration file that base on su.
    Maybe there is something in pam.d/su that can cause problems, so if it is modified, please send us
    what changes were made and which modules were added. Also there could be a hint in system log file
    /var/log/auth.log – please look for ‘pam_unix(nx:session)’ entries.

    Going back to nxnode process crash. There should be a hint for this in /var/log/syslog file or similar.
    If operating system is configured to leave core files after crash we would be grateful for a backtrace
    from all threads. If not, You can try configuring nxnode to run with valgrind to help us find the problem.
    Please refer to our article at on how to set up NX to work
    with Valgrind.


    in reply to: NoMachine refuses to re-attach to physical session #18445


    Regarding the logs you sent us, there is a new behavior different to the previous problems: nxexec process when starting node for desktop owner crashes. There are a few things to check:

    1. In logs there are two instances: nxexec with pid 21223 and 21316. Is there any sign of nxexec or nxnode processes crashes in system logs?

    2. Is there any indication of problem in our nxerror.log file. This file is located in ‘/usr/NX/var/log’ directory by default and is important part of logging. You can also send us this file for investigation. Also please check if SessionLogLevel in node.cfg file is also set to 7 as I cannot see any node logs and am not sure if the process is started or crashes on runtime.

    3. Please check the access rights to ‘/usr/NX/bin/nxexec’ file. they should match:

    Access: (4555/-r-sr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)

    4. Please check if nxnode works properly. You can check it with

    /etc/NX/nxnode –version

    If there are any errors please send us the logs again.


    in reply to: Information on the black screen problem #18434


    apologies for the late reply. I thought I had answered, but had left my message cached instead of posting on the day of you previous followup.

    So there are basically three problems there.
    First you seem to have run into a known bug with Xserver, when NoMachine queries for
    information before physical session is started, the Xserver will get confused and not let
    the physical session to be started. So the only solution is to keep the checkLocalSessionDelay
    key on default – removed or commented.

    Second, because of that problem, our session finding has to be delayed, and it is also a known problem, if someone tries to login before the session finding is complete, there will be a query sent to the player connecting to start new desktop. This is what happens in your logs. 5 seconds after NX
    startup, there is a connection with answer “yes” to creating new desktop. The proposition here
    is to answer “no” and wait for physical session to be detected.

    And this come to a third problem, which is black screen after selecting “yes”, this also should not happen.

    From the logs, what is started is ‘/etc/X11/Xsession default’ which exits after 6 seconds with no errors
    visible in our logs. This may be related with first problem, but we have not enough data to follow on this.
    Is there any problems in system logs during this time? There may also be something in .xsession-errors file in users home directory.


    in reply to: NoMachine refuses to re-attach to physical session #18420


    This is what I see in logs:

    1. nxserver –daemon process is started, probably after system restart.
    2. It tries to detect any running Xserver, but the command ‘netstat -ln –protocol=unix’
    does not list any proper sockets.
    3. Our virtual Xserver is started automatically and no more attempts to find Xservers are made.
    4. Two login attempts are made, but no attach.
    5. nxserver –restart is invoked and new server –daemon starts.
    This time server detects two running Xservers on displays :0 and :1.

    On display :0 we have running ‘gnome-session-binary –autostart /usr/share/gdm/greeter/autostart’ – so it is Login Window
    On display :1 ‘gnome-session-binary’ – it is users desktop.

    When queried about sessions, operating system answers that session on display 0 is inactive and on display 1 is active.

    6. The attach is being made to a proper session, but it seems to hang and is terminated after around 90 seconds.

    So there are two problems:

    First the virtual session that is being created after system startup. Probable culprit is the order of starting services in system. NoMachine is started before Xserver is finished, and it is causing problems. This can be mitigated by disabling automatic session creation in the server.cfg file. Please set the key ‘CreateDisplay’ to 0, and nxserver will wait for the Xserver to run
    or it will ask during player connection if such session should be started.

    The second is the hanging during attach. There is unfortunately no clue in the logs provided, so we will require additional data.
    We would need client side logs from the logging attempt when player is hanging. Please refer to the point about client logs from this article and send them to us like previously.


    in reply to: Information on the black screen problem #18316


    It is a very strange behavior indeed. Please help us to understand this problem.

    First question, is that machine headless or runlevel 3? If not, which desktop environment
    and desktop manager is in use? Also if they are running on Xorg or Wayland.

    Second question is: on that problematic machine in


    configuration file, do you have uncommented entry

    CreateDisplay 1

    This may cause a problem if the Xserver on the machine starts slower than NoMachine.
    If that’s the case, please check if DefaultDesktopCommand key in


    points to a proper session command or set CreateDisplay key to 0.

    Next question is, what changes on that machine during this 30 seconds, do
    physical sessions stay in login window, or there is automatic login to user’s desktop

    Last thing you can try to add a key to server.cfg file:

    checkLocalSessionDelay 0

    and check if this help.

    If everything fails, please provide us with full logs. You can find instructions about debug and collecting logs here: Please send them to forum[at]nomachine[dot]com referring post topic in mail subject.




    The problem seems to be that NoMachine cannot detect running physical session and its starting
    its own virtual session. If it is nomachine-6.0.66-2.x86_64 package on Fedora 26 the most probable
    cause is Wayland. As stated here:

    NoMachine only recently released a version that supports Wayland, so if that’s the case an update
    is advised.

    You can also follow the tips here on how to disable Wayland:

    If this is not the case, we will need further information to properly debug this problem:

    – What system/desktop environment processes are running for the logged user/login window screen.
    – nxserver.log from nxserver startup. We would need only logs from nxserver –daemon process, so no logging required.


Viewing 15 posts - 91 through 105 (of 124 total)