[HOW] Veracrypt file container very slow write on SMB

[wenuam]

Hello, trying to use Veracrypt on network shared file container.

Windows 10 22H2 -> SMB3 on 1 Gbps -> T9-423 5.1.145-00320 (BIOS 5.19) -> TRAID BTRFS -> Veracrypt container

Read performance is decent (80 MB/s) but write performance is abysmally slow (4 MB/s).

Writing a file outside the container is about the same as read (about 65-70 MB/s write).

There is a ongoing issue on this on the Veracrypt Github :

https://github.com/veracrypt/VeraCrypt/issues/1277

It is advised to set "strict sync = no" to smb.conf :

https://github.com/veracrypt/VeraCrypt/ ... 4048621835
https://forum.openmediavault.org/index. ... mb-speeds/
https://forums.unraid.net/topic/176061- ... -solution/

But how to find this parameter on the TOS 5 user interface ?

I looked at the following topics without finding a clue :

viewtopic.php?t=7273
viewtopic.php?t=7816

Any clue how to improve Veracrypt write on SMB ?

Other people having the same problem outside Github :



More SMB tweaks :



smb.conf :

https://web.mit.edu/darwin/src/modules/ ... STRICTSYNC
https://www.samba.org/samba/docs/curren ... STRICTSYNC
https://www.samba.org/samba/docs/using_ ... 11-TABLE-9

Regards.

[Gremlin]

You should be able to add settings in the Advanced settings for SMB > Custom (at end of list of settings)

[wenuam]

What is the format ?

[Gremlin]

I presume it is the format given in the examples shown previously from the other group(s). But don't take my word for it, not something I need.
I believe that each line added via the advanced dialogue gets added to the conf file and is parsed when activated, so a service restart is likely required after modification. (Or maybe it restarts automagically after configuration is complete.)

[CursaYang]

You can add custom parameters and configurations in SMB settings.

[wenuam]

It is indeed writing way way faster now. Is it using the cache SSD ?

[EriChan]

No, it’s actually using System RAM (Memory Cache) rather than an SSD cache. The Samba configuration enables zero-copy transfer and asynchronous writing (strict sync = no / AIO), allowing data to be buffered into fast RAM first before flushing to disk. Just note that because data hits RAM first, a sudden power outage could affect un-flushed data.

[wenuam]

Ok, thank you for the explanation but the write speed difference is too high to not use "strict sync = no" (4 MB/s vs. 70 MB/s).

When speaking about transferring 2 TB, we're from 6 days (4 MB/s) down to 8 hours (70 MB/s).

I just cannot afford to waste 6 days when it can be done in 8 hours (also waste of power and your equipment immobilized).

I'm using a PSU so a power outage is unlikely, anyone with a NAS to save/secure important data should use one anyway.

Consider making "strict sync = no" a default, or at least allow to tick a checkbox with a clear explanation (faster vs "security").

[EriChan]

The performance difference between 4 MB/s and 70 MB/s is indeed substantial. In an ideal environment, disabling strict synchronization (strict sync = no) to improve bulk backup efficiency is a reasonable trade-off.

Why this setting is disabled by default:

As a standard for NAS storage, data integrity takes precedence over out-of-the-box speed.

• Mechanism: Setting strict sync = no causes Samba to immediately report "data written" to the client while the data is still residing in system RAM.

• Potential Risk: If a system lockup, kernel panic, or Samba crash occurs before RAM flushes to disk (events a UPS cannot prevent), the client application will assume the backup succeeded when the file is actually corrupted. For databases or virtual machines, this can lead to silent data destruction.

That said, your suggestion to add a user-controllable toggle (e.g., "Performance Mode / Asynchronous Write") with a clear risk warning is excellent. We will forward this suggestion to our product team for evaluation.

[wenuam]

Thank you for considering my suggestion.

However could you also investigate into this writing speed difference as obviously the NAS is very capable to write at sustained speed with "strict sync = no", but tank abysmally when set to "yes" ?

Is Samba reading back the data to compare if it has been written correctly ? In that case it might just halve writing speed (write @ 70 MB/s + read back @ 80 MB/s), not make it almost 20x slower (70 MB/s -> 4 MB/s).