OpenSSH is the de-facto standard for Linux.

Hi Martin,
It does happen quite often, even within the LAN, across subnets for testing.
Maybe the way TrueNAS implements SFTP is not quite right.
I will try setting up a plain SFTP server with Ubuntu instead and see how that works.
Any suggestions for preferred SFTP Server? It will be under a linux flavoured VM in Proxmox.
Thanks.

How often do you get the problem with zeroes? Is it easy to reproduce? I assume you get it also for simple downloads? Can you reproduce the problem with other SFTP clients too?

Hi Martin,
The server is TrueNAS 25.10 Community Edition, it does not have a specific sftp server, as it is built in, "allegedly".
WinSCP does seem to connect ok if I remove the checksum option.
So, without the checksum option, the scripts runs fine, files are transferred if missing on destination, BUT, randomly, some files, not all,are filled with "00" (zero value bytes), that is, files are transferred, operation completes without errors.
Running FC.exe on Windows between the downloaded corrupt file and original one, shows the corrupted (transferred) file has "00" in it while the original one does have actual data.

I got SftpScpFallback=0 from a Google search, apparently this is supposed to stop WinSCP falling back to SCP Protocol if SFTP fails....

If your SFTP server does not support calculating checksums (what is common – as particularly common OpenSSH server does not support it), then WinSCP indeed falls back to using shell commands to calculate the checksums.
https://winscp.net/eng/docs/protocols#checksum

---

I'm confused about the "files filled with 00" problem. Is this related to the checksum problem? Or did you resolve it somehow?

---

(Btw, there's nothing like SftpScpFallback=0).

Hi Martin,
Yes, that was it I think, however, it now falls back to scp, not SFTP protocol.
What I am trying to achieve is as follows:
I distribute an SSD filled with all the software for our equipment, around 300GB all up.
I am trying to make it as simple as possible for the people in the field, so that they just click on a batch file, it runs and the SSD is updated as required.
The client is Windows 11, the server is TrueNAS 25.10, SFTP, SSH using Private/Public key.
The target is an SSD with 2 partitions, one is a Windows recovery (our equipment boots from this), the other contains the data, WinSCP and related files are copied in a folder of the recovery partition.
The original command was working, however I would get random files filled with "00" instead of actual data. Original command was:

So I added the -transfer=binary -resumesupport=off, no joy, eventually I ended up with:

But for some reasons, this causes the protocol to switch from SFTP to SCP and it fails....
The default shell on TrueNAS was zsh, later changed to bash, service restarted, but still getting error.
I have attached that starting batch file, the sync.txt referred by it and the error log.
Note this transfer tests are currently happening on a local network at the moment, so no slow internet.
Hope you can shed some light on it.
Many thanks!

Hard to tell without a log file.
But it seems that you are specifying the key with just file name (so relatively to your working directory). If the script changes the working directory (lcd) before the synchronize, the key.ppk stops being valid.
If this does not help, please post a log file.

Hello, I am at my wits end with a script supposed to synchronize a local folder with a remote folder, this works:

But if I add -criteria=checksum:

This causes the second part of the authentication to fail, reason given is that it cannot read the private key.

Script: Credentials were not specified.

If I just remove the -criteria=checksum switch from the command, everything is fine.

Any idea?

Thanks