Forum Replies Created

Viewing 15 posts - 106 through 120 (of 124 total)
  • Author
  • Mth


    This problem may be caused by the server.cfg key ‘EnablePersistentSession’
    Please make sure that username ‘user’ is listed there, or it is set to the default ‘all’
    value or commented. Valid key values for this case would be:

    EnablePersistentSession user
    EnablePersistentSession all
    #EnablePersistentSession <any_value>

    I can see no hint of it in logs, but please also make sure that the key
    DisablePersistentSession does not list this ‘user’.

    Please let us know if this does not help with the issue.


    in reply to: Disable authorize connections to remote desktop #18140


    Such behavior is expected when trying to attach, when different user is already connected.

    On the free version of NoMachine it is only allowed for just one connection at once, so if there is one
    connection established, NoMachine will ask current user to disconnect and give 15 seconds to answer.
    If no answer is made the old session should be disconnected regardless.

    To disable this you can enable config key AutomaticDisconnection and set it to 1:

    AutomaticDisconnection 1

    It will cause old sessions to be always disconnected immediately even when different user is logged in.

    Please let us know if it solved the issue or if another behavior is observed or expected.


    in reply to: Errors with 6.0.78 on Ubuntu 16.04 #17507


    It seems that you have two problems here.

    First one is:
    The session negotiation failed.
    Error: Agent was not initialized properly.

    This we have reproduced and it is connected with the Xvfb process:
    dslaybac 22939     1  0 Jan30 ?        01:45:10 /usr/bin/Xvfb :25 -screen 0 1280x1024x8

    NoMachine doesn’t support 8bit color, so any attempts to attach to such desktop will always cause
    agent not to be initialized. Changing to 24 bits should help here.

    Second problem is that the nxexec –node –user lightdm process crashes with 11. We would need some more data to help with this. Can you check if the operating system is generating crash file for these and provide us with backtrace of core dump? Also the process is running with parameters:

    ‘/usr/NX/bin/nxexec –node –user lightdm –priority realtime –mode 0 –pid 12’

    Can you tell us what is this process designated with –pid parameter – 12 in this case. We would need command line and environment for this process. Also can you confirm the operating system is in the login window state?

    If not, it could be a cause for a problem as we are detecting that login window session is running here.

    If there is no core dump for this case, please provide us with full logs to forum[at]nomachine[dot]com. You can find instructions about debug and collecting logs here:


    in reply to: Stopped working in Ubuntu after reboot #17303


    Thank you for cooperation in this matter. Can you please try attaching from the problematic machine to itself using nxplayer?

    Please use the ‘NX’ protocol and ‘localhost’ as the host name in nxplayer application.

    Please check if something changes in those circumstances and send us the logs from after this attempt as you did in your first post.

    in reply to: Stopped working in Ubuntu after reboot #17270


    The first thing that comes to mind after seeing the logs is the problem with localhost entry in /etc/hosts file.

    NoMachine uses localhost to connect locally via loopback device, so please make sure the localhost entry points to a loopback address, for example the line in /etc/hosts could look like this:  localhost

    Please let us know if this does not help. If it doesn’t, more info about your network configuration would be useful, such as content of /etc/hosts/ and output of ifconfig.

    in reply to: NoMachine Workstation: excessive size of logs #16276


    There is nothing wrong with this logs itself, as they are part of the search for physical session. The problem here is probably the amount of sessions registered in systemd – which IDs are reaching 28760 here. Systemd has information there stored for every open session that goes through pam (physical desktop sessions, ssh sessions, nx sessions also). So as long as it is proper, this behavior is also proper. If the number of sessions is wrong, it may be indication of systemd problems, so please check if the number is right, as this information should be cleaned when the session closes.

    For this log size I can propose two solutions.

    First, you can disable offending function. If you do not need access to physical desktop on that machine, you can edit the “AvailableSessionTypes” key in server.cfg and remove “physical-desktop” item.

    Second, you can pass server logs to syslog by uncommenting and enabling “EnableSyslogSupport” key in server.cfg:

    EnableSyslogSupport 1

    and then enable autorotate in /etc/syslog.conf as you see fit.

    in reply to: Connections when H.264 installed fail #14008

    Thank you for contacting us with this problem.

    Unfortunately we can not determine where the problem is. To help us find it, we need more
    information. Please follow this steps:
    1. Shut down the NoMachine by running:
    # /etc/NX/nxserver –shutdown

    2. Ascertain there is no leftover NoMachine processes by running:
    # ps -ef | grep nx
    If not sure, please send us the list of processes.

    3. Please gather the result of commands:
    # ls -l /usr/NX/etc
    # ls -la /usr/NX/var/db/running

    4. Start the NoMachine by running:
    # /etc/NX/nxserver –startup

    5. If the problem repeats please attach to the nxserver –daemon process with strace program.
    You can get the pid of valid process by running:
    # ps -ef | grep nxserver | grep daemon

    Please attach the results of this commands here.

    in reply to: Cannot find default environment after TR09N07188 fix #13401


    It seems that the problem lies in DefaultDesktopCommand key from node.cfg.

    Please find this key in the /usr/NX/etc/node.cfg file. By default it should look like:

    DefaultDesktopCommand “/usr/bin/dbus-launch –exit-with-session startkde”

    You need to change the startkde to full path to this program eg:

    DefaultDesktopCommand “/usr/bin/dbus-launch –exit-with-session /usr/bin/startkde”

    If this does not help please edit the /usr/bin/startkde file by adding

    set -x

    line at the start.

    Then please make sure that the SessionLogClean key in /usr/NX/etc/node.cfg
    is uncommented and set to 0.

    SessionLogClean 0

    reproduce the problem and send us the logs again.

    in reply to: Cannot find default environment after TR09N07188 fix #13189


    It seems the server has trouble with finding working display. Can you give us
    the output of:

    # lsof -a -c Xorg -U

    And if it gives any output, also:

    # /bin/netstat -ln –protocol=unix

    # ls /tmp/.X11-unix/

    If the output include any sockets named like


    please make sure that netstat has access rights on at least 755.

    If not, there is a possibility that Xorg server has disabled listening on unix sockets, which are vital for connecting via NoMachine. Are you aware of any changes made in this regard? (any changes
    in system configuration files, startx script etc.)

    in reply to: Cannot find default environment after TR09N07188 fix #13082


    First of all, it seems that there is something wrong with configuration files.
    Can you please send us whole /usr/NX/var/log directory along with /usr/NX/etc/server.cfg
    and /usr/NX/etc/node.cfg for investigation?

    To fix it please try a clean installation – uninstall, remove the /usr/NX directory then install again.

    If this does not help, please enable the logs as described here:
    then do /etc/NX/nxserver –restart as administrator and send us the /usr/NX/var/log directory.

    Also it would help to debug the source of problem if you include the output of

    ps awwxo uid,ppid,pid,sid,comm,args

    when logged on to desktop.

    Please send the logs to forum[at]nomachine[dot]com referencing the post topic in the mail title.

    in reply to: Frame buffer on server not started: nxFrameBuffer aborted #12856


    It seems that the server has every session type disabled and this causes the connection problems. Please edit the server configuration file:


    and make sure that key


    is uncommented and it includes both nxvfb and physical-desktop entries.

    For example working key for free version should look like this:

    AvailableSessionTypes nxvfb,physical-desktop

    If modification is required, please restart nxserver (as administrator user)

    /etc/NX/nxserver –restart

    and try connecting again.

    If this does not help, please enable debug and submit logs.
    Instructions are available here:

    Please include the configuration files:

    Send them on to forum[at]nomachine[dot]com making sure to reference your topic.

    in reply to: Cannot detect any display running #11819


    The most probable cause for this problem is that Fedora 23 uses Wayland instead of X server. NoMachine is not yet compatible with Wayland, so disabling it is the only way to fix it.

    By default Wayland is enabled on Login Window, to disable it for GDM, please edit


    And under the tag


    make sure the only line containing WaylandEnable field is:


    Please let us know if it helps, or if the problem persists after disabling Wayland.

    in reply to: Automatic disconnection on one side #10516


    With logs provided, the problem is hard to debug, to handle it we would require
    more data.

    Please set in the node.cfg:

    SessionLogClean 0

    Also it seems, that master agent hangs in this case, so please add this line at the
    bottom in the server.cfg:

    dumpCoreOnHang 1

    This will cause the server to kill node with signal 11 instead of 9, so please make sure
    the system can handle core dumps.
    After this please restart the nomachine server:

    /etc/NX/nxserver –restart

    Reproduce the problem and send the server and node logs as previously. We would also
    require the full agent logs, so please include the full:



    When the problem is reproduced, please do:

    /etc/NX/nxserver –restart

    again so, if the Agent hanged, the system produce core report for nxnode process. We would
    require the backtrace of all threads. The instruction is available here:

    Also include the logs from client machine: .nx directory in user’s home.
    In case of uncertainty please consult article on collecting logs:

    Send all logs on to forum[at]nomachine[dot]com making sure to reference your topic in message title.

    And some finishing questions: have you tried to log in as different user than root? Do the same problems happen?
    Also is the machine you are trying to connect to on user desktop or Login Window?



    To analyze your problem further we need more information.

    Can you enable debug and submit logs to forum[at]nomachine[dot]com? Instructions are available here:

    Also, do you have any desktop manager or Xserver configured on this machine or is it a headless Linux? If it is not headless, we would also require output of ‘ps -ef’ command or details about graphic environment configured there.

    Please reference your forum topic when sending the logs.



    It seems that the problem you have encountered most likely is caused by a corrupted nodes.db
    configuration file.

    During uninstall procedure we save the backup configuration files in /usr/NX/etc directory, so
    reinstalling will preserve this problem. The safest option is to uninstall NoMachine, make sure
    the /usr/NX/etc/nodes.db.backup file is removed, then install again.

    You can also edit /usr/NX/etc/nodes.db.

    The file should look like:


    The problem will occur when first entry is different from “running”.

Viewing 15 posts - 106 through 120 (of 124 total)