madmin

Since the Syncthing DB structure was modified, my Syncthing docker container (Linuxserver.io ) malforms the database with no apparent reason (server shutdown, etc.) - again and again. Each time, I have to (recommended fix) remove the index folder, re-scan, and remove all the sync-conflicts that have piled up until I notice the problem again. For a productive server, this issue is really more than annoying... According to the Syncthing forum, this might be related to the docker containers (both Linuxserver.io and binhex) using the SQLite. The SQLite Go backend seems not really well tested, so the recommended solution is to use the original Syncthing package (or something closer to it) instead. Is there a docker container for Syncthing with a non-SQL backend? Or is it possible to install the original Syncthing package on Unraid?

OK. Da ist ja echt viel zu durchdenken... Ich schaue mir mal die Spinups an und überdenke dann meine Strategie. Schonmal vielen Dank für die geduldigen und hilfreichen Antworten! Das Array ist schon ein typisches Datengrab-Daten, bei dem nur selten was passiert und das auch nur sporadisch eingesehen wird (v.A. Archiv Daten und Familien-Fotos/-Videos - Alltagsdaten sind im Cache). Aber mit XFS muss ich mir dann wohl zum Cache parallele neue Lösungen ausdenken für: A) eine Time Machine (statt Snapshots), um versehentlich überschriebene (und ggf. schon nach-gesicherte) Dateien re-rollen zu können, und B) ein zeit- und speichereffizientes Backup (differentiell-inkrementellee Kombi) mit täglichem Voll-Abgleich (statt der direkten Replication zwischen ZFS-Platten). Das ist halt Alles so schön schnell, einfach und einheitlich mit ZFS... 😉

Bitte entschuldigt, wenn ich so genau nachhake - Ich schätze Eure Expertise und möchte es einfach auch selbst verstehen: Dass XFS auch solide ist, und dass ZFS im Array nicht alle Funktionen ausspielen kann, ist schon klar. Das wäre für mich auch vollkommen OK, denn Snapshots und Replication zum ZFS Backup-Pool funktionieren ja trotzdem auch bei Einzel-Datenträgern (Was XFS nicht kann, soweit ich weiß). Das wären immer noch Vorteile, die ich auch nutze. Was ich noch nicht so richtig greifen kann: Was an ZFS-Einzelplatten im Array ist denn der Nachteil? Also versucht ZFS z.B. dauernd, auch bei denen Bits gegen Rotting zu ändern? Und weckt es dann dazu auch ständig die Parity (oder das gesamte Array) auf? Ich habe schon den Eindruck, dass das Array bisher fast immer erst hoch-spinnen musste, wenn ich darauf zugreife. Aber vielleicht passieren ja andere Dinge, die mir als Einsteiger noch entgehen...

@saber1, @DataCollector: Schon mal vielen Dank - Das hat mir weitergeholfen! Ich habe es jetzt auf 50 (-3) °C eingestellt, und auch das hätte dann ja noch etwas Reserve. Ich dachte, ich hätte irgendwo gelesen, dass es nicht dauerhaft über 40 °C sein soll - Aber das ist ja dann wohl weit ab von realistisch... Insgesamt ist das dann mit dem Gehäuse ja viel entspannter, als ich bisher das Gefühl hatte. OK... Das Array ist als reines Datengrab ja eher selten hochgefahren (Regelmäßig zugegriffene Shares gehen bisher komplett über den Cache). Und ja, man hat nicht alle Vorteile von ZFS - aber einige coole Features eben doch, die mir wichtig waren (Snapshots als Ressourcen-sparsame Time Machine, direkte Replication). Wäre das bei 6.X schon gegangen, hätte ich vielleicht auch gleich zwei ZPools ohne Array gemacht. Andererseits ist ein Unraid-Array ja schon auch reizvoll für einfache Erweiterbarkeit und Upgrade-Fähigkeit der Dauer-Daten (Wobei die 16 TB wahrscheinlich für viele Jahre reichen werden...). Vielleicht habe ich da einfach den deutlichen Nachteil der Kombi "Array mit ZFS-disks" noch nicht geblickt... Mein Setup hat bisher jedenfalls auch noch mehr als genug Reserven für meinen Use Case (Das ist vielleicht bei Anderen enger...).

