Update cannot recognize administrative password

Forums / NoMachine for Linux / Update cannot recognize administrative password

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #31775
    johngalt17
    Participant

    Hello,

    I run NoMachine in my home LAN to communicate between two PC’s, both running Linux.  The connection runs flawlessly over my LAN.  However, NoMachine popped up a message requesting to update the software, and after starting this, it asks for my administrative password.  That password has never changed and is the exact same one I used when I installed the NoMachine server and client.

    This is the result of sudo -l:
    root@KerryPC:/usr/NX/var/log# sudo -l
    Matching Defaults entries for root on KerryPC:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/<wbr />usr/local/bin\:/usr/sbin\:/<wbr />usr/bin\:/sbin\:/bin\:/snap/<wbr />bin

    Runas and Command-specific defaults for root:
    Defaults!/sbin/service jellyfin restart, /usr/sbin/service jellyfin restart !requiretty
    Defaults!/sbin/service jellyfin start, /usr/sbin/service jellyfin start !requiretty
    Defaults!/sbin/service jellyfin stop, /usr/sbin/service jellyfin stop !requiretty
    Defaults!/usr/bin/systemctl restart jellyfin, /bin/systemctl restart jellyfin !requiretty
    Defaults!/usr/bin/systemctl start jellyfin, /bin/systemctl start jellyfin !requiretty
    Defaults!/usr/bin/systemctl stop jellyfin, /bin/systemctl stop jellyfin !requiretty
    Defaults!/etc/init.d/<wbr />jellyfin restart !requiretty
    Defaults!/etc/init.d/<wbr />jellyfin start !requiretty
    Defaults!/etc/init.d/<wbr />jellyfin stop !requiretty

    User root may run the following commands on KerryPC:
    (ALL : ALL) ALL
    root@KerryPC:/usr/NX/var/log#
    root@KerryPC:/usr/NX/var/log# more nxerror.log
    384375 384375 15:53:07 589.849 Redis: Server started, Redis version 3.0.7.
    384375:signal-handler (1611960787) Received SIGTERM scheduling shutdown...
    384375 384375 15:53:07 691.444 Redis: User requested shutdown....
    384375 384375 15:53:07 691.489 Redis: Saving the final RDB snapshot before exiting..
    384375 384375 15:53:07 697.385 Redis: Redis is now ready to exit, bye bye....
    384738 384738 15:53:08 807.046 Redis: Server started, Redis version 3.0.7.
    384738 384738 15:53:08 807.359 Redis: DB loaded from disk: 0.000 seconds.
    384738 384832 15:53:11 023.107 ServerNetworkInfoHandler: WARNING! Obtaining network data failed with result -7.
    384738 418263 19:10:17 845.232 ServerNetworkInfoHandler: WARNING! Obtaining network data failed with result -7.
    384738 994116 19:29:52 253.482 ServerNetworkInfoHandler: WARNING! Obtaining network data failed with result -7.
    384848 384848 19:30:32 325 handleSigterm: Received SIGTERM.
    384738:signal-handler (1612146635) Received SIGTERM scheduling shutdown...
    384738 384738 19:30:35 437.455 Redis: User requested shutdown....
    384738 384738 19:30:35 437.510 Redis: Saving the final RDB snapshot before exiting..
    384738 384738 19:30:35 449.145 Redis: Redis is now ready to exit, bye bye....
    384738 384738 19:30:35 450.471 HostDescriptorClose: WARNING! Descriptor FD#43 is invalid.
    2831 2831 19:31:44 144.322 Redis: Server started, Redis version 3.0.7.
    2831 2831 19:31:44 145.329 Redis: DB loaded from disk: 0.001 seconds.
    2831 4697 19:33:08 145.449 ServerNetworkInfoHandler: WARNING! Obtaining network data failed with result -7.
    2831 199148 11:49:23 714.015 ServerNetworkInfoHandler: WARNING! Obtaining network data failed with result -7.
    2831 199488 11:49:32 495.833 ServerNetworkInfoHandler: WARNING! Obtaining network data failed with result -7.
    2831 281295 17:42:05 910.141 ServerNetworkInfoHandler: WARNING! Obtaining network data failed with result -7.
    2831 296532 19:16:33 610.815 ServerNetworkInfoHandler: WARNING! Obtaining network data failed with result -7.
    2831 577171 19:34:20 228.092 ServerNetworkInfoHandler: WARNING! Obtaining network data failed with result -7.
    2831 577227 19:34:20 496.070 ServerNetworkInfoHandler: WARNING! Obtaining network data failed with result -7.
    root@KerryPC:/usr/NX/var/log#

    This the result of $HOME/.nx/*/session:
    384851 384851 2021-01-31 19:30:33 747.831 NXNODE   WARNING! libnxh::NXConnectLocal cannot connect to localhost:25001: Connection refused from NXClientMonitor::<wbr />sendTerminateMessageToNxMonito<wbr />r.
    384851 384851 2021-01-31 19:30:33 748.368 NXNODE   WARNING! Process '/usr/NX/bin/nxclient --monitor --pid 7322' with pid '384870/384870' finished with exit code 1 after 185844,346 seconds.
    3847 3847 2021-02-04 18:52:28 290.715 NXNODE   WARNING! Process '/usr/NX/bin/nxexec /usr/NX/scripts/restricted/<wbr />nxupdate.sh kerry background ask /var/NX/nx/.nx /home/kerry/.nx/node/C-<wbr />KerryPC-1001-<wbr />1825FAA4A8D7CA4407387283AD2903<wbr />B5/authority :0' with pid '1171268/1171268' finished with exit code 255 after 10645,579

    As a result of the above, your update script repetitively fails to authenticate my administrative password.

    What steps can I take to resolve this and achieve successful password authentication that will satisfy your update script?
    Many thanks for your help!

    #31824
    Britgirl
    Keymaster

    Can you send us the whole server-side folder $HOME/.nx ? Please zip up the file and send to forum[at]nomachine[dot]com using the title of your topic as the subject. Thanks!

    #32133
    graywolf
    Moderator

    Hello johngalt17.

    Those logs are insufficient to determine the nature of the problem. Please run the interface to change settings on your server, select “Player settings”, “Security”: in that pane check the box “Don’t delete log files on exit”.

    Then reproduce the problem, collect the complete log on the server by command sudo /etc/NX/nxserver --debug --collect.

    #32202
    lmcjoma
    Participant

    I have had exactly the same problem for about six months, first on Fedora31, and even now after upgrade to Fedora33. I am running the free version. Right now I am on the verge of throwing out NoMachine altogether, but I’ll give it another chance. Everything I have tried has failed, and googling the problem brings on useful results.

    What I don’t understand is why you want logs from the server side, when what we have clearly is a software update problem on the client side. At the moment I don’t even have a server, since I upgraded my it and deemed it useless to re-install NoMachine there until this problem is solved.

    Another question is what you mean with “a user with administrative rights”? Is it enough with a user with passwordless sudo access (me), or does it have to be root? I did of course try both, with no success.

    Anyway, here is some info about my environment, and I also attach some logs that you may find useful.

    XXX@fenrir ~]$ sudo -l
    Matching Defaults entries for XXX on fenrir:
    !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL
    QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER
    LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

    User XXX may run the following commands on fenrir:
    (ALL) ALL
    (ALL) NOPASSWD: ALL
    (ALL) NOPASSWD: ALL
    [XXX@fenrir ~]$

    Thanks,
    lmcjoma

    #32215
    Carin
    Participant

    Hi lmcjoma,

    The log files failed to attach, maybe because they are too big.

    “What I don’t understand is why you want logs from the server side, when what we have clearly is a software update problem on the client side.”

    Provided the issue is on the client-side, then it would be useful if you could send us client-side logs. Please see the following article for guidance: Collect server and client logs manually.

    Can you please send them directly to forum[at]nomachine[dot]com making sure you use the title of the topic in the subject of your email? Thanks!

     

    #32302
    lmcjoma
    Participant

    I posted the files as instructed over a week ago. Any news on this?

    ///jon

    #32312
    Carin
    Participant

    Hi lmcjoma,

    we would like to send you a test program. Would you mind running that program in order to collect more debug logs?
    Please let us know and we will send it via email.
    Thanks!

     

    #32319
    lmcjoma
    Participant

    Sure, no problem. As long as it is not a binary.

    #32371
    Carin
    Participant

    Hi lmcjoma,

    We understand your concern. The program is a binary, however it is just a modified version of the nxexec binary, so it should not represent an issue. The procedure will be to simply replace the original nxexec with the test one, reproduce the problem and collect logs.
    Let us know if this would be ok for you and we will send you the test program via email.

    #32576
    lmcjoma
    Participant

    Ok. Please send me the program, and I will try it.

    #32624
    Carin
    Participant

    I’ve sent you the program to download with instructions. Check your inbox 🙂

    #34360
    Carin
    Participant

    Logs received, so the topic has been reopened.

    #34363
    Carin
    Participant

    Hi lmcjoma,

    we took a look at your logs but we could not find the debug messages.

    Did you manage to replace the old nxexec with the new nxexec-test file, that we sent you via email with the instructions?

Viewing 13 posts - 1 through 13 (of 13 total)

Closed because the user did not provide further feedback. Please notify us if you confirm that it is resolved or open a new topic if you have the same problem.