Permission denied on specific operations when using symlink to network share

[sawo1337]

"OpenSSH for Windows 8.1.0.0"

Windows Server 2016 Datacenter

Client OperatingSystem
Any

What is failing
When using a symlink to a network share as ChrootDirectory, I can rename files, delete files, create empty files, but as soon as I attempt to append any data to the file I just created, I get permission denied. An empty file is created on the server, but no data is in it.
I'm using domain users, they have full permissions over the network share, NTFS permissions on the network server, I can log in using the same user and create files just fine, but as soon I attempt the same using SFTP client, it fails with permission denied error.
On the target server, I can see the correct user is attempting the operation, but for some reason, it fails. No failure is logged on the network share server, tried different network share server where everyone has full control, but still no go.
It is interesting that during testing this worked for a brief moment, but then it never worked afterward.
This is all with password authentication.

Config:

AllowGroups domain\sftpgroup
AuthenticationMethods password
ForceCommand internal-sftp
ChrootDirectory C:\root\sftpnetworksharesymlink
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no

Expected output
Files are uploaded by the logged-in user.

Actual output
An empty file is created and then permission denied message is shown on the client.

[bagajjal]

Check #1258

[sawo1337]

Thanks, I've seen this and this is where I started, but the issue for me is that even though this workaround works and I can create/delete/rename files and folders, I cannot append data to the files I've created.
I do have proper permissions since I can manipulate files in ChrootDirectory that sits on a symlink to a network share, but I just can't append data to these files.

I've enabled a security audit on the NTFS folder where the network share lands via the symlink and I can see that the first event is access request:

Access Request Information:
	Transaction ID:		{00000000-0000-0000-0000-000000000000}
	Accesses:		READ_CONTROL
				SYNCHRONIZE
				WriteData (or AddFile)
				AppendData (or AddSubdirectory or CreatePipeInstance)
				WriteEA
				ReadAttributes
				WriteAttributes

This is all fine and well I believe, but the next audit events show where it fails:

An attempt was made to duplicate a handle to an object.

Subject:
	Security ID:		domain\thesftpuser
	Account Name:		thesftpuser
	Account Domain:		CORP
	Logon ID:		0x2C7E628

Source Handle Information:
	Source Handle ID:	0x1424
	Source Process ID:	0x4

New Handle Information:
	Target Handle ID:	0x155c
	Target Process ID:	0x4

The next two events are "The handle to an object was closed." - one from SYSTEM and another from the domain user who connected to the SFTP session initially.
Looks like that duplicate handle fails and then the operation is canceled altogether.

Edit:
I've tried entering PS session on the SFTP server with the SFTP user, went to the symlink SFTP root folder, created file and succeeded without any issues.

[Youbi42]

Hello,
I have the exact same problem.
Windows Server 2016.
OpenSSH_for_Windows_8.0p1, LibreSSL 2.6.5

[sawo1337]

This appears to be a bug in the server, I still haven't found a solution as well.

[penicaudm]

Also having the same bug.

Windows Server 2016 Standard Core 10.0.14393
SFTP version 3
OpenSSH_8.1p for Windows

NTFS rights are correct, the user has correct permissions and can create / upload / delete stuff in a PS session or the Windows explorer.

[Marcel2]

I'm having the same problem. From a Windows perspective, openssh should run under an AD service account to access a network share. It appears that this is not intended with OpenSSH. I would be very happy to find a solution for this problem.

We are having the same issue. We had to develop a file sync job to circumvent this bug. Please do tell if we can do anything to help getting it fixed.

[sawo1337]

Looks like there is still no solution to this, which sadly makes the application useless to a lot of people.

Are anyone from the project receiving e-mails or notifications about this issue? I'm sorry i'm a bit new to Github issues. @maertendMSFT @manojampalam

This problem makes it impossible to have a non-hacked setup of an SFTP-server, where the files are located on another server/file cluster via smb/file shares.

[maertendMSFT]

Yes, we get notifications :) There can be some delay in responses/solutions based on current prioritization of Win32-OpenSSH.

@bagajjal , can you look at this issues again?

[aman6261]

New to github and unfortunately a negative first post -

my project has decided not to proceed with openssh due to the same limitation... we have a requirement where -

1. sftp client will connect to a SFTP server using key based authentication
2. After authentication, it will write files to chroot directory.. this chroot directory is basically a symlink to a NAS path....
3. Due to the limitation of openssh, it’s not possible to write to a symlink which has NAS reference, if chroot directory is a symlink.
4. As a work around, if I don’t set chroot directory for that sftp client user, that user is able to write/read/modify/delete to NAS location while accessing via symlink using password based authentication..
5. but it allows sftp user to access whole sftp server which is a security breach...
6. I am yet to test symlink (reference to NAS) with key based authentication if there is no chroot directory but since project has decided not to accept this risk, I might not get a chance to check via key based authentication...

But I will keep a track of this story.. hopefully will proceed with openssh once the fix is available...

thank you...

[malfuncion]

Just compiled the latest version from the repo and this issue still occurs in August of 2022. I tried earlier in the year and came across similar posts with this bug dating back to 2019. This issue unfortunately doesn't appear to be a priority and as another mentioned, makes this deployment useless on Windows for a lot of people.

We have unfortunately moved over to the SolarWinds SFTP server but it too has its own set of limitations- but not of the symlink variety.

[sawo1337]

We actually retested this just two weeks ago and nothing has changed in this regard.
It has been long enough so we moved to a proper Linux solution which we managed to deploy in a couple of days. Kerberos domain authentication, network share access with chroot - everything that is not possible with this windows port, works perfectly under Linux.
Not being able to chroot to a network location is a pretty serious flaw and makes this project useless to a lot of people.