Forum Replies Created
May 31, 2023 at 15:32 in reply to: State of Pipewire support #44456
NoMachine connects to the default PipeWire server that is currently running. The default path of pipewire-pulse socket should be /run/user/<uid>/pulse/native. Maybe your issue is somehow specific to your Linux distribution. Can you see what happens if you just change “unix:native” to “unix:/run/user/<uid>/pulse/native”?
KubaMay 25, 2023 at 12:28 in reply to: State of Pipewire support #44421
I think setting server.address to “unix:native” should be enough, then server string is simply “/run/user/<uid>/pulse/native”. Doesn’t it work for you?
NoMachine doesn’t require “system-wide” PipeWire. I don’t think if that would be possible, pipewire server generally runs per-user. NoMachine also creates pipewire client for the specific user when logging to the remote desktop.
KubaMay 17, 2023 at 11:10 in reply to: State of Pipewire support #44277
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.
KubaMay 17, 2023 at 10:41 in reply to: 8.5.3 update break sound streaming on Slackware 15.0? #44276
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.
KubaMay 15, 2023 at 16:21 in reply to: 8.5.3 update break sound streaming on Slackware 15.0? #44229
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.
KubaMay 15, 2023 at 11:57 in reply to: State of Pipewire support #44227
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.
KubaMay 8, 2023 at 13:40 in reply to: Local Windows drive sharing to remote Linux fails #44166
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.
KubaMay 5, 2023 at 15:33 in reply to: Local Windows drive sharing to remote Linux fails #44140
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.
KubaApril 3, 2023 at 13:19 in reply to: Local Windows drive sharing to remote Linux fails #43689
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.
KubaMarch 22, 2023 at 14:43 in reply to: Local Windows drive sharing to remote Linux fails #43540
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.
KubaMarch 22, 2023 at 13:29 in reply to: State of Pipewire support #43536
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.
KubaMarch 17, 2023 at 13:45 in reply to: Local Windows drive sharing to remote Linux fails #43447
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?
KubaMarch 8, 2023 at 15:45 in reply to: State of Pipewire support #43291
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.April 20, 2022 at 10:33 in reply to: Update to NoMachine audio not working on Mojave #38369
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’April 19, 2022 at 14:23 in reply to: Update to NoMachine audio not working on Mojave #38359
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:
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.