fisherman

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 248 total)
  • Author
    Posts
  • in reply to: NoMachine scanning range #50889
    fisherman
    Moderator

    NoMachine cannot autodetect devices on the other network segment, but there is a workaround that you can implement on the router.

    To implement a workaround for this issue, the user must have network administrator privileges. They need to configure an mDNS forwarder, repeater, or proxy on the router, provided the router supports this feature.

    This is necessary due to a fundamental limitation of the multicast protocol: each subnet uses the same multicast DNS address (224.0.0.251), which is not shared across subnets. For example:

    • Subnet 192.168.1.0/24 uses the local mDNS address: 224.0.0.251
    • Subnet 192.168.0.0/24 also uses the local mDNS address: 224.0.0.251

    Without mDNS forwarding or proxying, devices in one subnet cannot discover or communicate with devices in another subnet via multicast.

    fisherman
    Moderator

    On NoMachine port 5353 is the broadcasting port, so you can not check it the way you tried. NoMachine uses NX port 4000 by default, or SSH port 22 for any enterprise product.

    Please try the following steps:

    1. Check accessibility:
      Use Telnet to test if either port 4000 or port 22 is accessible on the server:
      192.168.1.17 4000
      or
      telnet 192.168.1.17 22
    2. Verify network routes:
      Ensure that your client’s subnetwork can access the server’s subnetwork, or confirm that the correct routes are in place to enable connectivity between the client and server.

    Let me know if you need further assistance.

    in reply to: NxFrameBuffer error while starting #48414
    fisherman
    Moderator

    It 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 localhost

    Check 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.

    in reply to: NxFrameBuffer error while starting #48385
    fisherman
    Moderator

    Removing 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.

    in reply to: NxFrameBuffer error while starting #48372
    fisherman
    Moderator

    I 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

    in reply to: NxFrameBuffer error while starting #48364
    fisherman
    Moderator

    Upon 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.

    in reply to: Never resize remote screen #47865
    fisherman
    Moderator

    you can change PhysicalDesktopMode 1 in the /usr/NX/etc/server.cfg file

    extracted part from the server.cfg file with explanation what each mode is doing:

    # Set the interaction level for the session connected to the physical
    # desktop:
    #
    # 0: View-only. The session is connected to the desktop in
    #    view-only mode, i.e. the user can't interact with the
    #    physical desktop.
    #
    # 1: Restricted. User connected to the physical desktop can
    #    interact with the desktop except for resize operations.
    #
    # 2: Interactive. User connected to the physical desktop has
    #    full interaction with the desktop.
    #
    #PhysicalDesktopMode 2
    in reply to: List session details – idle time #47861
    fisherman
    Moderator

    Can you check nxserver --history if it gives you the details you need.

    I extracted usage from the nxserver --help

    --history
      [--verbose]
      [ --file <file>]
      [<sessionid>|<username>|clear]
      [--client-type] [--client-version] [--client-platform]
      [--stats]
    in reply to: HTTP proxy with password authentication #45476
    fisherman
    Moderator

    I tried today to install openresty, but I could not succeed to correctly configure it to work as normal http proxy. I was getting that proxy was refusing my connections.

    Can you verify if you can use your current proxy server  in your browser to access other websites?

    in reply to: HTTP proxy with password authentication #45461
    fisherman
    Moderator

    Is it possible to provide openresty configuration sample?

    you can send it to forum[at]nomachine[dot]com mentioning forum topic name.

    in reply to: The sound on the server is broken #45387
    fisherman
    Moderator

    Please can you try to change key AudioInterface in node.cfg
    AudioInterface pipewire

    and then restart NoMachine server using
    sudo /etc/NX/nxserver --restart

    in reply to: SSH is working fine, but not able to connect via NoMachine #45347
    fisherman
    Moderator

    If you are using NoMachine free version, you will not be able to use SSH protocol. When you try to connect with SSH you will receive message in player

    Running NoMachine sessions over a SSH connection is not supported on this server. Do you want to switch your connection to using the NX protocol?

    If you would like to use SSH, please use some of NoMachine enterprise products.

    in reply to: No available desktops on this server #44808
    fisherman
    Moderator

    There was upload error, can you send log file to to the forum[at]nomachine[dot]com?

    in reply to: No available desktops on this server #44799
    fisherman
    Moderator

    We still did not have full logs, as I have missed to ask after enabling debug logs to restart server and then to reproduce problem. Please can you redo it and then provide us with logs.

    sudo /etc/NX/nxserver --debug --enable all
    sudo /etc/NX/nxserver --restart
    in reply to: No available desktops on this server #44780
    fisherman
    Moderator

    Hello,

    It seems that what you mentioned “The Centos7 workstation is not connected to a monitor” could play a role in the problem that NoMachine does not detect it as available session, and when NoMachine tries to create new display, that request fails as there is already display number used.

    Logs from the server side would be useful. Enable debug on the CentOS 7 machine, reproduce the problem and then gather up the logs.You can send them to forum[at]nomachine[dot]com making sure to use the title of the topic as the subject of your email.

    sudo /etc/NX/nxserver –debug –enable all
    sudo /etc/NX/nxserver –debug –collect
    sudo /etc/NX/nxserver –debug –disable all

    I could propose workaround to try so NoMachine will create new display with a new display number.
    Please edit /usr/NX/etc/node.cfg by enabling key PhysicalDisplays :3 .

Viewing 15 posts - 1 through 15 (of 248 total)