Forum / NoMachine for Linux / Update cannot recognize administrative password
- This topic has 12 replies, 5 voices, and was last updated 3 years, 5 months ago by Carin.
-
AuthorPosts
-
February 8, 2021 at 12:58 #31775johngalt17Participant
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 />binRunas 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 !requirettyUser 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,579As 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!February 8, 2021 at 16:22 #31824BritgirlKeymasterCan 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!
February 24, 2021 at 11:22 #32133graywolfParticipantHello 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
.March 2, 2021 at 11:42 #32202lmcjomaParticipantI 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\:/binUser XXX may run the following commands on fenrir:
(ALL) ALL
(ALL) NOPASSWD: ALL
(ALL) NOPASSWD: ALL
[XXX@fenrir ~]$Thanks,
lmcjomaMarch 2, 2021 at 12:45 #32215CarinParticipantHi 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!
March 9, 2021 at 10:08 #32302lmcjomaParticipantI posted the files as instructed over a week ago. Any news on this?
///jon
March 9, 2021 at 10:13 #32312CarinParticipantHi 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!March 9, 2021 at 17:09 #32319lmcjomaParticipantSure, no problem. As long as it is not a binary.
March 12, 2021 at 10:50 #32371CarinParticipantHi 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.March 24, 2021 at 17:10 #32576lmcjomaParticipantOk. Please send me the program, and I will try it.
March 26, 2021 at 11:53 #32624CarinParticipantI’ve sent you the program to download with instructions. Check your inbox 🙂
July 6, 2021 at 13:07 #34360CarinParticipantLogs received, so the topic has been reopened.
July 7, 2021 at 09:58 #34363CarinParticipantHi 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?
-
AuthorPosts
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.