Forum Replies Created
-
Posts
-
Hello,
for sure NoMachine is using /usr/NX/etc/node.cfg as a configuration file where DefaultDesktopCommand could be set.
Could you give a little more information about your configuration?
Are you using the NoMachine free product ? Verify by running a command /etc/NX/nxserver –version. E.g.,/etc/NX/nxserver –version
NoMachine – Version 5.1.44Is MDM working and do you get the login window ? If yes then you need to focus on MDM setup and select desktop kind using MDM’s menu (press letter M in top-right corner of login box) because xfce4 is started by MDM and NoMachine allows access to the physical DISPLAY whatever is running on it. So, there is no DefaultDesktopCommand in use.
Any problem or errors related to session run should be in /home/USERNAME/.xsession-errors file.
Hello, NoMachine (free version) gives access to physical desktop limited to
1 connection at the same time.So if you have any kiosk-mode application run as current desktop then attached user will have available only that application.
Hello Xaint,
I was able to reproduce similar problems when I installed ‘xfce4-session’ using apt.However after I installed meta-package xfce4 and both commands which you used work correctly out-of-box. I tried /etc/X11/Xsession xfce4-session and it works also.
b.
There is no a automatic way to terminate idle sessions at the moment, so we’re evaluating whether to insert a Feature Request into our roadmap.
You could set DisablePersistentSession “username” key in server configuration file, but then every network disconnection of that user will terminate a session, which doesn’t seem to be helpful in your case.
# Disable persistent sessions for users. If the option is followed by
# the keyword ‘all’, no user is allowed to run persistent sessions. Al-
# ternatively, the option can be followed by a list of comma-separated
# usernames. The default value is the empty string which corresponds
# to disabling persistent sessions for no user. The values specified
# override the values set for the ‘EnablePersistentSession’ key.
#
#DisablePersistentSession “”By default NoMachine sets: #EnablePersistentSession all
Alternatively, you could try switching the –timeout values for ‘AgentExtra’ key, and ‘DisconnectedSessionExpiry’ , so decrease the value for disconnect on idle, and increase the time how long session could be disconnected. Again, it’s not optimal, but it might help.
Hello Pnnord,
the reason of that behaviour could be the same UUID on remote nodes (appserver34, appserver35) which could happen if one is a clone of another. You can verify it for example looking in /usr/NX/var/log/nxserver.log file which provide an extended description, e.g.,2016-09-20 17:38:19 973.162 21624 NXSERVER ERROR! Cannot add node ‘appserver34:4000’: node ‘appserver35:4000’ with the same UUID 174be7e5-388f-40fe-8adc-46220c78ab49 already exists in database.
In that case, there is a solution here for it in the following forum post:
Hello,
it seems that you don’t have a desktop environment installed, or nxnode doesn’t find it.
In this case, this article could be helpful: ‘How to solve error ‘Cannot find the default environment’ on Linux headless machines’ (https://www.nomachine.com/AR06N00891)If you have a correct and existing command set in DefaultDesktopCommand
key in node.cfg, then please enable logs in server and node, restart the server
and connect using the client.Reproduce problem, collect logs and send them to forums[at]nomachine[dot]com using
“Unable to access remote centos 7 server” as e-mail’s subject.The procedure to collect logs is available here: https://www.nomachine.com/DT07M00098
Regards
Hello,
so far we were not able reproduced problem using Scientific Linux 6 in its default installation with desktop, regardless whether ipv6 is enabled or disabled.Could you provide more info about what SL you’ve installed exactly, or if you’ve customize it in any way? For example the output of rpm -qa (all installed packages) could help us replicate the same environment. Are you using any Display Manager or just starting desktop using startx command ?
Then please consider re-enabling debug, restart nxserver and send to us logs again after display 0 became available. The logs you sent to us before don’t contain debug of daemon server which is searching and reporting local X server.
Please look for the current working authority file of Xserver using command: ps -ef | grep X
Among parameters of that process should also be -auth userhome/.serverauth.pidUse path to that file in following command, executed from command like:
xauth -f userhome/.serverauth.pid listIt should report all cookies set and in use by current Xserver, and it is likely we can see the cause of the problem from that.
Please attach also output from /sbin/ifconfig command, and content of /etc/hosts.
You are using NoMachine product which support only NX connection methods (it doesn’t support SSH).
About access to the .serverauth, NFS prevent to access file as root which seems to be a reason
of that issue. Please verify ownership of the .serverauth file, and configuration of NFS.Likely option no_root_squash in NFS configuration is needed, for allow to local root account
access a filesystem exported by NFS. Note that this is insecure which is a reason that in default
configuration NFS has it disabled.Hello Tim,
we received logs, and seems that problem is related to your network configuration.Could you share with us your /etc/hosts file ? Could be through mail again as in case of logs.
We were not able to reproduce this problem on CentOS 7.2.1511. Could you enable logs in server and node configuration file, restart nxserver, reproduce the problem and then send to us whole /usr/NX/var/log directory to forum[at]nomachine[dot]com or attach them here (size is restricted).
Instructions about debug and collecting logs you can find there: https://www.nomachine.com/DT04M00076.
Please update NoMachine server to the latest version, and if problem persists, could you enable logs in server and node configuration file, reproduce the problem and then send to us whole /usr/NX/var/log directory to forum[at]nomachine[dot]com or attach them here (size is restricted).
Instructions about debug and collecting logs you can find there: https://www.nomachine.com/DT04M00076.
/b.
It seems that nxserver found Xorg but the problem is with reaching cookie of it.
In particular system xauth reports warning and exits with code 1:
/usr/bin/xauth: /home/users/weigand/.serverauth.9074 not writable, changes will be ignoredIts very likely a problem with wrong SELinux context to this .serverauth.9074 file.
To verify current context you can use command:
ls -Z /home/users/weigand/.serverauth.9074
To set correct context you can use this command:
chcon -Rv unconfined_u:object_r:xauth_home_t:s0 /home/users/weigand/.serverauth.9074
We were not able to reproduce this problem on SL 6.5. Could you enable logs in server and node configuration file, reproduce the problem and then send to us whole /usr/NX/var/log directory to
forum[at]nomachine[dot]com or attach them here (size is restricted).Instructions about debug and collecting logs you can find there: https://www.nomachine.com/DT04M00076.
We were not able to reproduce this problem on Debian 4.0.4-1+kali2. Could you enable logs in server and node configuration file, reproduce the problem and then send to us whole /usr/NX/var/log directory to forum[at]nomachine[dot]com or attach them here (size is restricted).
Instructions about debug and collecting logs you can find there: https://www.nomachine.com/DT04M00076.
Hello,
please take a look at /LibraryLogs/DisagnosticReports directory for nxexec’s crash report, and send to us. If you’re not able to find the crash report, information about location of such report is stored in /var/log/system.log.
We’ve started an investigation regarding support for Centrify. This could be provoking this weird behaviour in nxexec.