Mth

Forum Replies Created

Viewing 15 posts - 46 through 60 (of 124 total)
  • Author
    Posts
  • in reply to: Server doesn’t start on Windows 10 #25909
    Mth
    Contributor

    Hello

    From the logs you provided the reason seems to be here:

    2020-03-10 13:03:06 012.355  8568 NXSERVER WARNING! Process 'c:\apps\nomachine\\bin\\nxexec --server --upnpstatus' with pid '9152/812' finished with exit code 1 after 0,015 seconds.
    
    9152 1328 13:03:06 012 nxexecExecServer: ERROR! Only nxnode or nxserver can run --server command.
    9152 1328 13:03:06 012 nxexecExecServer: ERROR! Cannot execute nxserver process.
    Error code is : 0.^M
    9152 1328 13:03:06 012 main: ERROR! Error: Server exec failed.

    This is a bit of a puzzler, the path c:\apps\nomachine\\bin\\nxexec clearly exist, it is
    clearly executed by nxserver, but the nxecec cannot recognize it.

    The problem could be a result of bad installation, did you choose c:\apps\nomachine during the installation, or it was copied afterwards?

    There is also a file ‘c:\ProgramData\NoMachine\nxserver\localhost\server.cfg’,
    could you confirm that in this file a key “ServerRoot” is set up to point to the installation directory?

    /Mth

    in reply to: Unable to start the server in a chroot environment #25853
    Mth
    Contributor

    Hello

    The problem indeed is that the nxserver cannot open any socket to listen on. It should not be the fault on the NoMachine side,
    at least not in normal circumstances. You should be able to find more clues in nxerror.log file – if the system reports a reason,
    or in the operating system logs.

    Please check if there is any clue to this within the Ubuntu logs, or the parent system logs – most probably it is because of how the chrooted system is set up, the parent OS is blocking any attempts to open a socket.

    If there is nothing wrong in the system logs, please elaborate more about the system setup and how did you exactly set up the chroot environment.

    We may need to reproduce the problem to handle it.

    /Mth

    in reply to: Problems with NoMachine in docker #25730
    Mth
    Contributor

    Hello.

    The logs shows that every instance of nxexec process is being blocked.
    Most commonly there are problems with apparmor blocking the docker container.
    We have a document on this topic:

    https://www.nomachine.com/DT10O00161

    Please check the troubleshooting part of that document.

    There also can be a problem with the privileges on the container, sometimes
    it is also required to add

    --privileged

    parameter to docker run command.

    If the article does not help you, please check if there is anything in the system logs
    of the parent operating system that could be relevant to starting any nx processes,
    any access blocking, termination etc. Also please share the Dockerfile and the command
    you use to start the container for us to debug.

    /Mth

    Mth
    Contributor

    Hello

    Sorry for the confusion, the proper command would be:

    sudo /etc/NX/nxserver --debug --collect

    This command should point you to the generated archive, like:

    NX> 900 Archive is: /usr/NX/var/log/archives/NoMachine-log-2020.02.12-10.28.14.zip

    Please send this archive and the ‘su’ file to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

    /Mth

    in reply to: Ubuntu password not working #25562
    Mth
    Contributor

    Hello

    There are a few things to check:

    1. In /usr/NX/etc/server.cfg what are the values of keys EnableUserDB and EnablePasswordDB?
    Are they commented?

    If they are commented or set to 0 it means the NoMachine will use
    system authorization to authenticate users. Skip point 2 and go to the point 3.

    2. If both this keys are set to 1, NoMachine is using the internal password database
    to authenticate users. please use command

    # /etc/NX/nxserver --passwd <username>

    to set new password and try again.

    3. To rule out the simplest mistake, please check if you can use the username/password to login into system.

    4. To check for NoMachine authorization problems please run

    /usr/NX/bin/nxexec --auth

    and use the Username and password used for failed connection. Please provide us
    with output.

    5. Please check the NoMachine log files for errors/warnings connected with the user login
    Files are /usr/NX/var/log/nxserver.log and /usr/NX/var/log/nxerror.log.

    6. Please check the system log file – for ubuntu it should be /var/log/auth.log – for any errors connected with failed login.

    /Mth

    Mth
    Contributor

    Hello.

    Unfortunately NoMachine logs cannot be read by a normal user, even if the directory
    rights are proper. You will need sudoer or root account to access and copy them.
    You can also use the command

    etc/NX/nxserver --debug --collect

    to make NoMachine collect and package them itself, but this command also requires
    the sudo/root access.

    As for the pam.d directory, it is not NoMachine configuration, but rather system
    configuration, so it will not be in ‘/usr/NX’, but in system directory ‘/etc’.

    /Mth

    Mth
    Contributor

    Hello.

    For now it seems the problem is not with Xvfb, but with the NoMachine processes and docker itself.
    It seems we want to make this display visible, but every process dies with exit code 1.

    First we need to check if the container is properly run. We have a document on this topic:

    https://www.nomachine.com/DT10O00161

    Most commonly there are problems with apparmor blocking the docker container from running
    processes using nxexec. Please check the troubleshooting part of that document.

    There also can be a problem with the privileges on the container, I found that on one specific machine
    with Mint I need to add –privileged parameter to docker run command.

    If the article does not help you, please check if there is anything in the system logs that could
    be relevant to starting any nx processes (any access blocking, termination etc.). Also please share
    the Dockerfile and the command you use to start the container. With this it should be easy for us
    to reproduce the problem to find a solution.

    /Mth

    Mth
    Contributor

    Hello.

    The player logs had nothing really meaningful, so I think we need the server side logs here.

    Please check the system logs. For mint system the /var/log/auth.log should
    say if the logging attempt was blocked by the system (entries for nx:auth).

    Also as the nx service uses su module for authorization, please provide us the /etc/pam.d/su module
    configuration. Also please note that if authorization uses Kerberos tool, you need to specify it before
    connecting in the player (connection details -> advanced).

    And at last please provide the NoMachine server logs. As your server is on Linux, please refer to point
    ‘1.1. Server on Linux’ of the article
    https://www.nomachine.com/DT10O00163

    Please enable logs, try to connect and then gather the logs. Send them to us just like before.

    /Mth

     

    Mth
    Contributor

    Hello

    The problem here is a bit complicated. As you said, setting PhysicalDisplays key to ‘:10’ prevents the NoMachine from detecting your true desktop (which probably is on display :0, :1 or :1024 if you are using Wayland).

    Then, as you say NoMachine is creating its own Xserver and starting the session there.

    So now you have ‘physical session’ and ‘virtual session’ working on your system, so even when you unlock it on physical screen, it will not affect virtual.

    The problem is however with virtual session and lock screen. It is a known issue with the new way gnome handles the sessions, and how it interacts with NoMachine virtual sessions, and right now unfortunately there is no solution, except for disabling the lock screen on the virtual session.

    /Mth

    Mth
    Contributor

    Hello

    I’m sorry, this forum seems to change double “-” signs to this big “–” when not written in code tags. The commands to use are:

    sudo /usr/NX/bin/nxserver --useradd <username>
    sudo /usr/NX/bin/nxserver --passwd <username>

    But it seems this does not matter in this case.

    I’m sorry I have not noticed before, but on that screenshot you sent you are in a completely wrong page.

    This is not an connection attempt to the remote machine. This is an attempt to change settings on the server for the local machine.
    If you click on this “lock icon” and the “Changes disabled”, you should get prompt for the local administrator account and password to enable the
    settings changes, same if you try to change anything.

    I am really not sure what is the case here, but to connect to another machine please use “New connection” instead of “Service status”
    screen from the monitor tray icon, or use ‘nxplayer’ application.

    /Mth

    Mth
    Contributor

    Hello

    First thing about NoMachine config, the information you got is correct, when you set it like that:

    #EnableUserDB 1
    #
    EnablePasswordDB 1

    Even if you change the EnableUserDB key to 1, the whole line is still treated as comment line and ignored. You need to get rid of ‘#’ character for config line to be parsed.

    Second, at the bottom of the config file, the Section “Server” and Section “STUN” are only when you are connecting to the server using web interface (usually through a web browser) and not NoMachine player application. And for standard usage the modifications here are usually
    not required.

    Also if you are using free version, the HTTP protocol is disabled, so those fragments can be simply ignored.

    Then for the config file backups, I’m afraid there is no way to restore it in easy way. We provide some generic cfg.sample files, but the main .cfg are created during the installation procedure depending of operating system configuration. In other words, you can restore some of the keys by comparing
    .cfg to .cfg-sample files, but the most important ones have to be created on installation.

    And for the problem. Part of it of course may be that currently you have EnableUserDB key commented and by default it is set to 0. Although when EnablePasswordDB is set to 1 it should not provide the problem with login.

    First what does EnablePasswordDB do. If it is set to 0, you can connect to the NoMachine server using any user account that is on that operating system by providing its username and system password.
    When you set it to 1, by default you will not be able to connect at all.

    So by doing ‘sudo /usr/NX/bin/nxserver –useradd *****’ you have provided the NoMachine database with the user.
    When doing so you should have been prompted by the:

    nxserver --useradd test
    NX> 906 Setting password for user: test.
    NX> 251 Password:
    NX> 102 Confirm password:
    NX> 110 Password for user 'test' has been added to the NX password DB.

    And now, as long as EnablePasswordDB is set to 1, you need to provide this new password to connect.

    There is a problem though, if you added that user before setting EnablePasswordDB to 1, there would have
    been no new password prompt, and the user would not have its NoMachine password provided.
    You would need to do the useraddd command again to fix it.

    There is one exception to this, when using SSH connection protocol you still need to provide system password as per the SSH configuration, then after this you will be again prompted by the NoMachine password question.

    So for now please try those things:

    1. Remove the ‘#’ from server.cfg ‘#EnableUserDB 1’ line.

    2. Run ‘sudo /usr/NX/bin/nxserver –useradd <username>’ again and see if you have password prompt, if yes, please
    provide it and use that password to login. Be sure you are using NX protocol.

    3. If still no use please run ‘sudo /usr/NX/bin/nxserver –passwd <username>’ and set new password again, just to rule
    out there was no typos, and use that password to login.

    4. If it still does not work, please set in server.cfg

    EnableUserDB 0
    EnablePasswordDB 0

    And try to login using the system credentials.

    5. If that attempt also fails, there may be more to this problem, and we would like to see the logs as there might me unexpected bug behind this.

    Article on how to collect logs:

    https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

    Please enable the debug and then try to login again and send the logs to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

    /Mth

    in reply to: Unable to connect to Windows from Mac #25136
    Mth
    Contributor

    Hello

    The logs you provided suggests there is something wrong with the IP address or port you are trying to connect to.

    When you say “There are 2 IPs listed” do you mean the addresses provided by the player application from “My machines” view?

    Since you are using vpn there is always a possibility that NoMachine did not list every network interface and the valid IP is simply not there. Could you ascertain which IP is proper for the target machine and use the “add new connection” in the player application to provide the valid address?

    If the connection still does not work like that, please check if there is nothing blocking the 4000 port on the target machine. You can also try to change the protocol used during the connection from the NX to SSH (from connection details menu) this will also change port used to connect to
    22 (if you are connecting to linux/osx) or 4022 (for connections to Windows).

    Also on the target machine please check if the nxd process is running and also for any errors/warnings in the NoMachine logs. Most likely place would be nxd.log and nxserver.log.

    /Mth

    in reply to: No sessions available on Ubuntu #25087
    Mth
    Contributor

    Hello

    From the logs it seems that there is a problem with installation. We have:

    /usr/NX/bin/nxnode.bin: symbol lookup error: /usr/NX/lib/libnxdiag.so: undefined symbol: deyaultPoi9terContSol

    There are no nxinstall or nxupdate logs included, so I am not able to tell, but was it a clean installation? Maybe there was some directories left from previous one?

    The log suggests some kind of modified, old or broken libraries present, so right now the only thing to do would be a clean installation.

    If you have version free or evaluation, it is probably safe to ignore points 1, 5 and 6 of this instruction.
    It is only relevant if you have received custom license files from us or using modified configuration files.

    1. Backup all the modified files from /usr/nx/etc directory (important to keep .lic files if you are a customer
    with custom license and .cfg or .db files when modified)
    2. Uninstall NoMachine.
    3. Remove /usr/NX, /etc/NX and /var/NX directories if they still exist.
    4. Install NoMachine.
    5. Restore backed up licenses as per https://www.nomachine.com/AR11O00942 article.
    6. Restore backed up cfg and db files.

    Please let us know if it helped, or if the issue persists after reinstall.

    /Mth

     

    in reply to: Can’t connect to headless server using Windows 10 #24876
    Mth
    Contributor

    Hello.

    First to clarify, when referring to the ‘nxserver’ command, on Linux systems by default the full
    path is either:

    /etc/NX/nxserver

    or

    /usr/NX/bin/nxserver

    Then to the problem itself. The popup window ‘A configuration error has been encountered. Please contact your administrator.’
    right now it can only be displayed during starting of a session when the ‘.ICEauthority’ file for the user that is starting
    session has wrong owner.

    You can confirm that this is the problem by checking the ‘/usr/NX/var/log/nxserver.log’ file.
    The warning too look for is:

    WARNING! The /root/.ICEauthority file has wrong ownership.

    If this is the case please make sure that the file noted in that warning has proper ownership set,
    in this case it should be:

    stat /root/.ICEauthority
    File: '/root/.ICEauthority'
    Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root)

    If the access rights are wrong you can modify them by running:

    # chown root:root /root/.ICEauthority
    # chmod 0600 /root/.ICEauthority

    If this still does not help, please share any warnings/errors from ‘/usr/NX/var/log/nxserver.log’ and
    ‘/usr/NX/var/log/nxerror.log’ files.

    /Mth

    Mth
    Contributor

    Hello.

    First lets rule out the easy stuff.

    There could be two issues here:

    1. When on “no sessions available” screen, please make sure the view is set to “All desktops”.

    2. Please make sure the user you are connecting with is marked as an administrator for NoMachine.
    On licenses other than Enterprise Desktop we have something called “restricted access” to physical desktop, and the user has to be specifically marked as administrator to have full access to Login Window and desktop sessions.

    If the user account has already been used to access NoMachine, please use:

    /etc/NX/nxserver --useredit username --administrator yes

    if not, please use:

    /etc/NX/nxserver --useradd username --administrator yes

    And try to connect again.

    If this does not help please gather logs for investigation.

    As it is Catalina, please gather information from the MacOS system log, preferably by running:

    # cat /var/log/system.log | grep -e nxserver -e nxnode -e nomachine >> system.debug

    and

    /usr/bin/log show --debug | grep -e nxserver -e nxnode -e nomachine >> log.debug

    Also please collect NoMachine logs.

    Article on how to collect logs:

    https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

    Please include the system.debug file and send them to forum[at]nomachine[dot]com using the title of
    that forum’s thread as the mail’s subject.

    /Mth

Viewing 15 posts - 46 through 60 (of 124 total)