So, I was more or less fooling around with accessing a zpool via samba from a windows 10 client and noticed a very strange behaviour: The windows 10 client puts this weird ntfs system volume infomation folder in the root as soon as I map the network share. This question maybe better fit on the MSDN forums, but did anyone else of you ever noticed this?
For the sake of ease I set the zpool mount to 0777 and enabled anonymous guest access for the samba share - as for some reason I goofed up the config to make use of user login, which in default config grants access to the users home directory.
Also, as I noticed a negative perfomance impact using smb if I recall correctly there was (or still is?) several drivers (?) for windows to mount a network share using sftp instead - but all I was able to dig up currently seem to be commercial products only. Has someone experience with such if it may mitigate the bad performance caused by SMBs single-thread implementation mainly when accessing lots of small files?
Hi
Use sshfs, google sshfs+windows 
Probably has to do with however you mounted the share.
If you simply accessed the share in normal recommended ways, you shouldn’t see a SysVol created.
On the other hand, if you map a share on a Windows machine, I can see how it’s likely the Windows machine will think the location is a locally installed drive so could very well want to set up a SysVol although it’s been so long since I’ve done this I haven’t actually experienced what you’re describing.
In other words…
You don’t have to map a remote share unless an application absolutely demands it (I’ve mapped drives when apps were written only to access drive letter locations).
If you can point your application simply to a directory, then you can define that directory with the network path and likely no SysVol will be created.
TSU