graywolf

[graywolf]

Hello. I guess your client switched to mode “Resize remote screen”. Unlocking the desktop doesn’t look related. By the way, you can turn it off easily, without restarting the client: use the kystroke “Ctrl+Alt+0” to access the NoMachine menu, and unlock the button “Resize remote screen”. Also look at “Fit to window”.

Attachments:

1. 

   buttons.png
   

[graywolf]

But sometimes, in a way i can’t explain, NoMachine, after having asked me the login password on his wizard, connect me directly using by default Gnome 3 desktop (wrong behaviour)

Is it possible you had a previously started Gnome session on the remote host? In that case the greeter window is not presented, you’ll get the running session directly. By the way, that is the way Gdm (or any display manager, generally) works, it is not related to NoMachine configuration.

[graywolf]

Would you paste the output of command:

sudo -l -U <username>

and upload the content of $HOME/.nx folder?

[graywolf]

Hello. Someone is preparing that list.
Meanwhile, would you:
– tell me what you get with command sudo -l -U <username>
– send me the folder $HOME/.nx from your server

[graywolf]

Hello. Would you tell me if users’ home folders are remotely mounted by NFS? That could be related because settings panel could get troubles retrieving confi files.

[graywolf]

Try a little change to the command:

DefaultDesktopCommand "env DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u)/bus startkde"

[graywolf]

It looks that dbus-daemon in Arch Linux exits immediately if not launched from a terminal. Rather that using dbus-launch, you could run a systemd user daemon using some tweaks.

1. Create a backup of nx PAM configuration (sudo cp -a /etc/pam.d/nx /etc/pam.d/nx.original). Then change /etc/pam.d/nx in this way:

auth       include       system-login
account    include       system-login
password   include       system-login
session    include       system-login

2. Change DefaultDesktopCommand in /usr/NX/etc/node.cfg in order to remove dbus-launch –exit-with-session:

DefaultDesktopCommand "startkde"

3. Stop display manager:
sudo systemctl stop display-manager

4. Restart NoMachine:
sudo /etc/NX/nxserver --restart

[graywolf]

It is possible that compatibility list is out of date as I didn’t find the card.

[graywolf]

dbus-launch or startkde (look at the command defined by DefaultDesktopCommand key in /usr/NX/etc/node.cfg) failed to start (actually they terminated after just 2 seconds).

Browse for the application log in files /usr/NX/var/log/F-*/clients and in the systemd journal (try the command journalctl -b -0 | grep -i "kde\|dbus").

[graywolf]

Yes, it looks correct: in the latter case you get lower compression rates.

[graywolf]

We’ll fix it in NoMachine.

About the font server issue, check the current font path in the remote session by command xset q, then try add font server to path, e.g.:

xset fp+ unix/:7100 (font server on localhost, Unix socket)

xset fp+ tcp/10.0.0.1:7100 (font server on remote host 10.0.0.1, TCP)

[graywolf]

Command localectl set-x11-keymap fr would set the Xorg keyboard layout to French (automatically creating the config file /etc/X11/xorg.conf.d/00-keyboard.conf).

[graywolf]

Are you using NoMachine to create a virtual display on the server or to share an existing display?

How can I check this ?

User Ctrl+Alt+0 to access the menu, chose “Connection” to view session info, check the “session type” field.

[graywolf]

So the physical keyboard is set to French while virtual to US. I can’t explain how that occurred. If you like to investigate further you can look into /var/log/Xorg.0.log. By the way, I’d try to fix it by setting French layout in Mate configuration: as the setup looks unique it is supposed to be applied to all keyboards.
Setting French layout in a purposely created config file in xorg.conf.d could be a solution as well.

[graywolf]

I think that physical keyboard has correct layout (French) while virtual keyboard used by NoMachine has US layout. Run a terminal emulator in MATE and type

xinput list

The list of avaialble input device is shown, e.g.:

~$ xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Logitech Performance MX                 	id=10	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Power Button                            	id=7	[slave  keyboard (3)]
    ↳   USB Keyboard                          	id=8	[slave  keyboard (3)]
    ↳   USB Keyboard                          	id=9	[slave  keyboard (3)]

You can see that “Virtual core XTEST keyboard” has id number 5. Pass that number to the -i switch of command xkbcomp to query the keymap:

~$ xkbcomp -i 5 -xkb $DISPLAY - | grep "xkb_keycodes\|xkb_types\|xkb_compatibility\|xkb_symbols\|xkb_geometry"
xkb_keycodes "evdev+aliases(qwerty)" {
xkb_types "complete" {
xkb_compatibility "complete" {
xkb_symbols "pc+us+inet(evdev)" {
xkb_geometry "pc(pc105)" {

Then repeat for your physical keyboard id and compare results.

Please take a look of input device settings in /etc/X11/xorg.conf and /etc/X11/xorg.conf.d. Dump Mate keyboard-related configuration:

gsettings list-recursively | grep -i "keyboard\|xkb"

[Author]

Posts