Symptome: ca. alle 20 Minuten wird der Parity Check für 15 Minuten unterbrochen, weil disk1 (nie parity) "überhitzt" (42 °C). Das passt auch zu den Einstellungen: "Disk Settings > Default warning disk temperature threshold" steht bei 45 °C. "Parity Check Tuning > Pause an array operation at" steht bei 3 °C (eigtl. K...), "Resume an array operation at" steht bei 8 °C (eigtl. K). Braucht es diese Margen, oder kann ich getrost die Temperaturgrenze erhöhen / die Resume-Abkühlung absenken? Oder habe ich ein tatsächliches Kühlungsproblem? Das Gehäuse ist durch das MiniATX-Netzteil ja schon recht un-luftig. Aber die Platten sitzen ja auf der unteren Etage, und der Prozessor hat ja kein Problem. Im sonstigen Betrieb läuft es gut, und die Platten gehen auch erkennbar erst bei Bedarf an (Das meiste läuft über den NVME-Cache-Pool). Details zu meinem Setup bei Bedarf: Unraid 6.12.14 (Ich traue mich noch nicht, mit dem produktiv genutzten System den Sprung auf 7.x zu machen). Jonsbo N3 mit derzeit noch 3 HDDs nebeneinander: Slot 1 Parity, Slot 2 disk1 (beide Exos 18 16 TB), Slot 3 "Backup". Die Dauer-Föhn-Lüfter hatte ich gegen eine leisere Arctics getauscht mit einer einstellbaren 40 % / 60% / 100 % Umschaltung (Da könnte ich bei Bedarf nochmal ran, aber eigentlich läuft das im sonstigen Betrieb gut). Array aus parity und disk1 (jeweils auf ZFS) Parity Check alle 3 Monate - Bisher OK. Änderungen seither: disk1 ist jetzt nicht mehr auf einer Seite frei, sondern sitzt zwischen Parity und Backup-HDD (1. Platte eines ZFS Pools, der noch eine zweite HDD bekommen soll). etliche letzte Daten von Diskstation nach Unraid-Server migriert Da dürften nochmal ein halbes TB oder so dazugekommen sein, aber das sollte den Server nicht in die Knie zwingen) NVME 1x 1TB (ZFS) gegen 2x 2 TB (ZFS-Pool) getauscht (dürfte ja keinen Einfluss haben). Syncthing installiert und in Nutzung ZFS Snapshots und Replication nach "Backup" gemäß Anleitung SpaceInvador1 eingerichtet.

Thanks - I found that info just now, too, in the German forum, with the hint that UMASK needs to be set to 002 instead of 022 to result in the correct chmod code. That worked. Thanks for your response!

Erst einmal herzlichen Dank - Ich bin an dem Thema fast verzweifelt und hatte im englischen Programming Forum im Synthing Thread keine Antwort bekommen - Jetzt nochmal hier gesucht, und siehe da... UMASK 022 => 002 und "Permission Ignore" -> gelöst 🙂 Dabei ist mir hier noch was aufgefallen: Müsste es beim find-Befehl dann nicht "chmod 775" statt 755 heißen, damit die Berechtigungen für SMB-User stimmen? Ansonsten hatte ich diese Kombi noch nicht auf dem Radar - Sehr nützlich, danke!

Has anyone else solved this? It does not seem like an unusual use case... Or have I missed a solution in the forum?

@binhex So how do I set consistent permissions between the syncthing docker and SMB users? All Users (incl. "nobody" which runs syncthing) are members of GUID 100 ("Users"). But when I create a file or folder on a remote device, permissions on the Unraid NAS are set to 755 for folders resp. 644 for files - So a SMB-User has no permission to create files in a new folder, or modify a file. However, when I create a file/folder via an SMB user, its permissions are set on Unraid to 777 for folders, or 766 for files (i.e. (only) the owner is allowed to execute any file, e.g. test.txt ...).. Is there any way to change the permissions for files received from remote (within the guid 100 "users") - without having to grant root permissions to Syncthing?

This did not seem to work for me... I sync several shares with my Windows notebook (and a few with my Android phone). When I create files/folders/subfolders on Windows, the newly synced folders on the Unraid share receive 644 permissions - So they cannot be modified via "normal" users with SMB read/write permission... After checking "Ignore permissions", the behavior is the same - Is there anything else required for Syncthing to assign new data the same permissions as the share?

Awesome - Thanks. That worked like a charm. Ladies and gentlemen: We have backups! 🙂

