This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
I have a windows machine (AWS instance, Windows Server 2022, 10.0.20348) running openssh (OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2) that can visit and mount a shared network drive (samba/linux).
When I am on the windows machine itself via RDP I can visit the path, mount it as a drive, make folders and make files via both explorer and powershell.
When I ssh into the windows machine I can visit the path, mount it as a drive, enumerate the folders, and read the files. But "access to path '' is denied." whenever I try to make a folder or file (mkdir/Set-Content/New-Item).
The same is true of other applications run via SSH that attempt the same operations through I imagine the c++ windows api. I get mkdir errors from Perforce when syncing.
I have tried searching for this but almost every result is based on how mapped drives aren't available over ssh as they are "session" specific.
I have tried and failed to reproduce the issue on the machine itself via RDP and powershell to make sure it wasn't powershell command specific.
I have verified the user/password being used to mount the drive has proper read/write access.
I have stored the credentials for the drive in the windows credential manager which I think is why the ssh connection can access the UNC path directly without mounting.
I have tried first mounting the UNC path to a drive letter and trying the ssh commands on the mounted drive instead. Same read only behavior happens.
I have tried setting the "EnableLinkedConnections" registry key as I originally assumed this is due to a mix of elevated vs non-elevated prompts
I would expect to have write access to this drive via ssh like I do via RDP especially when I mount it during the ssh session as all credentials seem to be lining up, but so far that doesn't seem to be the case.
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question. To protect privacy, user profiles for migrated questions are anonymized.
Hello,
Based on my understanding of your issue, I suggest you try configuring the correct permissions on the .ssh/config file to see if that resolves the issue. You can try executing the following command:
chown $USER ~/.ssh/config
chmod 644 ~/.ssh/config
Best regards
Zunhui
To clarify ssh is working fine otherwise and it is a windows machine I am SSHing into with the issue hence being here.
I can write/delete/modify machine local files via SSH fine too.
For additional context after this post I made a windows network share on another machine also using user/pass auth and it works properly through SSH, but the Samba based share doesn't.
Both work properly when connected via RDP into the box.
So:
My Machine -- RDP (/w Admin credentials) --> Windows VM --> Local Files = Read/Write
My Machine -- RDP (/w Admin credentials) --> Windows VM -- Samba Share (/w share user credentials) --> Linux Share Host = Read/Write
My Machine -- RDP (/w Admin credentials) --> Windows VM -- Windows Share (/w share user credentials) --> Windows Share Host = Read/Write
My Machine -- ssh (/w Admin user - Key file) --> Windows VM --> Local Files = Read/Write
My Machine -- ssh (/w Admin user - Key file) --> Windows VM -- Samba Share (/w share user credentials) --> Linux Share Host = Read only
My Machine -- ssh (/w Admin user - Key file) --> Windows VM -- Windows Share (/w share user credentials) --> Windows Share Host = Read/Write
Hello,
Thank you very much for providing more information on this issue. I would like to follow up and find out if you have tried to configure SSH configuration using the method I provided before?
Best regards
Zunhui
As best I can tell windows/powershell doesn't have chown or chmod so no, that is not a thing I could have tried. My response was trying to highlight that nothing here is sshing into a Linux box. I spelled out which OS each machine is using and which method is being used to communicate with each.
I suppose the only OS I didn't specify is that the machine SSHing into the Windows machine (My machine during testing and a Jenkins instance in the actual environment) is also a Windows machine.
I dont think he really understands your issue.
I am seeing this as well, and I believe it to be something about the kerberos ticket not being issued to the ssh user like it would normally be via RDP sessions.
Apparently MS locked this down some time ago, I am trying to find out more and will post here if I solve it.
Brett.
