Es läuft:
/etc/samba/smb.share.conf, benutztes share: strict allocate = yes
"Systemsteuerung/Dateidienste/Windows Dateidienst/Erweiterte Einstellungen“ “Max. Protokoll für Windows-Dateidienst“ auf “SMB 3” und min. Protokoll auf “SMB 1“ einstellen.
und einen Haken bei “Opportuunistic Locking aktivieren” setzen.
der Unterpunkt “SMB2 Lease aktivieren” bleibt deaktiviert.
Logs gibt es in C:\Windows\Logs\WindowsBackup
und in der Ereignisanzeige
Bei mir bringt das leider auch nichts. Genau die gleichen Einstellungen hatte ich sowieso schon standardmäßig - bis auf SMB3. Aber SMB3 ändert auch nichts. Am Ende des Schreibens des Systemabbildes (VHDX) kommt immer der "berühmte" Fehler 0x807800c5. (Wenn man kein VHDX schreibt, geht es, aber ohne das VHDX hat man ja keine volle Sicherung.)
In der Registry sehe ich dann noch, dass der "LastBackupResultHrDetailed" dazu der Fehler 0x80780081 ist, was aber letzten Endes auch nicht weiterhilft. Habe alle Tipps aus diversen Foren probiert, bisher immer ohne Erfolg. Der Tipp aus der c't ganz vorne bezieht sich auf uralte DSM-Versionen (vermutlich <= 4.x). Seither hat Synology einiges getauscht, u.a. die Versionen von Samba und glibc. Dadurch liegen u.a. die Konfig-Dateien woanders.
Das ganze Problem dreht sich ja eigentlich "nur" um die Behandlung von "Sparse"-Dateien durch den SMB-Server. Also hier der Samba unter Linux (DSM). "Sparse"-Dateien sind Dateien die ein große Anzahl von "Lücken" (leeren Blöcken) beinhalten, wie bei Systemabbildern wie VHDX. Für die "Lücken" wird dann kein realer Platz beleget. Die Option "strict allocate = yes" bewirkt, dass Samba bei der Erzeugung der Sparse-Dateien für die Lücken Platz alloziert, wie ein Windows-Dateiserver. Während bei "no" kein Platz alloziert wird und dabei eine Datei angelegt wird, die nominell (scheinbar) so groß wie das System-Image ist, aber real für alle Lücken keine Blöcke (Sektoren) auf den Platten belegt. Wenn der Client (hier Windows Backup) nicht mit solchen Lücken-Dateien umgehen kann, kommt er aus dem Tritt. Daher sollte strict allocate = yes das ja auch lösen und hat es anscheinend auch eine Zeit lang. Ich sehe auch den Unterschied beider Optionen beim Anlegen (bei "no" wird sofort die große VHDX-Datei angelegt, bei "yes" wächst sie langsam).
Trotzdem kommt am Ende immer der obige Fehler. Meist erst am Ende der Sicherung, manchmal schon schneller. Was ich dabei auch nicht verstehe ist, dass die Option "strict allocate = yes" eigentlich von Samba selber seit Version 3.5.7 aus Performance-Gründen auch für Linux selber die empfohlene Einstellung ist, insofern das darunterliegende Dateisystem sogenannte "Extends-based allocation" unterstützt, was u.a. für ext4 und BTRFS gilt (für ext3 z.B. nicht).
(Siehe ausführliche Erklärungen hier im Samba-Wiki:
https://wiki.samba.org/index.php/Linux_Performance)
Kurioserweise gibt es im DSM unter Systemsteuerung => Dateidienste => SMB => Erweiterte Einstellungen auch die Option "Beim Erstellen von Dateien keinen Speicherplatz reservieren". Wenn man die anhakt, wird vom DSM die Option "strict allocate = no" in eine Datei /etc/samba/smbinfo.conf geschrieben, die angelegt wird, wenn sie nicht schon da ist. Entfernt man den Haken wieder, wird die Option nicht auf "yes" geändert, sondern ganz entfernt. Es sieht fast so aus, als würde Synology annehmen "yes" ist der default-Wert. Ist es aber bei Samba nicht. Es sei denn Synology hat das für die eigene Version geändert. Dagegen spricht aber das unterschiedliche Verhalten.
Apropo Synology-Version von Samba:
In DSM 6.2.1 ist aber Samba 4.4.16 ("Synology Build 23824, Oct 26 2018 20:04:21"). Die glibc ist 2.20-2014.11. Also beides neu genug.
Bei mir: NAS: DS214play mit DSM 6.2.1-23824 Update 2, 2x Platten, ein Volumen mit ext4 formatiert. Der Client mit Windows Backup ist Windows 10 Pro Version 1803.
Gut wäre zu wissen, ob es ein generelles oder versionsspezifisches Samba-Problem ist oder ein Problem des Synology-Builds von Samba. Denn ich bin nicht sicher, ob es wirklich noch die gleiche Ursache ist, wie früher oder eine neue "Verschlimmbesserung". Ich hätte zwar auch andere Linux VMs mit Samba zum Vergleich aber aktuell keine mit genügend Platz, dass da ein volles VHDX draufpassen würde und Sicherungen ohne VHDX sind ja eh kein Problem.
Meine DS1618+ ist jedoch schon unterwegs. Dann wechsele ich auch auf BTRFS und schaue dann mal weiter...