I am trying to replicate my Array (2 ZFS-HDDs => Source disk1) and Cache Pool (2 ZFS-NVMEs, source "cache") to a Backup Pool (2 slots, but currently only 1 ZFS-HDD - other will follow; destination "backup"). @SpaceInvaderOne's script does snapshots, but then fails replication. Error: cannot receive new filesystem stream: pool must be upgraded to receive this stream. mbuffer: error: outputThread: error writing to at offset 0x40000: Broken pipe mbuffer: warning: error during output to : Broken pipe What does "new filesystem stream" and "pool must be upgraded" mean? For background: At first, I created (using ZFS Master) one parent data set "replication" for two scripts (error see above), but then realized that "direct mirror" will only keep data sets that are in source, so replication would delete each other. So I created two parent data sets "disk1-backup" and "cache-backup", one for each script. I also tried to make the backup pool just one slot (no empty slots). Same error, though. I also posted this issue as a response to a similar issue in the "programming" forums section - But I think it is better to make a separate thread, and it seems to fit better in this forums section - Sorry for the doublet.

For me, the replication script also seems not to be working: I created two scripts, one for "disk1" (I run ZFS in the array) and one for "cache" (also a ZPool). I tried pointing them to the local ZFS pool "backup" (2 slots, but currently only one drive) with the mutual parent dataset "replication" /created with ZFS Master, not with Add Share). Snapshots of all datasets were created (I used the autodetect). But for replication, I go an error for all datasets: cannot receive new filesystem stream: pool must be upgraded to receive this stream. mbuffer: error: outputThread: error writing to at offset 0x40000: Broken pipe mbuffer: warning: error during output to : Broken pipe I am not sure whether I have to "upgrade" to Unraid 7 for this to work... (I avoided that for now, until I have a replication as a true backup). I also read in the script that the strict-mirror mode will delete dataset not present in source - which should be a problem with two separate scripts pointing to the same destination dataset. So I created two separate parent datasets (disk1-backup, cache-backup) and added them to their respective script. I also tried to have the ZPool Backup with only 1 slot. Neither helps - The error persists. I am not sure whether it is the same issue as the OP - If not, let me know and I will open a separate thread.

Danke ebenfalls! Twonky scheint aber auch kommerziell / nicht Open Source zu sein. Wenn ich die Website richtig verstehe, braucht man auch eine Lizenz, die dann zwar etwas günstiger als Emby/Plex ist - aber immer noch ziemlich beeindruckend für eine Standard-Funktion (Ich brauche einfach nur Endgeräte-DLNA-Zugriff auf meine Musik-Bibliothek). miniDLNA scheint mir für meine Zwecke erstmal völlig ausreichend. Vielleicht kommt der Apetit auf mehr dann ja noch beim Essen...😄 Ein bisschen habe ich das Setup und die config ge-tweakt, um mehr Verzeichnisse angeben zu können (Ich habe nicht alles zusammen in einer "Media"-Freigabe, sondern dedizierte Freigaben für Audio, Video, Fotos usw.) - So etwas muss bei dem miniDLNA-Plugin dann doch etwas angepasst werden.

Ja, vom Gehäuseabstand dürfte das passen, aber das Problem ist eher die Seitenaufhängung, die dann neu gedacht werden muss: Die Durchgangslöcher für die Befestigungsschrauben habe ich ohnehin unten links / Mitte oben nur mit Mühe in die Kastenprofile gewürgt bekommen. Bei meiner Lösung liegen die dann in Seitenwänden (rot durchgezogen). Mit der lila durchgezogenen Anordnung wäre das Problem raus. Aber Du kannst aufgrund des Radius in der abgerundeten Gehäuseabdeckung das Gestell nicht einfach höher bauen - sondern musst die PSU daran verschieben. Und das macht Probleme: Bei meiner Lösung sind so die Luftauslässe am Rand nur minimal bedeckt, und die Kaltgeräte-Buchse passt knirsch in die Aussparung (Der Netzschalter hat noch etwas Luft). Wenn Du die PSU höher ziehst, brauchst Du da ein luftigeres Seitengestell mit weniger oberer Abdeckung der Belüftung und einer Aussparung für die Buchse (Problembereiche in rot gepunktet). Dann musst Du noch gucken, wie Du die Durchgangsbohrungen oben links und unten rechts nicht direkt in der Profilseitenwand einlässt. Jedenfalls bei den 20er Kastenprofilen aus Baustahl - zugegebenermaßen eine recht erdbebensichere Lösung... Bei entsprechenden Fertigungsmöglichkeiten kann man das sicher luftiger gestalten, bei immer noch ausreichender Verwindungssteifigkeit gegen das Biegemoment vom Netzteilgewicht. Ein Gestell aus Kastenprofile mit Verschraubung am Boden (auf dem Foto fehlen da noch die Schlitze im Fuß für die Schrauben) sind da quasi das Optimum, und halt eine Bastler-freundliche Lösung, um das Gewicht an mehr Punkten am Gehäuse abzustützen. Die mitgelieferten dünnen Blechlein für auf dem Boden stehende PSU-Montage würden sich da einfach tordieren.