Forum Replies Created
January 24, 2018 at 13:45 in reply to: Disk forwarding error: Failed to connect the disk D: #17302
Thanks for the additional info. We still haven’t been able to reproduce the problem replicating your set-up and configuration. It might be a configuration problem of your environment.
What we can do is send you debug binary files which you can install, then reproduce error and submit a full set of logs.
To do that, reply here or submit an email to forum[at]nomachine[com] notifying us that you wish to receive this package. We will send you instructions as well.
/mushroomJanuary 4, 2018 at 09:02 in reply to: Disk forwarding error: Failed to connect the disk D: #17055
Ok, we got the logs.
There are some errors in there but nothing about disks.
Do you have possibility to connect from other machine?
Also can you try reverse mounting:
1) Connect from Windows to Centos, and export disk from Centos to Windows.
2) Connect from Centos to Windows, and import disk from Windows to Centos (so mounting would be on Centos side).
Some helpful logs can be on client side also.
To check player logs on windows go into:
And try to reproduce the issue.
Do you have our official NoMachine server installed or some other derivative?
/mushroomJanuary 3, 2018 at 13:54 in reply to: Disk forwarding error: Failed to connect the disk D: #17049
We tried to reproduce the issue in our labs, but everything is working.
Few more questions, so we can work this out:
Did you check other session logs in folder /usr/NX/var/log/node/ ?
Can you paste here output of that command:
$ sudo df
Also do you have full access to that Desktop folder, like creating folders, changing names?
Did you try to follow instructions in article about enabling disks on Centos, which we provided before?
One more thing is to switch Selinux off for testing only, you can do it with that command:
$ sudo setenforce 0
Enabling it again with:
$ sudo setenforce 1
If issue will still occur then could you send us server logs from active session?
In my previous answer i send you link how to do it.
/mushroomJanuary 3, 2018 at 10:07 in reply to: Disk forwarding error: Failed to connect the disk D: #17042
We would need some more information from you to resolve this issue.
First of all you can check if there are any errors in Session log on server side.
From my understanding you are connecting from Win 10 to Centos 6, which mean server is Centos.
Session logs are in path:
$ /usr/NX/var/log/node/”generated folder”/session.log
That “generated folder” is created each time you create session and deleted after you close it (removing is set up by default, You can change that in settings).
Best way would be if you connect to that Centos, recreate issue and check session log in most recent folder.
If there will be nothing helpful in there, you can follow this article (its common issue):
Enabling disk service
Also article which explain how to collect logs:
How to collect logs.
Those error message could be given for various reasons and we have few steps that will help to solve this problem.
1) First you can try to change name in “Export as” field.
This is name of the folder which inside would be mounted disk.
Change to something that doesn’t exist, because we don’t want to overwrite anything.
2)Second its possible your account doesn’t have enough permissions to create directory on macOS, so make sure you have it. Try to create new folder there.
3) Another reason could be that on installation something went wrong with drivers from disks.
On Windows (even when its Client machine) its very important to restart computer when prompt come out on installation. Its important because otherwise drivers are not correctly installed.
On macOS (Server machine) its important to allow NoMachine to install “third party drivers”.
If those prompt was missed, you can check it under System Preferences -> Security & Privacy tab.
*its possible to check it in less then 30 minutes after NoMachine installation.
To list driver loaded on macOS use command:
$ kextstat | grep nx
You can get similar result as:
$ kextstat | grep nx
116 0 0xffffff7f80fcd000 0x5000 0x5000 com.nomachine.driver.nxau (4.1.b2) 78172556-B6A4-3112-BA41-E79D18108476
Nxau is NoMachine audio driver, its loaded all the time. If its missing then installation went wrong, and system blocked our drivers. However, you can load it yourself.
First shutdown nxserver:
$ sudo /etc/NX/nxserver –shutdown
Load kext file:
$ sudo kextload /System/Library/Extensions//nxaudio.kext
Now new window could appear on macOS with information about third party drivers.
Then you can check it under System Preferences -> Security & Privacy tab, and allow to load/install those drivers.
Last, start nxserver:
$ sudo /etc/NX/nxserver –startup
Now you should have nxau when you list kext files.
Nxfs is driver from disks. If nxfs is missing you can connect from Windows to macOS and try to export disk from Windows to macOS, and then run kextstat command. Now it should appear.
$ kextstat | grep nx
168 0 0xffffff7f832c7000 0x5000 0x5000 com.nomachine.driver.nxau (4.1.b2) 78172556-B6A4-3112-BA41-E79D18108476
170 0 0xffffff7f832cc000 0x12000 0x12000 com.nomachine.kext.nxfs (4.1.b1) BFEE045F-718B-31CD-AA31-0E114A139EB3
Thats mean that driver is ok. If nxfs.kext is missing that you can load it manually like before, but
its in other place:
$ sudo kextload /Library/Application\ Support/NoMachine/Extensions/nxfs.kext
And now you should see nxfs.kext driver.
Also do you have problems with sharing other devices?
Or maybe something is not working on specific machines?
We also got helpful articles:
NoMachine Installation Guide
If above commands don’t help, please gather logs:
How to collect logs.
This instruction work on NoMachine 6 version as well. Any logs can be sent to forum[at]nomachine[dot]com
/mushroomNovember 7, 2017 at 15:56 in reply to: NoMachine inside docker – resource sharing doesn’t work #16337
In order to fix compilation error of USB module you should follow instruction in this Article:
If this instruction will not work, can you provide us output of make command?
And –cap-add=SYS_PTRACE is needed for normal functioning of nxserver.October 31, 2017 at 13:25 in reply to: NoMachine inside docker – resource sharing doesn’t work #16251
Thank you for information, we will investigate this issue in our labs.
There may be some services that don’t work because of Docker limitations.
For example, USB sharing needs the driver in order to work.
It would be helpful if you could send us server side logs, which are in:
/usr/NX/var/log on your server machine.
Also some useful information are stored in session logs – /usr/NX/var/log/node.
For example if you don’t have Cups installed, printing will not work and that information would be in those logs. Send to forum[at]nomachine[dot]com.
If you copy a file using drag&drop feature or “Download a file from the server” from NoMachine tray menu – timestamps are not kept and you cannot copy folders but by using drag&drop you can copy multiple files.
If you mount disk to or from server and copy files in file browser, or by ctrl+c ctrl+v, timestamps are kept and you can copy folders. Folders do not keep timestamps, but files inside them do.
If you want to use only drag&drop or copying from server, you can pack folder into an archive and copy that archive. That way you can copy whatever you need and keep the timestamps.
After investigation we found out that source of that problem is nautilus itself.
To be more specific nautilus + mounted disk from windows. It can affect various file browsers and few text editors.
Nautilus has a specific way to overwrite files, which is not always compatible with overwriting files on mounted devices.
It’s a known bug affecting multiple Ubuntu users and unfortunately it’s not solved yet.
You can track it here:
From our side we cannot provide solution for your problem other that you already found out :
– replacing files through console
– deleting and then coping files through file browser.
We already have opened Trouble Report with that case and our developers are working on it.
You can track everything here:
According to logs that you have provided, we can see there is some problem with desktop on local server. We have got a topic with a very similar problem:
Since it’s headless, can you make sure you followed the instructions outlined here?
Maybe you have problem with the Fedora firewall – SElinux. You can try to set it on permissive mode just for test.
Setting Selinux on permissive will disable SElinux, but everthing will still be logged into the SELinux log, which is in: /var/log/audit/audit.log .
Command to set Selinux on permissive:
To revert it back:
To check Selinux status :
You will need admin authorization to do this.
It also would be nice if yoo tell me what connection are you trying to use: NX or SSH?