Local Windows drive sharing to remote Linux fails

Forum / NoMachine for Windows / Local Windows drive sharing to remote Linux fails

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #43433
    tcn
    Participant

    Hi,

    I am trying to diagnose an issue where I would like to share a local drive with my Linux workstation. The result is always the same, a gray swirl beside the drive and nothing gets mapped.

    I enabled debug log for both server ans node.  On the Linux machine, I have been able to identify the handshaking for the drive sharing. It looks fine.

    However, on the Windows machine, even before I initiate the share, I get this error in the log:

    DeviceServiceDisk: WARNING! Cannot open directory for reading. The reason is 87.

    This error gets in the log multiple times when I initiate the share.  There is no indication of what the directory name is and thus, I am stuck here.

    What exactly is this directory?  The drive does exist; the remote attach directory does exist …. I can’t figure it out.

     

    Regards,

    tcn

    #43447
    kubaszym1
    Participant

    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

    #43459
    tcn
    Participant

    Hi,

    The drive is a simple drive, and yes I have access; it is X: in my case; but even C or E doesn’t work.  But the error comes before I even start sharing which I find weird.  It multiplies with I start trying.

    Regards,

    tcn

    #43540
    kubaszym1
    Participant

    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

    #43689
    kubaszym1
    Participant

    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

    #43751
    tcn
    Participant

    Hi,

    No, it is not my problem.  I was trying to mount the drive under a single letter.  There is no easy way to debug this…..  Logs do not tell me much.  Is it an sshfs error; is it that somehow the directory does not exist???

    I have yet to figure our why.  I don’t know if it is the Windows machine or the Linux machine …..

    Regards,

    tcn

    #44140
    kubaszym1
    Participant

    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

    #44159
    tcn
    Participant

    Hi,

    I am having this issue with a few OS which seems to point to either my Windows (10)  machine, or firewall blocking something or a configuration that is present on all machines.

    For instance, I am having this issue through VPN to work to a RedHat 8.6 machine.  Whenever I try to share a drive, a gray swirl appears and connection never gets established.

    I think Nomachine is using sshfs right?

     

    Regards,

    tcn

    #44166
    kubaszym1
    Participant

    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

    #44654
    tcn
    Participant

    Hi,

    I have an update on the issue.  When using full desktop, I am able to mount drives from and to my Linux box but not in terminal mode.  What could be the difference?

    Regards,

    tcn

    #44842
    kubaszym1
    Participant

    Hi,

    We discovered an issue with forwarding devices in custom sessions. We will work on a fix. I noticed that it happens if you open the session in a floating issues. It should work if you run the custom sesssion in a virtual desktop. You can set it when you create a new custom session.

    Regards,

    Kuba

Viewing 11 posts - 1 through 11 (of 11 total)

This topic was marked as solved, you can't post.