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.

Danke für die rasche Antwort! Das probiere ich aus dann mal aus!

Wie bekomme ich ein DLNA-Zugriff inkl. Zugriff via Verzeichnisstruktur (so wie Synology DSM, viele andere Media-Server oder Kodi es anbieten)? Jellyfin kann und will das offenbar nicht. Die "plain folders" Option ist dann nicht strukturiert, sondern schmeißt Alles auf Top-Level zusammen. Und trotz Top20 Feature Request mit hunderten Anfragen scheint das gegen den Strich der Devs zu gehen. Plex und Emby nehmen Lizenzpreise, die teurer sind als Unraid selbst, Außerdem bevorzuge ich OpenSource schon deutlich (Da spende ich lieber mal). Es mag ja Menschen geben, die kein Problem damit haben, ihre Musik-Sammlungen und Abruf-Gewohnheiten nach der Software zu richten - Aber die vorgegebene Struktur zum Metadaten-Scraping bekomme ich nicht durch- oder umgesetzt, und DLNA muss für die Familie halt nutzbar sein, bevor ich ganz auf Unraid wechsle. Ich habe gelesen, dass als Workaround Manche Kodi installieren und dann mit den Fernbedienungs-Apps arbeiten. Notfalls wäre das noch ein Weg, aber ich weiß z.B. nicht, ob unser AVR als Empfangsgerät das hinbekommt...

Hi @serpro, I have not done a lot with it yet, tbh - No tweaking, and yes, the BIOS options were a bit too impressive for my state of knowledge to go into details and do research. Sorry for the late and lacking reply - While I do have the need to get into it more, I am currently pretty caught up in other stuff of higher priority (sadly).

@Joczek Not me. I have not tried to update the BIOS yet. I have very little time, my progress is really slow, and I have not yet gotten to the point of optimization. No, if you are not referring to optimization. I had to change one BIOS option for it to auto-boot without hitting enter on a keyboard. Other than that, it worked out of the box. But again, this is not advanced requirements level. I am still learning, it's been literally decades that I built mini tower PCs before, I always used notebooks ever since. From what I read at Amazon, the BIOS update archive is broken because of a wrong flash tool (which can be exchanged, appearently fpt.efi is wrong and fph.efi is right, but it is not clear where to get the fph.efi from the review). I will have to look at that myself, at some point. Sorry if that is not much help.

Alles gut 🙂 Ich habe Unraid tatsächlich auch nicht gekauft, um der CLI vorgaukeln zu müssen, hier säße ein voller Linux-Admin. Aber an dieser Stelle muss die webGUI wohl noch etwas reifen (oder ich hätte halt das Skript von Spaceinvador One anwerden sollen...). Da ich gerade einsteige und 6.13 in den Startlöchern steht, wollte ich allerdings die Weichen richtig stellen, bevor ich dann wieder das ganze FS umstellen muss, und gleich ein stimmiges Konzept mit Snapshots usw. aufziehen. Aber stimmt, wer Teilimplementierungen nutzt, muss halt auch mit etwas ruckeligem Fahrwerk rechnen... 🤷‍♂️

Solution: It works, even with chmod -R 775 - I realized that "users" is the GID and tried that. So Unraid does support user groups (sorry for the misinterpretation - The post I had that from was in 2018...). I do not know why shares are 777, and why newly created sub-datasets do not inherit the permissions of the share. But that seems to be how Unraid does things.

@hawihoney Es tut mir leid, falls Du irgendwo rausgelesen hast, dass ich Dir ein single ZFS im Array aufschwatzen wollte, oder dass ich Dich nötigen wollte, über Unbekanntes zu spekulieren. Das war auch mehr an Leute gerichtet, die an ZFS Interesse haben, das schon für das Array probiert haben (Es gibt dazu Posts), über das recht offensichtliche Problem gestolpert sind, und vielleicht schon eine Lösung gefunden haben. Die lautet übrigens: Unraid macht Alles ein bisschen anders... Als ich den Besitzer nobody gesehen habe, wurde es mir dann klar: root@NAS:~# ls -la /mnt/user/media total 12 drwxrwxrwx 1 nobody users 4 Mar 5 14:32 ./ drwxrwxrwx 1 nobody users 9 Mar 3 12:09 ../ drwxr-xr-x 1 nobody users 2 Mar 5 14:31 audio/ drwxr-xr-x 1 nobody users 2 Mar 5 14:32 video/ root@NAS:~# chmod -R 775 /mnt/user/media/* Offenbar macht Unraid Shares mit 777 🤔 und regelt dann den Zugriff anders - Die sub-Datasets erben das aber nicht... Chmod 777 geht mir auch irgendwie gegen den Strich, also chmod 755. Dann läuft auch Alles wie erwartet 🙂

