Michael Lanzl

Oh man, es könnte so einfach sein. Ich hatte garnicht mehr auf dem Schirm das ich da mal mit Powertop usw. experimentiert hatte. Alles entfernt - läuft. Vielen Dank für die Turbo schnelle Hilfe!

Hey, Habe vorhin meinen Server auf 7.1.2 geupdatet, leider bekomme ich ihn jetzt nicht mehr zum laufen. Boot läuft durch bis zum Anmeldeprompt, lässt sich auch während des Bootens pingen (sobald halt das Netzwerk initialisiert wird) Sobald aber der Anmeldepromt kommt, kommen nur noch timeouts zurück. In den normalen GUI Mode komme ich auch nicht, sehe nur ein schwarzen Bildschirm mit einem nicht blinkenden cursor oben links. Der GUI Safe Mode funktioniert aber. Einstellungen sehen für mich erstmal alle OK aus, aber eben kein Netzwerk. Wenn ich das Kabel ab und wieder anstecke, habe ich für 5 Zyklen einen Ping dann aber wieder Timeouts. Hardware scheint wohl ok zu sein. Ich hänge mal die Diagnostics mit an, vielleicht fällt euch dort was auf. VG Michi monkeyserver-diagnostics-20250520-1202.zip

Leider sind die NFS Einstellungen in meinem alten WD My Cloud NAS sehr rudimentär. Aber Squash war das richtige Stichwort. folgende Zeile habe ich in der /etc/exports auf dem NAS angepasst. "/nfs/duplicacy" 172.30.2.1(rw,no_root_squash,sync,no_wdelay,insecure,no_subtree_check,anonuid=99,anongid=100) geändert hatte ich von "all_squash" auf "no_root_squash" und die ID`s auf nobody angepasst. jetzt kann Duplicacy sowohl auf die über ssh übertragenen Daten als auch auf die die über NFS geschoben wurden zugreifen. Danke für den Tipp!

Nicht ganz. Das Skript von SpaceinvaderOne das ich verwende erstellt erstmal ZFS Snapshots und schiebt dann die Daten aus den Snapshots mit rsync auf mein NAS. Duplicacy soll das dann um den offsite Part erweitern und die Daten vom NAS in die Cloud schieben. Aber egal welches Tool ich am Ende dafür verwende, des Problem ist aktuell wohl das NAS und die Rechte. Aktuell fällt mir auch nur ein, die Rechte nach dem sichern auf dem NAS einmal zu überschreiben, oder das Skript die Daten nicht über SSH sondern direkt auf den SMB Share schreiben. Dann spare ich mir das nachträgliche anpassen. Privilegierte Rechte hat übrigens auch nichts geändert. Ich habe auch statt SMB mal NFS getestet, ähnliches Problem.

Hey, danke für deine Antwort. Das habe ich tatsächlich noch nicht Probiert, würde das auch gerne vermeiden. Von duplicati habe ich schon einige negative Sachen gelesen wenns um's zurückspielen der Backups ging, deswegen bin ich erstmal auf Duplicacy gegangen. Borgbackup sieht auch interessant aus, spielt aber soviel ich auf die Schnelle gesehen habe nicht mit meinem Cloudspeicher. Ich habe zwischenzeitlich ein bisschen weiter getestet. Ich habe mir mal den rsync Befehl aus dem Skript genommen und für einen Test umgestrickt: rsync -azvh -e ssh /mnt/cache/appdata/duplicacy/.zfs/snapshot/autosnap_2025-03-06_11\:08\:37_daily/ [email protected]:/shares/duplicacy/test1/ im Original kommt halt noch --delete und --link-destination für die Hardlinks dazu, aber das brauchen wir für den test ja nicht. Wichtig, die Rechte Optionen sind identisch. Als erste einmal die Rechte und Owner im Original Ordner: root@Unraid:/mnt/cache/appdata/duplicacy/.zfs/snapshot/autosnap_2025-03-06_11:08:37_daily# ls -hla total 43K drwxrwxr-x 7 root root 12 Mar 6 00:46 ./ drwxrwxrwx 9 root root 2 Mar 6 11:20 ../ drwx------ 3 nobody users 4 Mar 5 22:42 bin/ drwxrwxr-x 3 root root 3 Mar 2 17:13 cache/ -rw------- 1 root root 4.3K Mar 6 00:46 duplicacy.json drwx------ 3 nobody users 3 Mar 2 17:39 filters/ -rw------- 1 nobody users 171 Mar 2 17:15 keyring -rw------- 1 nobody users 1.1K Mar 2 17:43 licenses.json drwxrwxr-x 3 root root 15 Mar 6 00:40 logs/ -rw-rw-r-- 1 nobody users 33 Mar 2 17:13 machine-id -rw-rw-r-- 1 nobody users 144 Mar 2 17:13 settings.json drwx------ 4 nobody users 4 Mar 2 17:13 stats/ Ergebnis des rsync über ssh: root@Unraid:/mnt/remotes/172.30.2.21_duplicacy/test1# ls -hla /bin/ls: bin: Permission denied /bin/ls: filters: Permission denied /bin/ls: logs: Permission denied /bin/ls: stats: Permission denied /bin/ls: duplicacy.json: Permission denied /bin/ls: keyring: Permission denied /bin/ls: licenses.json: Permission denied total 24K drwxrwxrwx 2 nobody users 0 Mar 6 00:46 ./ drwxrwxrwx 2 nobody users 0 Mar 6 21:50 ../ drwxrwxrwx 2 nobody users 0 Mar 5 22:42 bin/ drwxrwxrwx 2 nobody users 0 Mar 2 17:13 cache/ -rwxrwxrwx 1 nobody users 4.3K Mar 6 00:46 duplicacy.json* drwxrwxrwx 2 nobody users 0 Mar 6 21:50 filters/ -rwxrwxrwx 1 nobody users 171 Mar 2 17:15 keyring* -rwxrwxrwx 1 nobody users 1.1K Mar 2 17:43 licenses.json* drwxrwxrwx 2 nobody users 0 Mar 6 21:50 logs/ -rwxrwxrwx 1 nobody users 33 Mar 2 17:13 machine-id* -rwxrwxrwx 1 nobody users 144 Mar 2 17:13 settings.json* drwxrwxrwx 2 nobody users 0 Mar 6 21:50 stats/ Und hier nochmal der Ordner direkt über ssh abgerufen: root@backup test1 # ls -hla drwxrwxr-x 7 root root 4.0K Mar 6 00:46 . drwxrwxrwx 17 root root 4.0K Mar 6 21:50 .. drwx------ 3 nobody netdev 4.0K Mar 5 22:42 bin drwxrwxr-x 3 root root 4.0K Mar 2 17:13 cache -rw------- 1 root root 4.3K Mar 6 00:46 duplicacy.json drwx------ 3 nobody netdev 4.0K Mar 2 17:39 filters -rw------- 1 nobody netdev 171 Mar 2 17:15 keyring -rw------- 1 nobody netdev 1.0K Mar 2 17:43 licenses.json drwxrwxr-x 3 root root 4.0K Mar 6 00:40 logs -rw-rw-r-- 1 nobody netdev 33 Mar 2 17:13 machine-id -rw-rw-r-- 1 nobody netdev 144 Mar 2 17:13 settings.json drwx------ 4 nobody netdev 4.0K Mar 2 17:13 stats Direkt auf dem NAS sehen die Rechte wie im Original aus, über den SMB Share zugegriffen gibt es aber Probleme, obwohl hier die Rechte für alle auf rwx stehen. Jetzt habe ich das ganze mal nicht über ssh sondern direkt mit rsync auf den smb share geschoben: rsync -azvh /mnt/cache/appdata/duplicacy/.zfs/snapshot/autosnap_2025-03-06_11\:08\:37_daily/ /mnt/remotes/172.30.2.21_duplicacy/test Ergebnis: root@Unraid:/mnt/remotes/172.30.2.21_duplicacy/test# ls -hl total 24K drwxrwxrwx 2 nobody users 0 Mar 5 22:42 bin/ drwxrwxrwx 2 nobody users 0 Mar 2 17:13 cache/ -rwxrwxrwx 1 nobody users 4.3K Mar 6 00:46 duplicacy.json* drwxrwxrwx 2 nobody users 0 Mar 2 17:39 filters/ -rwxrwxrwx 1 nobody users 171 Mar 2 17:15 keyring* -rwxrwxrwx 1 nobody users 1.1K Mar 2 17:43 licenses.json* drwxrwxrwx 2 nobody users 0 Mar 6 00:40 logs/ -rwxrwxrwx 1 nobody users 33 Mar 2 17:13 machine-id* -rwxrwxrwx 1 nobody users 144 Mar 2 17:13 settings.json* drwxrwxrwx 2 nobody users 0 Mar 2 17:13 stats/ und hier nochmal über ssh abgerufen: root@backup test # ls -hla drwxrwxrwx 7 unraid share 4.0K Mar 6 00:46 . drwxrwxrwx 17 root root 4.0K Mar 6 21:50 .. drwxrwxrwx 3 unraid share 4.0K Mar 5 22:42 bin drwxrwxrwx 3 unraid share 4.0K Mar 2 17:13 cache -rwxrwxrwx 1 unraid share 4.3K Mar 6 00:46 duplicacy.json drwxrwxrwx 3 unraid share 4.0K Mar 2 17:39 filters -rwxrwxrwx 1 unraid share 171 Mar 2 17:15 keyring -rwxrwxrwx 1 unraid share 1.0K Mar 2 17:43 licenses.json drwxrwxrwx 3 unraid share 4.0K Mar 6 00:40 logs -rwxrwxrwx 1 unraid share 33 Mar 2 17:13 machine-id -rwxrwxrwx 1 unraid share 144 Mar 2 17:13 settings.json drwxrwxrwx 4 unraid share 4.0K Mar 2 17:13 stats Erstmal keine Permission denied Meldung, die Rechte sind gleich geblieben aber der Owner wurde geändert. "unraid" ist der user auf dem NAS der Schreibrechte auf dem Share hat. Eigentlich ist das was über ssh geschoben wird das Richtige, nur das unraid über den Share nicht richtig drauf zugreifen kann. Ich denke mal es liegt an irgendwelchen User Rechten auf dem NAS selber. Mir würden jetzt spontan folgende Sachen einfallen: 1. Das Skript so bearbeiten das es statt über ssh direkt über den SMB Share auf das NAS kopiert 2. Oder das Skript gleich so umschreiben das der Rsync erstmal auf einen anderen Pool geschrieben wird, dann mit Duplicacy hochgeladen wird und erst danach auf den NAS. Das würde wahrscheinlich auch die Backupzeit reduzieren, weil nicht erst auf das NAS geschrieben wird und dann wieder davon die Daten für Duplicacy geholt werden müssen. 3. Oder eine weitere Platte einbauen auf zfs und direkt darauf sichern und dann weiter mit Duplicacy 4. In dem Skript werden für Rsync temporäre Snapshots angelegt, man könnte das Skript so umbauen, das Duplicacy die gleich mit verwenden kann.

Moin, ich hol mal ein bisschen weiter aus, vielleicht lässt sich das Problem dann ja auch schon an einer anderen Stelle lösen. Ich teste gerade Backupstrategien für meinen Unraid Server (7.0.0) Bisher hatte ich meine Backups mit dem Appdata Backup Plugin auf ein WD NAS gesichert. Das NAS ist über SMB Shares in Unraid gemountet, es gibt noch weitere Shares für das Nextcloud AIO eigene Backup und für die iobroker backups. Das hat soweit auch immer gut funktioniert. Jetzt wollte ich mich aber doch mal um ein weiteres ausgelagertes Backup kümmern, dafür habe ich mich für Duplicacy in Verbindung mit iDrive e2 entscheiden. Da das Appdata Backup Plugin aber alles in Archive verpackt, macht das mit inkrementellen backups keinen Sinn, so würden ja jedesmal alle Daten neu in den Cloud Speicher geschoben. Bin dann auf das zfs snapshot & replication Skript von SpaceinvaderOne gestoßen, damit lasse ich jetzt Appdata und meine wichtigen Datasets mit rsync auf das WD NAS sichern. Das funktioniert schon mal ganz gut. Jetzt sichere ich mit Duplicacy den gesamten Ordner vom NAS in den rsync die Daten geschoben hat auf iDrive e2. Auch das funktioniert eigentlich ganz gut, aber... Im Log finde ich sehr viele permission denied und cannot be opened Meldungen, in Summe 157 Verzeichnisse und 2714 Dateien. Hier mal ein kurzer Auszug aus den logs: 2025-03-04 11:28:14.683 WARN LIST_FAILURE Failed to list subdirectory cache_system/2025-03-03_0245/docker/: readdirent /data/cache_system/2025-03-03_0245/docker: permission denied 2025-03-04 11:28:14.798 WARN LIST_FAILURE Failed to list subdirectory cache_system/2025-03-03_0918/docker/: readdirent /data/cache_system/2025-03-03_0918/docker: permission denied 2025-03-04 11:28:14.886 WARN LIST_FAILURE Failed to list subdirectory cache_system/2025-03-03_1038/docker/: readdirent /data/cache_system/2025-03-03_1038/docker: permission denied 2025-03-04 11:28:15.353 WARN OPEN_FAILURE Failed to open file for reading: open /data/rsyncd.secrets: permission denied 2025-03-04 11:28:15.415 WARN OPEN_FAILURE Failed to open file for reading: open /data/cache_appdata/2025-03-03_0010/ApacheGuacamole/databases/ddl_recovery-backup.log: permission denied 2025-03-04 11:28:15.454 WARN OPEN_FAILURE Failed to open file for reading: open /data/cache_appdata/2025-03-03_0010/ApacheGuacamole/databases/ddl_recovery.log: permission denied Hier scheint es wohl ein rechte Problem zu geben. ich habe dann die Permission Variablen im duplicacy Docker angepasst: PUID:0 PGID:0 UMASK:002 aber auch das brachte keine Verbesserung. Dann hatte ich die Idee, einfach nach dem rsync der Daten, einmal alle rechte mittels newperms neu zu setzten, aber auch das brachte für die Verzeichnisse immer ein Operation not permitted, trotz root rechten. Habe mit dann mal ein einzelnes Verzeichnis rausgesucht, zufällig von duplicacy selber, hier die Ausgabe von newperms: root@Unraid:/# sudo /usr/local/sbin/newperms /mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/ Processing: /mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/ ... chown -R nobody:users chown: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/bin': Permission denied chown: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/cache/localhost': Permission denied chown: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/filters': Permission denied chown: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/stats': Permission denied ... chmod -R go-rwx,u-x,go+u chmod: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/bin': Permission denied chmod: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/cache/localhost': Permission denied chmod: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/filters': Permission denied chmod: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/stats': Permission denied ... find -type d -exec chmod 777 {} \; find: ‘/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/bin’: Permission denied find: ‘/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/cache/localhost’: Permission denied find: ‘/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/filters’: Permission denied find: ‘/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/stats’: Permission denied ... sync Completed, elapsed time: 00:00:04 und so sehen die Rechte im Ordner aus: root@Unraid:/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy# ls -lah /bin/ls: duplicacy.json: Permission denied /bin/ls: keyring: Permission denied /bin/ls: licenses.json: Permission denied /bin/ls: bin: Permission denied /bin/ls: filters: Permission denied /bin/ls: stats: Permission denied total 20K drwxrwxrwx 2 nobody users 0 Mar 2 19:30 ./ drwxrwxrwx 2 nobody users 0 Mar 2 22:03 ../ drwxrwxrwx 2 nobody users 0 Mar 2 17:13 bin/ drwxrwxrwx 2 nobody users 0 Mar 2 17:13 cache/ -rwxrwxrwx 1 nobody users 3.0K Mar 2 19:30 duplicacy.json* drwxrwxrwx 2 nobody users 0 Mar 2 17:39 filters/ -rwxrwxrwx 1 nobody users 171 Mar 2 17:15 keyring* -rwxrwxrwx 1 nobody users 1.1K Mar 2 17:43 licenses.json* -rwxrwxrwx 1 nobody users 33 Mar 2 17:13 machine-id* -rwxrwxrwx 1 nobody users 144 Mar 2 17:13 settings.json* drwxrwxrwx 2 nobody users 0 Mar 2 17:13 stats/ Sind doch eigentlich für alle lese und schreibrechte vergeben (lesen sollte im fall duplicacy -> idrive eigentlich sogar reichen) mal von diesen Permission denied Meldungen von ls abgesehen. Ich bin jetzt über ssh direkt auf das NAS und habe mir dort die Rechte für den selben Ordner angesehen: root@backup duplicacy # ls -hla drwxrwxr-x 6 nobody netdev 4.0K Mar 2 19:30 . drwxrwxrwx 30 nobody netdev 4.0K Mar 2 22:03 .. drwx------ 2 nobody netdev 4.0K Mar 2 17:13 bin drwxrwxr-x 3 nobody netdev 4.0K Mar 2 17:13 cache -rw------- 6 nobody netdev 2.9K Mar 2 19:30 duplicacy.json drwx------ 3 nobody netdev 4.0K Mar 2 17:39 filters -rw------- 7 nobody netdev 171 Mar 2 17:15 keyring -rw------- 7 nobody netdev 1.0K Mar 2 17:43 licenses.json -rw-rw-r-- 7 nobody netdev 33 Mar 2 17:13 machine-id -rw-rw-r-- 7 nobody netdev 144 Mar 2 17:13 settings.json drwx------ 4 nobody netdev 4.0K Mar 2 17:13 stats sieht schon garnicht mehr so richtig aus. habe die Rechte jetzt direkt über ssh auf dem NAS für den gesamten share auf rwx gesetzt chmod -R 777 /shares/duplicacy/ Duplicacy läuft jetzt ohne Fehler sauber durch. Aber macht das Sinn? Ich bin ja kein Freund von so großzügigem Rechte verteilen, hat ja bestimmt auch einen Grund. Klar ein chmod -R 644 hätte wahrscheinlich auch gereicht, aber war ja erstmal nur zum testen. Hat jemand eine Idee warum die Rechte auf dem NAS anders sind wie wenn ich über den SMB Share darauf zugreife? Wie löse ich das Problem am saubersten? Muss ich bei Rsync noch weitere Parameter angeben? Liegt es an den Shares und Rechte Einstellungen des WD NAS? Oder habt ihr einen anderen Vorschlag für meine Backupstrategie? Grüße Michi

Hi zusammen, es wird Zeit meinen in die Jahre gekommenen Unraid Server ein Upgrade zu verpassen. Aktuell sieht mein Setup so aus: Gigabyte GA-Z79X-UD3H i5-4690K 4x 8GB Crucial Ballistic Sport XT DD3 PC3-12800 1x Crucial 250GB SSD (Cache) 3x Toshiba Enterprise MG 14GB (Array mit 1xParity) Corsair CS550M Nanoxia DeepSilence 3 GTX960 Laufen soll neben klassischer Netzwerkshares: Plex (2x 4k Hardwaretranscodes) pihole unifi controlller unbound CheckMK sabnzb diverse Arrs 1x Windows 11 VM (Gaming) 1x Ubuntu VM 1x Homeassistant VM und Luft für alles was mir die nächsten Jahre noch so einfällt Folgendes hab ich mir rausgesucht: Supermicro X13SAE-F i5-14500 Be-Quiet! Dark Rock Elite 2x Kingston Server Premier DDR5-4800 ECC CL40 32GB 2x980 Pro 1TB (evtl. 2TB) Gehäuse würde ich das alte übernehmen, steht im Büro unterm Tisch und muss nichts können oder gut aussehen, evtl. kommen mal noch neue Lüfter rein. Das alte Netzteil würde dafür wahrscheinlich auch noch reichen. Evtl. will ich die 960 aber in nicht all zu ferner Zukunft mal gegen eine 4070 tauschen und dann wird das glaub ich zu klein, also würde ich das gleich ersetzten gegen ein Be-Quiet! PurePower 12 M 850W Was haltet ihr von dem Setup? Kann man das so machen? VG Michi