kubaszym1

[kubaszym1]

Hi,

Unfortunately this issue is hard to reproduce. If it was a NAS or network share drive, our service could have a problem with finding the drive on your computer. But it’s a standard drive so it’s hard to guess what is wrong. Can you tell me what is your setup exactly? I mean the Linux distro and the Windows version that you use.

Soon we’ll release NoMachine 8.5, maybe the issue will disappear after update. Meanwhile I’ll try to reproduce this issue with a setup similar to yours.

Regards,

Kuba

[kubaszym1]

Hi,

I think I discovered what is wrong. It’s likely caused by whitespace characters in the name of the mounted disk. Try to share a disk with a different target name, i.e. “root_on_player” or “root_on_server”, or simply just delete whitespace characters. It should work for now. I will handle this issue, so the “whitespace problem” should disappear in the upcoming version.

Regards,

Kuba

[kubaszym1]

Hi,

Please check this directory: C:/ProgramData/NoMachine/var/log. If there is a file called nxtrace.log, it means that one of NoMachine’s processes crashed. The information from nxtrace.log would be very useful for further investigation.

This warning multiplies because NoMachine monitors drives’ list in a loop – it probably occurs in each iteration. You can also check nxfs.log which is located on your Linux server (because you share from a Windows to a Linux) in ~/.nx/nxdevice/D-<display>-<session-ID>/disk/. There might be some errors from our sshfs client. This process starts when you click to share a drive.

If something crashes on Linux server, core files will be located in /var/crash.

Can you share a drive from the Linux server to your Windows client machine? If you can’t do that as well, you can look for nxfs errors in C:/Users/<username>/.nx/nxdevice/D-<display>-<session-ID>/disk/nxfs.log

I hope this will help. Let me know if you discover new information.

Regards,

Kuba

[kubaszym1]

Hi,

We recently added some changes to handle PipeWire better in physical sessions. They will be present in upcoming version. Although you should be able to hear audio in physical session with your NoMachine version and configuration. Here are some things to check:

1. Check if you are able to use pw-cli. If you don’t have pw-cli for some reasons, NoMachine chooses to connect to pulseaudio, assuming that you don’t have pipewire installed. pw-cli should be installed by default, together with PipeWire.

2. If NoMachine tries to connect to pulseaudio, it creates unix sockets in .nx/nxdevice/D-*/audio/. These sockets are called cli.socket and native.socket. In the upcoming version they don’t exist if you use PipeWire as your audio server, but I’m not sure how this works in the current release version . They are removed while disconnecting, so please connect to your server and go to the directory .nx/nxdevice/D-<display>-<session-ID>/audio.

I hope this will help somehow. I would appreciate any information, maybe I will need to fix something in the part of our code that checks what audio server is used.

Kuba

[kubaszym1]

Hi,

Do you have access to the drive that you want to share? Error 87 is a WinAPI error that indicates invalid parameters.  In this case it is probably the path of the directory. This directory can be drive name (like C:, when listing drives) or some folder name (creating/removing directories). NoMachine checks if the directory is empty. It can return failure if the user doesn’t have permissions to the given directory.

What are you trying to share? Is it a standard C or D disk or something else?

Regards,

Kuba

[kubaszym1]

Hi, I analyzed the logs you had sent. For some reason NoMachine is trying to connect to pulseaudio instead of pipewire. Can you check if you have pactl and/or pw-cli commands installed? If you have pactl installed, please run pactl info. If PipeWire is used, there should be a line like this:

Server Name: PulseAudio (on PipeWire 0.3.x)

If pulseaudio is used, it will look like this:

Server Name: pulseaudio

Also, don’t worry that you have AudioInterface pulseaudio. This is right for your current version. What is more, CommandStartPulseAudio is used only for virtual sessions.

[kubaszym1]

Hi,

Here’s what you can try:

This command should show you the reason of the issue (run it after reboot):

sudo kextutil -nt /System/Library/Extensions/nxaudio.kext

The command below may help you to solve it:

sudo kextcache -prelinked-kernel /System/Library/PrelinkedKernels/prelinkedkernel /System/Library/Extensions/nxaudio.kext

To make sure whether .kext is added to the prelinked kernel:

strings /System/Library/PrelinkedKernels/prelinkedkernel | grep nxau

Please check if something is different after a reboot. If ‘sudo kextcache …’ doesn’t help, please send me the output of ‘sudo kextutil -nt /System/Library/Extensions/nxaudio.kext’

[kubaszym1]

Hi,

Kernel extensions should be loaded automatically by the OS. I’m still not sure whether your issue is caused by the OS or by NoMachine.

You can make sure that SIP is disabled by running:

csrutil status

Moreover, I would like to see some logs. Please set the log level to ‘9 – Debug’ and restart NoMachine server, then reboot your computer and load nxaudio.kext manually.

I would like to see .nx/nxserver.log, .nx/nxerror.log, and you can also send me this folder: /Library/Application Support/NoMachine/var/log

Send everything to forum[at]nomachine[dot]com, with the topic as reference in the subject field.

[kubaszym1]

Hi,

It’s hard to say what happened at first glance, so I would need a crash report. In the Console app you should find some crash reports or diagnostic reports. Also, I would like to know if it happens before or after kextload, so it would be nice if you reproduced the issue.

Please send all the log files as attachments.

[kubaszym1]

Hi,

Unfortunately there’s nothing more I can do. I found out it depends on the functionalities that your audio driver supports. There is a small chance that updating drivers might help you, but it’s not for sure.

[kubaszym1]

Hi,

You can try to workaround this issue by plugging in an external device, i.e. headphones to your Windows machine. Then connect to the Windows machine via NoMachine and check if everything works as expected. I hope it will help you. I’m still trying to find out why capturing audio doesn’t work with several drivers.

[kubaszym1]

Hi,

There is a way you can temporarily fix it. Our test team found that setting NoMachine Microphone Adapter as the default device fixes the issue but it shouldn’t work that way. Microphone adapter is for sending voice from the client to the server. We’re now trying to investigate why this happens on Windows.

[kubaszym1]

Hi,

Try to run it in recovery mode:

1. Turn off your computer.

2. Turn on your computer in recovery mode

3. Run the command /usr/sbin/spctl kext-consent add 493C5JZAGR as before

4. Restart your computer

If you don’t know, how to start up you Mac in recovery mode, check here: https://support.apple.com/en-us/HT201255

[kubaszym1]

Hello,

You can try this command:

/usr/sbin/spctl kext-consent add 493C5JZAGR

If it still doesn’t work, please send me any notifications you will get.

[kubaszym1]

Hello,

You can check if NoMachine kernel extensions are in the kext policy database:

sudo sqlite3 “/var/db/SystemPolicyConfiguration/KextPolicy” “SELECT * FROM kext_policy;” | grep nomachine

Please send us the result of this command.

Also, do you use any Mobile Device Management like JAMF?

[Author]

Posts