Giorgi-G.

[Giorgi-G.]

Hi,

After plenty of tests, I can confirm that in the case of iPhone forwarding from Windows to macOS 11.4, the forwarded device shows up in the NoMachine with a green dot, but it does not show up on the remote macOS.

Just only difference in our case and in your tests is that if after the restart, forward a simple USB device (mouse, USB disk) it is forwarded and shows up on the remote macOS. Worth noticing, if forward USB disk after iPhone forwarding, USB disk will also appear with a green dot, but will not appear on the remote macOS.

The Trouble Report https://knowledgebase.nomachine.com/TR07S10310 for the issue with iPhone forwarding has been created.  Please use that link to monitor its status.

Would it be possible to share, what service was used as a host for virtual macOS?

[Giorgi-G.]

Hi, can you please check, if when connecting from a MacOS to a Windows machine, does your screen looks like in the attached file (Local USB devices are not visible)? If you connect from Windows to Mac., will you see remote Mac’s USB devices in the USB devices window (look at the screenshot).

Attachments:

1. 

   image_2021_07_12T07_49_49_355Z.jpg
   

[Giorgi-G.]

Hi,

Thank you for providing so detailed feedback and logs.

We made some internal tests based on your logs report and will come back to you on Monday.

[Giorgi-G.]

Hi,

That means that no device has been forwarded to the target machine. Most probably it’s caused by not loaded kext drivers that are required to forward USB devices.

Please run this command when you have forwarded the device and see a green dot and send the output.

sudo kextstat | grep nx

[Giorgi-G.]

Hi,

Can you please run this command before forwarding the device, and after it is forwarded? Do you see any differences in the output?

ioreg -p IOUSB

 

[Giorgi-G.]

Hi,

The disk forwarding module is not related to the USB device forwarding.

On Mac, if you missed the popup to accept drivers loading, that popup will not appear anymore. The best way is to run NoMachine, go to USB devices forwarding panel and after check the Security & Privacy panel. That panel should look like this:

 

 

Another way to check that drivers are not loaded is to run the following command after opening the USB forwarding tab.

sudo kextstat | grep nx

If there are no lines with nxusb* that means that drivers definitely are not loaded.

 

[Giorgi-G.]

Hi,

I do not see any devices on the remote side, usually, that happens in the case when NoMachine’s USB forwarding module is not well loaded and is followed by this error in the logs (on the remote Mac side):

2660 174091 14:52:43 397.932 DeviceIoUsbUnixClient: ERROR! Could not start USB daemon.
2660 174091 14:52:43 398.034 DeviceIoUsb: Error on initializing USB interface.

Most probably, this error is caused because of a failure on loading the required by daemon kext files on Mac machine.

Please take a look at this article: https://knowledgebase.nomachine.com/AR01P00962

Also,  would be great if you can confirm that the simplest USB device forwarding (like a flash drive) also ends up with a failure.

 

[Giorgi-G.]

Hi, could you please send the full log folder? It would be great if it also includes session logs.

Also please check, if the Universal Serial Bus controller is present in Devices Manager?

 

[Giorgi-G.]

Hi,

Can you please attach logs from both machines to the topic?

Also, please check if any conflicting software is installed on the machines? AR03R01080

[Giorgi-G.]

Hi,

I clearly see that there is some issue with loaning nxusb kexts on your macOS machine.

Can you please share what macOS version you use?

As well, you can try to update macOS and re-install NoMachine on it.

To check the loading of drivers on the macOS machine run these commands.

1. Close the NoMachine.

2. Unload all drivers
sudo kextunload /Library/Application\ Support/NoMachine/Extensions/nxusbvhci.kext/
sudo kextunload /Library/Application\ Support/NoMachine/Extensions/nxusbvic.kext/
sudo kextunload /Library/Application\ Support/NoMachine/Extensions/nxusblog.kext/ 

All of these commands should fail with the reason: “(libkern/kext) not found”

Sample:
(kernel) Kext com.nomachine.kext.nxusblog not found for unload request.
Failed to unload com.nomachine.kext.nxusblog – (libkern/kext) not found.

If you have any other output, please restart your machine and try again.

3. Load drivers to check that they are allowed in security preferences to be loaded.
sudo kextload /Library/Application\ Support/NoMachine/Extensions/nxusbvhci.kext/
sudo kextload /Library/Application\ Support/NoMachine/Extensions/nxusbvic.kext/
sudo kextload /Library/Application\ Support/NoMachine/Extensions/nxusblog.kext/ 

4. If you see such an error:

/Library/Application Support/NoMachine/Extensions/nxusbvhci.kext failed to load – (libkern/kext) system policy prevents loading; check the system/kernel logs for errors or try kextutil(8).

That means that the user has to approve kext loading in the Security Settings, as described here: https://www.nomachine.com/AR01P00962

Such output also should be followed by a system pop-up, with the button: Open security Preferences.

Once this is done for one kext, do that for the rest two ones, by launching the appropriate kextload command as described above.

After this is done for all three drivers, restart your system and check USB functionality.

5. If after launching the commands from step 2 you don’t see any output, that means that drivers are well loaded. Please run all three commands and after that run this command, to check that they are loaded:

sudo kextstat | grep nxusb 

The output should contain three lines with this kext ID’s:
com.nomachine.driver.nxusblog
com.nomachine.driver.nxusbvic
com.nomachine.driver.nxusbvhci

If you see such output, restart the machine and check the USB functionality.

 

[Giorgi-G.]

Hi,

Can you please send us logs from both machines and the screenshot of the Devices -> Connect USB Device tab?

You can send logs to forum[at]nomachine[dot]com (please use the topic title as the subject).

[Giorgi-G.]

Hi,

Thanks, happy to hear that everything works well now.

Regarding the 10 seconds for listing the device, I can confirm that in this update there were no changes in code. That may cause such a delay. In general, it depends on how many OS-related factors and 10 seconds to list all local and remote devices could be considered as normal listing time.

[Giorgi-G.]

Hi,

Can you please share what OS and version are you using? And what is the kernel version as well?

Can you also confirm that in both versions 7.0.211 and 7.1.3 nxusb.ko was well compiled, right?

[Giorgi-G.]

Hi,

We already have a feature request for the automatic rebuilding of nxusb.ko module on a kernel update. https://www.nomachine.com/FR01S04064

Until it’s ready, you can manually recompile nxusb.ko module after kernel update https://www.nomachine.com/AR11O00946

Or you can re-install NoMachine after kernel updates and it will be automatically rebuilt.

[Giorgi-G.]

Hi,

Do you have Linux on both sides? If yes – try to install the required on the article packages and just simply re-install NM. It will build nxusb.ko during the installation.

You can also manually check that on both machines nxusb.ko is built and exists on the path /usr/NX/bin/drivers/nxusb.ko

Also, worth mentioning that the problem could be on any of both sides.

[Author]

Posts