Forum / NoMachine Terminal Server Products / Cannot write to .Xauthority
- This topic has 5 replies, 3 voices, and was last updated 5 years, 7 months ago by Cato.
-
AuthorPosts
-
April 16, 2019 at 16:40 #22045ArmaggedonParticipant
Hi all,
I’m using the evaluation period for testing a cluster consisting in one Enterprise Terminal Server and one Terminal Server Node using default configuration. Both are CentOS 7 and running NoMachine products version 6.5.6. KDE as desktop and properly configured on DefaultDesktopCommand setting.
Node Protocol Label Status Load-B Manual-S Weight Limit
--------------- -------- ----- ------- ------ -------- ------ -----
node:4000 NX running yes yes
localhost:4000 NX running yes yesClass Type Value
--------- -------------------------- ------
feature manual-node-selection no
feature server-clipboard yes
feature enable-profiles yes
feature enable-guest no
feature enable-multiserver no
feature enable-multinode yes
feature node-load-balancing yes
feature client-clipboard yes
feature bandwidth noSo when creating a virtual desktop on the ETS everything works like a charm. However, when selecting the TSN, I get prompted with:
The session negotiation failed.
Error: Cannot write to .Xauthority file in on the local host. Please verify permission attributes for that file.
My home directory is on my corporate network file system. .Xauthority file has the right permissions (0600) and nothing changes if I delete it: TSN is unable to create it but TSN can.
Does anyone have an idea what might be going on?
April 16, 2019 at 21:00 #22056ArmaggedonParticipantApparently I cannot edit my post… When I said TSN is unable to create it but TSN can, I meant “TSN is unable to create it but ETS can”.
April 17, 2019 at 08:02 #22049brotechParticipantHello,
Lets focus on remote node. If you have correct permissions when logging in there using SSH, please create backup of /etc/pam.d/nx and then copy /etc/pam.d/sshd over /etc/pam.d/nx. After that, try to start NX session again on the TSN.If your remote node uses pam_mount module, then this article might be helpful: https://www.nomachine.com/AR09N00902
April 23, 2019 at 15:49 #22115ArmaggedonParticipantHello brotech,
I’m a bit lost with this but I think I did it correctly. As my user could ssh normally inside the node, I overrode /etc/pam.d/nx with the contents of /etc/pam.d/sshd. Still nothing happened.
I’m not sure how the pam_mount module is configured in my organization, but just in case I followed the steps of your article (both methods) and yet nothing happens.
April 24, 2019 at 07:30 #22117brotechParticipantHello,
please enable debug, reproduce issue, then gather logs as described in article: https://www.nomachine.com/DT10O00163 and send to forum[at]nomachine[dot]comPlease ensure that mail’s subject is ‘Cannot write to .Xauthority’ so we can track properly that
issue. If you could attach also the /etc/pam.d directory, it might be useful.
To make one file which contains the whole pam.d directory, run in a terminal:
tar -zcf myownpamd.tar.gz /etc/pam.dApril 26, 2019 at 11:04 #22137CatoParticipantHello Armaggedon,
There are few possible reasons of problem with accessing .Xauthority file. Check if you can establish NoMachine session after following instructions for each of the listed scenarios separately.
1. The home directory is not mounted.
Start terminal ssh session to remote node host, to make sure that home directory is mounted.
2. Home directory is mounted, but SELinux is preventing access.
Follow this article to temporarily disable selinux or set it to permissive mode:
https://linuxize.com/post/how-to-disable-selinux-on-centos-7
3. The file has correct permission, but not the correct owner.
Make sure that the owner of the file is the same as user who attempts to establish NoMachine session.
4. There’s some difference in configuration between server machine and remote node machine.
Look for potential differences in /etc/pam.d directories on ETS and TSN.
-
AuthorPosts
This topic was marked as solved, you can't post.