@wohlben Glad it helped someone 👍 Just to be clear: "It's not worth it" referred to the modding effort - not to the case itself. You know, it really depends on your use case: If you want an straightforward, efiicient, low-noise design, with little cost and effort for modding, there are clearly better options out there. But if you look for a design for an inexpensive miniITX-combo that actually fits into a shelf*, while allowing for many HDDs, including hotswap for e.g. for offsite backup disks, then I would not know of any alternative (not talking about a better alternative, I did not find anything, but tbh, I am new to all this). The small depth of the two-level design being really key here, at the cost that it leaves not enough height for an ATX PSU. And PSX seems to be an area where most manufacturers do not exactly excel. But as @jit-010101 pointed out correctly, that can be solved with alternative power supplies, depending on your use case: The picoPSU would limit the drive options; however, there are reports of more than 4 disk builds powering up in parallel with a 160 W picoPSU, if that suffices - Going over peak for a short time works, appearently. Still: It's a 8 HDD +2 SSD bay case, and I did not want to have an external extra coltage converter / cable power supply. I have not looked if the HDPlex gan would fit, and only browsed the efficiency report superficially. But they look really promising, and with the new 500 W unit out, you should have enough power to support enough HDDs to populate the case. The hardest bullet to bite is the 100 or 92 cm double fan design - again, a tribute to the short depth, two-level design - I wondered if you can fit an external larger fan, but then I looked at the power cable and the network ports of the MoBo right in the middle of the back plane and realized there is no way around the design as it is. I bought two Arctic double bearing 92 mm fans with a daisy chain connector, and a fan controller for a few bucks that could control the fan speed via temperature - but it does not work well, the disk temperature sometimes exceeds 45 °C, and the fans do not react (the sensor is not attached to one drive, so it measures compartment instead of disk temperature). But it has a trim resistor for one fan connector, so I will try to find a sufficient smaller permanent speed for the disks inside. Maybe Jonsbo comes up with an even better short depth design where the MoBo is on the bottom or side, and there is only a partial second level for the HDDs (to allow a larger diameter fan in the back). But then they would have to figure out where to place the PSU... While I see many compromises in the design, Jonsbo has really drawn out a lot of a mini-cube/max-function concept. There is really not much freedom of design left, with such a compact 8 hotswap bay NAS case...

@JorgeB I used the ZFS Master plugin: Main > ZFS Master > Create Dataset. e.g. "disk1/media/audio" (I left all defaults). Share security level "secure" was set in the share > SMB menu, with Read/Write user access to my main user. I had already deleted the datasets and created folders, but I reverted that for research here: root@NAS:~# ls -la /mnt/user/media total 12 drwxrwxrwx 1 nobody users 4 Mar 5 14:32 ./ drwxrwxrwx 1 nobody users 9 Mar 3 12:09 ../ drwxr-xr-x 1 nobody users 2 Mar 5 14:31 audio/ drwxr-xr-x 1 nobody users 2 Mar 5 14:32 video/ Looking at the owner "nobody" and the permission pattern, I start to wonder how one should specify write access other than chmod 777, actually - as Unraid does not seem to use permission groups to assign to users. The share has chmod 777, so it actually might be that the sub-datasets probably need that, too, then... So Unraid seems to manage permissions with a different mechanism, obviously...?

Is it possible to write to nested / sub-datasets in a ZFS array disk via SMB? I chose ZFS for it (next to the parity drive), and I created a share / dataset "/media" and, below, sub-datasets "audio", "video", etc. (instead of folders). But while I can create files from Windows Explorer in the main share-dataset /media, I cannot in the sub-datasets (like in "/media/audio"). SMB security for all datasets is "secure", with additional write-permissions to the unraid-user (which is registered in windows and validated for the main share-datasets). But even if I change SMB security to "private" (with permissions for the Unraid user), it does not work... When researching before posting, I found a thread about the ZFS plugin in 2022 stating to chmod 777 the complete dataset - But I am not sure if removal of all access control is the intended design, or just a work-around at an early stage. I am aware that ZFS is waiting for a lot function to be implemented yet, so I wonder if I am doing it wrong, or if I have to wait for 6.13. The ZFS tutorials by Spaceinvader One to his scripts show that he actually created sub-datasets /appdata for each app - which makes sense to keep the snapshots scope small. A work-around would be to create parallel shares for each type of media (which seems not appropriate, though), or to use folders below the share-dataset and have the snapshots for the whole share for now. Another approach would be to simulate an array with a pendrive and make a full RAIDz pool, but I'd rather keep the flexibility of the Unraid array. I am aware the some advanced features will not work in a non-RAIDz Unraid array - So chosing ZFS for a one-disk plus parity array might seem odd. But I am really keen on the compression and snapshot features that XFS does not offer, and that should work even on a single ZFS disk (as I understand it). So even if ZFS is yet to be fully implemented, it seems to have benefits and no drawbacks I could see over XFS (for a single disk). But I might be on a completely wrong path here because I am pretty new to Unraid and ZFS.