sshfs-win
sshfs-win copied to clipboard
winfsp
System error 67 when attempting to mount
I am using the latest versions as of today under Windows 10 Enterprise build 2004 and whenever I try to mount a folder, I get system error 67, the network name was not found (loose translation from German). I can ping the host fine however and can also connect to it via SSH without problem using PuTTY.
Tried with net use Z: \\sshfs.k\www-data@container-host
Also tried without the .k by using a password an no luck. I can connect via PuTTY to container-host using the www-data user and either a password or keyfile fine.
This is indeed weird. Can you post the output of the file diag.bat that can be found under C:\Program Files (x86)\WinFsp\bin?
WINFSP INSTALLATION DIRECTORY AND LAUNCHER REGISTRATIONS
HKEY_LOCAL_MACHINE\SOFTWARE\WinFsp
InstallDir REG_SZ C:\Program Files (x86)\WinFsp\
HKEY_LOCAL_MACHINE\SOFTWARE\WinFsp\Services
HKEY_LOCAL_MACHINE\SOFTWARE\WinFsp\Services\sshfs
Executable REG_SZ C:\Program Files\SSHFS-Win\bin\sshfs-win.exe
CommandLine REG_SZ svc %1 %2 %U
Security REG_SZ D:P(A;;RPWPLC;;;WD)
JobControl REG_DWORD 0x1
Credentials REG_DWORD 0x1
HKEY_LOCAL_MACHINE\SOFTWARE\WinFsp\Services\sshfs.k
Executable REG_SZ C:\Program Files\SSHFS-Win\bin\sshfs-win.exe
CommandLine REG_SZ svc %1 %2 %U
Security REG_SZ D:P(A;;RPWPLC;;;WD)
JobControl REG_DWORD 0x1
Credentials REG_DWORD 0x0
HKEY_LOCAL_MACHINE\SOFTWARE\WinFsp\Services\sshfs.r
Executable REG_SZ C:\Program Files\SSHFS-Win\bin\sshfs-win.exe
CommandLine REG_SZ svc %1 %2 %U
Security REG_SZ D:P(A;;RPWPLC;;;WD)
JobControl REG_DWORD 0x1
Credentials REG_DWORD 0x1
WINFSP DLL REGISTRATIONS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
ProviderOrder REG_SZ WinFsp.Np,RDPNP,LanmanWorkstation,webclient
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinFsp.Np\NetworkProvider
Name REG_SZ Windows File System Proxy
ProviderPath REG_SZ C:\Program Files (x86)\WinFsp\bin\winfsp-x64.dll
DeviceName REG_SZ \Device\WinFsp.Mup
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\WinFsp
EventMessageFile REG_SZ C:\Program Files (x86)\WinFsp\bin\winfsp-x64.dll
TypesSupported REG_DWORD 0x7
WINFSP FSD CONFIGURATION AND STATUS
SERVICE_NAME: WinFsp
TYPE : 2 FILE_SYSTEM_DRIVER
STATE : 1 STOPPED
WIN32_EXIT_CODE : 1077 (0x435)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
[SC] QueryServiceConfig ERFOLG
SERVICE_NAME: WinFsp
TYPE : 2 FILE_SYSTEM_DRIVER
START_TYPE : 3 DEMAND_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : \??\C:\Program Files (x86)\WinFsp\bin\winfsp-x64.sys
LOAD_ORDER_GROUP :
TAG : 0
DISPLAY_NAME : WinFsp
DEPENDENCIES :
SERVICE_START_NAME :
D:(A;;LCRP;;;WD)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)
WINFSP LAUNCHER SERVICE CONFIGURATION AND STATUS
SERVICE_NAME: WinFsp.Launcher
TYPE : 10 WIN32_OWN_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
[SC] QueryServiceConfig ERFOLG
SERVICE_NAME: WinFsp.Launcher
TYPE : 10 WIN32_OWN_PROCESS
START_TYPE : 2 AUTO_START
ERROR_CONTROL : 0 IGNORE
BINARY_PATH_NAME : "C:\Program Files (x86)\WinFsp\bin\launcher-x64.exe"
LOAD_ORDER_GROUP :
TAG : 0
DISPLAY_NAME : WinFsp.Launcher
DEPENDENCIES :
SERVICE_START_NAME : LocalSystem
D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)
OS INFORMATION
Hostname: KALO375A
Betriebssystemname: Microsoft Windows 10 Enterprise
Betriebssystemversion: 10.0.19041 Nicht zutreffend Build 19041
Betriebssystemhersteller: Microsoft Corporation
Betriebssystemkonfiguration: Mitglied der Domäne/Arbeitsgruppe
Betriebssystem-Buildtyp: Multiprocessor Free
Registrierter Benutzer: FLOW7 GmbH
Registrierte Organisation:
Produkt-ID: 00329-10458-00000-AA237
Ursprüngliches Installationsdatum: 27.02.2020, 17:39:42
Systemstartzeit: 04.03.2020, 00:00:36
Systemhersteller: Hewlett-Packard
Systemmodell: HP Z420 Workstation
Systemtyp: x64-based PC
Prozessor(en): 1 Prozessor(en) installiert.
[01]: Intel64 Family 6 Model 45 Stepping 6 GenuineIntel ~2701 MHz
BIOS-Version: Hewlett-Packard J61 v03.94, 10.07.2018
Windows-Verzeichnis: C:\WINDOWS
System-Verzeichnis: C:\WINDOWS\system32
Startgerät: \Device\HarddiskVolume1
Systemgebietsschema: de;Deutsch (Deutschland)
Eingabegebietsschema: de;Deutsch (Deutschland)
Zeitzone: (UTC+01:00) Brüssel, Kopenhagen, Madrid, Paris
Gesamter physischer Speicher: 65.460 MB
Verfügbarer physischer Speicher: 56.392 MB
Virtueller Arbeitsspeicher: Maximale Größe: 75.188 MB
Virtueller Arbeitsspeicher: Verfügbar: 65.747 MB
Virtueller Arbeitsspeicher: Zurzeit verwendet: 9.441 MB
Auslagerungsdateipfad(e): C:\pagefile.sys
Domäne: Dom.Rastatt.de
Anmeldeserver: \\KADC05
Hotfix(es): 3 Hotfix(e) installiert.
[01]: KB4534170
[02]: KB4537759
[03]: KB4539080
Netzwerkkarte(n): 1 Netzwerkadapter installiert.
[01]: Intel(R) 82579LM Gigabit Network Connection
Verbindungsname: Ethernet
DHCP aktiviert: Nein
IP-Adresse(n)
[01]: 10.45.60.95
[02]: fe80::b1c3:1177:428c:99fc
Anforderungen für Hyper-V: Erweiterungen für den VM-Überwachungsmodus: Ja
Virtualisierung in Firmware aktiviert: Ja
Adressübersetzung der zweiten Ebene: Ja
Datenausführungsverhinderung verfügbar: Ja
I am one step forward, by using sshfs-win svc \sshfs.k\www-data@container-host Z: manually, I am able to connect. My problem now is that my profile is on a network share, so is the .ssh directory with the keyfile and I am getting a warning that the permissions are too loose being 775. I have no idea how the Windows ACLs are mapped to UNIX rights. By fiddling with the rights in the Security tab of the id_rsa file properties, I can either disable so many rights for the various users that the keyfile is no longer being read or it's too "unprotected".
I am another step forward, I was able to delete all ACLs, including the inherited ones, for the keyfile, added my account as only user who is allowed to read the file and now sshfs-win svc \sshfs.k\www-data@container-host Z: works fine. However, I still cannot connect using net use or via the Windows Explorer Map network drive.
Wondering if it has anything to do with our Domain configuration at work.
There was no obvious problem in the diagnostic output that you sent earlier.
Is the the account that you using when doing net use a local account or a domain account. Also if it is a local account is it part of the admin group on the local machine?
I suspect some kind of access issue between the domain account and the local SYSTEM account that will ultimately launch your file system.
Here is one thing to try (untested as I am currently away from a Windows machine):
cd "\Program Files (x86)\WinFsp\bin
launchctl-x64 start \sshfs.k\www-data@container-host Z:
Let me know what launchctl reports.
KO launcher: error 161
Tried with both a regular cmd and a cmd opened with admin rights.
Thanks.
Error 161 is ERROR_BAD_PATHNAME, which corresponds to the NT status code STATUS_OBJECT_PATH_INVALID.
Unfortunately it is not immediately obvious how this error/status code would be produced. WinFsp does not return this status code as far as I can remember (confirmed with a code search).
In any case this now looks less like an access control problem and more like a path validation problem. According to this document the characters that you use in the path are all valid.
I'll try to create an entry in my hosts file tomorrow with a short name without any special characters and see if it helps.
Added an entry to my hosts file for "dev" and still no luck. :( Not even \\sshfs.k\dev (without the username@ part) works hoping that it would attempt to log me in with my Windows account name at least resulting in another error.
I'm also getting this very same error, in case I can help to diagnose the cause :)
I get both System Error 67 as well as the KO launcher error 161. Running sshfs-win.exe \user@server!port\folder Z: directly will hang forever and I have to exit the process.
@lehitoskin when you run sshfs-win svc from the command line, it waits for you to enter your password to log into the ssh server.
@billziss-gh That's odd because it never prompts me for a username and password --- which it shouldn't ask for in the first place because I use a key to access the server.
@lehitoskin
If you use something like the following it should not ask for password:
sshfs-win svc \sshfs.k\USER@SERVER!PORT X:
But if you use something like the following it will ask for password, without prompting you. The reason is that you are using an internal command that is normally only supposed to be used by computers and not people.
sshfs-win svc \sshfs\USER@SERVER!PORT X:
(Please note that I did not test any of the above commands.)
@lehitoskin
Please verify that the registry key HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\WinFsp\Services\sshfs.k contains the value Credentials=0.
@lehitoskin are you using the 32-bit version of SSHFS-Win? In that case you should try the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\WinFsp\Services\sshfs.
I'm using the 64-bit version of SSHFS-Win and I do not have a WinFsp folder in that location.
That can mean that you have uninstalled either WinFsp or SSHFS-Win. It could also mean that you have modified the registry by hand or that it was modified in some other way.
Ah, call me a fool. I reinstalled both WinFsp and SSHFS-Win and now it works like a charm. Go figure...
I can confirm that the last windows 10 update (v 2004) breaks the SSHFS-Win installations. To fix that a fresh install of both SSHFS-Win and WinFsp is required
@mvrk80 this is curious. When I updated to 2004 myself I did not experience this issue.
I am also experiencing problems mounting with an error 67, but the underlying cause appears to be different:
C:\Users\Miles>ver
Microsoft Windows [Version 10.0.18362.1016]
C:\Users\Miles>net use x: \\sshfs.k\[email protected]
System error 67 has occurred.
The network name cannot be found.
C:\Users\Miles>"\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" start \sshfs.k\[email protected] x:
KO CallNamedPipe = 2
C:\Users\Miles>"\Program Files\SSHFS-Win\bin\sshfs-win.exe" svc \sshfs.k\[email protected] x:
Warning: Permanently added 'pathfinder.orionnet.net,192.168.10.1' (ECDSA) to the list of known hosts.
The service sshfs has been started.
Just came here to report the same symptoms as @mspielberg:
- mounting through either net use, launchctl-64.exe or through the explorer UI all fail with "System error 67 has occurred" "The network name cannot be found",
- invoking sshfs-win.exe does work (authenticates, adds the X: mount point to the system and allows browsing and transferring files).
I am using ssh with pubkey auth, with the following command:
"C:\Program Files\SSHFS-Win\bin\sshfs-win.exe" svc \sshfs.k\[email protected] x:
using sshfs-win v3.5.20160-x64 and winfsp v1.8.20304, installed from their msi packages on an up to date Windows 10 x64 machine.
The SSH client seems to be invoked as:
- I do see SSH traffic going on,
- /var/log/auth.log shows the client connecting and dropping the connection before authenticating ("Connection closed by authenticating user [user] [ip address] port 49748 [preauth]".
I haven't been able to find much information in the windows event log.
Given the pre-auth disconnect message, my hunch is that the ssh.exe process spawn through launchctl-64.exe may not have access to the private key file, but I can't be sure.
