kubaszym1

[kubaszym1]

Hi,

I’m not sure how well our support for pipewire will work when server address is set to “tcp:…”. What happens when you change it to “unix:native”? Everything else in your configuration seems fine. I only wonder about this:

Connection failure: Connection refused
pa_context_connect() failed: Connection refused
875407 875723 2023-05-15 10:27:47 954.177 AudioProxyCore: Cannot check whether PulseAudio or PipeWire is used.

In AudioProxyCore we call “pactl info” in order to determine whether pulseaudio or pipewire is used. It seems that the command failed when called from NoMachine. The message “pa_context_connect() failed: Connection refused” indicates that something went wrong while connecting to the internal pulseaudio context (pactl is a pulseaudio command and pipewire is partly compatible with pulseaudio). In example, it can happen if try to run some pipewire/pulseaudio command when logged as root. Another option is that pipewire server wasn’t started in a proper way but it’s unlikely since everything works fine from the command line.

The nxserver process creates some virtual devices that can be used to forward microphone. That’s what you can see in nxserver.log.

Regards,

Kuba

[kubaszym1]

Hi,

It seems you have a pulseaudio internal issue. Have you tried reinstalling or update pulseaudio to v.16?

Don’t look at NoMachine Output, it’s used for microphone forwarding. For audio forwarding we just capture data from the default sink and send it to the client side.

Regards,

Kuba

[kubaszym1]

Hi,

Nothing significant in audio forwarding has changed in the last update. Have you updated pipewire recently? There is a chance they changed something that broke sound streaming in your case. You can check logs on the server side under these paths: ~/.nx/node/C-<display>-<session-ID> to see whether you have any warnings or errors related to audio.

Regards,

Kuba

[kubaszym1]

Hi,

NoMachine Output and Remapped nx_voice_out are devices that we use for forwarding microphone. If it comes to audio forwarding, nothing significant changed in the latest update. I only added some error handling. We capture data from the default audio device and send it to server. These new devices and processes are only for microphone forwarding. You can check the logs under this path: ~/.nx/node/C-<display>-<session-ID> to see whether you have any warnings or errors related to audio.

Best regards,

Kuba

[kubaszym1]

Hi,

Yes, NoMachine uses sshfs for mounting on Linux and MacOS, but for Windows we have our own service called nxfs. It uses stftp and Dokan API.

Moreover, we are going to update our implementation of VPN connections (planned for v9). Maybe this update will help with drive sharing when using VPN.

Regards,

Kuba

[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.

[Author]

Posts