Hello Nick,
I narrowed it down a bit. Since this issue clearly happened after the Windows 2019 Standard Version 1809 server joined the Active Directory domain, I decided to check whether this permissions issue / behaviour (4 folders false creations) was due to the fact that computer was part of an Active Directory domain or not. So I took another server, but this time a Windows 2012 R2 server.
I installed WinFSP and rclone and created the very same nssm.exe service with the exact same rclone mount options (with no -o uid... option), so with the service run by the SYSTEM account. No issues.
I then joined the computer to the very same Active Directory domain. No issue! I was expecting the opposite actually.
On the Windows 2019 server, the fsptool shows these permissions:
C:\Program Files (x86)\WinFsp\bin>fsptool-x64.exe perm s:
O:SYG:SYD:P(A;;FA;;;SY)(A;;0x1201ef;;;SY)(A;;0x1201ef;;;WD) (perm=18:18:0777)
On the Windows 2012 R2 server, the fsptool shows theses permissions:
C:\Program Files (x86)\WinFsp\bin>fsptool-x64.exe perm t:
O:SYG:SYD:P(A;;FA;;;SY)(A;;0x1201ef;;;SY)(A;;0x1201ef;;;WD) (perm=18:18:0777)
Exact same permissions on both computers.
Still, creating a folder on the Windows 2019 server results in 4 folders showing up in Windows Explorer.
Apart from that, writing a file in the root of the volume or in one of the 4 folders succeeds afterwards.
It's just that 4 folders get (virtually) created instead of one which looks like a bug to the user.
This looks to me like permissions got tighten since recent Windows versions. It's not clear to me whether this should be handled by loosening these windows restrictions or by using the -o option to set the file property. But maybe a clever way to fix this would be for WinFSP (I doubt rclone can do that) to tweak the NTFS special permissions. @billziss-gh might help us here.
Regarding your question about the documentation, it currently reads:
The easiest way around this is to start the drive from a normal command prompt. It is also possible to start a drive from the SYSTEM account (using the WinFsp.Launcher infrastructure) which creates drives accessible for everyone on the system or alternatively using the nssm service manager.
Until we find a global fix, I think we could add something like this:
There may be some situations were the drive might not be accessible to everyone from Windows Explorer, even to the Administrator account. In these situations using the -o option to set files property would help, for example:
rclone mount .... -o uid=65792,gid=544
uid=65972 is for user "Everyone" and gid=544 is for group "Administrators". fsptool that comes with WinFSP can be used to get user/group uid and gid.
C:\Program Files (x86)\WinFsp\bin>fsptool-x64.exe id "Administrator"
S-1-5-21-2790659633-1931783022-730602116-500(PC\Administrator) (uid=197609)
I'll let you rephrase it as English is not my mother tongue.
Hope @billziss-gh can see this post and come help.
Bests,
Frédéric.