Cannot access the Windows drive that is created

[dannypike]

Hi,

I think this ticket relates to this issue, which was closed last year, apparently because there is a desire to "keep things simple" in SSHFS-Win Manager. The problem that I have with your solution to that ticket, is that "failure at the first hurdle" is not "simple". This is a Windows program and, as a non-Linux user, I would like some better feedback and advice help when this happened, please:

I've just installed SSHFS-Win Manager and I can login to the remote server, but the drive that gets created has no permissions set. So I can't do anything with it. The manager's Debug Window looks like this:

--------------------------------------------------------------------------------
date: 2021-03-16T03:02:49.347Z
conntype: password
cmd: "D:\Program Files\SSHFS-Win\bin\sshfs.exe" ***user***@***host***:/ R: -p22 -ovolname=***FriendlyName*** -odebug -ologlevel=debug1 -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -oidmap=user -ouid=-1 -ogid=-1 -oumask=000 -ocreate_umask=000 -omax_readahead=1GB -oallow_other -olarge_read -okernel_cache -ofollow_symlinks -oPreferredAuthentications=password -opassword_stdin

On trying to access the drive, I get:

D:\junk>dir r:
 Volume in drive R is ***FriendlyName***
 Volume Serial Number is ...-....

 Directory of R:\

File Not Found

D:\junk>copy junk.txt r:\
Access is denied.
        0 file(s) copied.

D:\junk>

and Windows Explorer confirms that there are no permissions set on the drive that was created. I assume that it has something to with the umasks being set to zero in the cmd string that is shown in the Debug Window above, but I do not see any way to change those in the SSHFS-Win Manager configuration (despite, as I mentioned above, this issue having been raised and closed last year).

Just to confirm that everything is OK at the server end, I set up a separate drive mapping from the Command Line with:

net use S: \\***user***@***host***\path

That works fine; Windows is happily copying files to drive S:, as I'm typing this issue.

How do I get SSHFS-Win Manager to create a drive letter that I can access?

Many thanks,

Dan

[Jayonics]

As a fore-notice, I don't work on this project in any way, I just use it.

I'm not sure about the umasks or the such but I have a hunch that your access denied issue could be the result of a UAC (User Account Control) related issue:

Mapped drives are not available from an elevated prompt when UAC is configured to Prompt for credentials. [KB: 3035277] Symptoms:

• When you sign in to the client, mapped drives are available as expected.
• When you run an elevated command prompt as administrator, the mapped drives are unavailable in the elevated command prompt.
• Note: This issue also affects other applications that run in an elevated context (run as administrator) and use drive letters to access mapped drives.

The problem: Essentially, with UAC enabled, drive mappings to network drives are created in the non-elevated user logon environment. When a UAC enabled user logs in, they login with 'least user rights' and a non-elevated session is created. Programs that run with elevated/Run-as-Admin privileges, regardless of being run by the same user, create a separate elevated session independent of the non-elevated session.

So... When you map drives in an elevated environment, the mappings exist in the elevated session - but do not exist in the users non-elevated session. Hence it appears to the user like the drive was never mapped and likely why you are getting the access denied error, because the mapping simply doesn't exist in your user's session.

The solution: Firstly, I recommend temporarily disabling UAC and seeing if it resolves the issue. To do this:

1. Search for Local Security Policy in the start menu, or find it in the Administrative Tools section of the control panel.
2. Go to: Local Policies > Security Options > User Account Control: Run All Administrators in Admin approval mode
3. Set to Disabled, Apply & Ok.
4. Restart.
5. See if your issue is fixed.

If it is then you know UAC is the cause of the problem so you can implement the proper fix that doesn't involve the insecure disabling of UAC (Don't forget to reenable UAC from before). To do this:

1. In Registry Editor, locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System Right-click Configuration, select New, and then select DWORD (32-bit) Value.
2. Name the new registry entry as EnableLinkedConnections.
3. Double-click the EnableLinkedConnections registry entry.
4. In the Edit DWORD Value dialog box, type 1 in the Value data field, and then select OK. Exit Registry Editor, and then restart the computer.

If disabling UAC fixed it but the EnableLinkedConnections registry item didn't, then you at least know it's UAC related so you can do some more digging from there. Hope I helped 🙂

[dannypike]

Thank you for such a detailed and helpful reply!

When we didn't get a response to the original question, we decided that the project was probably dead in the water, and we set up a custom batch script to do what we needed. It's a clunky system, but it seems to work well enough. We don't need it to be particularly clever. We just need it to be robust, i.e. work quietly or report an understable error message to the operator when it fails.