Moin zusammen,

seit dem Update auf Unraid 7.3 funktioniert mein Backup offenbar nicht mehr. Ich hatte mir eine neue gekauft, weil die alte voll war, obwohl ich das mittlerweile auch anzweifle.

Vor dem Update auf 7.3 hatte ich die Platte formatiert, hinzugefügt und in Duplicacy als Backup-Ziel eingerichtet. Das hat soweit gut funktioniert und er hat 4 TB auf die insgesamt 12 TB große Platte geschrieben.

Heute sollte das nächste Regel-Backup stattfinden und es brach schlicht ab. Angeblich ist die Platte voll und er kann nicht darauf schreiben. Ich habe aber keine Idee, warum nicht. Geschweige denn wüsste ich jetzt ad hoc wo ich denn die Schreibrechte für das Laufwerk prüfen sollte. Musste ich vorher ja auch nicht, da hat er ja völlig problemlos das Backup gemacht.

Die Platte ist auch nicht "read only" gemounted und ich kann aus der Unraid-UI auch Dateien darauf schreiben.

Hat einer von euch eine Idee, was hier kaputt gegangen ist? Ohne Backup fühlt sich das alles ein wenig... unsicher... an. 😏

Die Fehlermeldung sieht so aus:

Running backup command from /cache/localhost/0 to back up /data/user
Options: [-log backup -storage backup2 -threads 1 -stats]
2026-05-14 21:47:05.055 INFO REPOSITORY_SET Repository set to /data/user
2026-05-14 21:47:05.056 INFO STORAGE_SET Storage set to /data/disks/ZZ30ENHE
2026-05-14 21:47:05.076 INFO BACKUP_START No previous backup found
2026-05-14 21:47:05.077 INFO BACKUP_INDEXING Indexing /data/user
2026-05-14 21:47:05.077 INFO SNAPSHOT_FILTER Parsing filter file /cache/localhost/0/.duplicacy/filters
2026-05-14 21:47:05.077 INFO SNAPSHOT_FILTER Loaded 0 include/exclude pattern(s)
2026-05-14 21:50:34.457 WARN LIST_FAILURE Failed to list subdirectory appdata/adguard_home/workingdir/: open /data/user/appdata/adguard_home/workingdir: permission denied
2026-05-14 21:54:12.694 WARN LIST_FAILURE Failed to list subdirectory appdata/containerd/: open /data/user/appdata/containerd: permission denied
2026-05-14 21:54:12.694 WARN LIST_FAILURE Failed to list subdirectory appdata/docker/: open /data/user/appdata/docker: permission denied
2026-05-14 21:54:12.801 WARN LIST_FAILURE Failed to list subdirectory appdata/ecodms/data/: lstat /data/user/appdata/ecodms/data/backup: permission denied
2026-05-14 21:54:18.658 WARN LIST_FAILURE Failed to list subdirectory appdata/portainer/bin/: open /data/user/appdata/portainer/bin: permission denied
2026-05-14 21:54:18.658 WARN LIST_FAILURE Failed to list subdirectory appdata/portainer/compose/: open /data/user/appdata/portainer/compose: permission denied
2026-05-14 21:54:18.658 WARN LIST_FAILURE Failed to list subdirectory appdata/portainer/tls/: open /data/user/appdata/portainer/tls: permission denied
2026-05-14 21:54:18.659 WARN LIST_FAILURE Failed to list subdirectory appdata/postgresql17/: open /data/user/appdata/postgresql17: permission denied
2026-05-14 21:54:18.659 WARN LIST_FAILURE Failed to list subdirectory appdata/postgresql_immich/: open /data/user/appdata/postgresql_immich: permission denied
2026-05-14 21:54:19.942 WARN LIST_FAILURE Failed to list subdirectory appdata/trilium/log/: open /data/user/appdata/trilium/log: permission denied
2026-05-14 21:54:19.947 WARN LIST_FAILURE Failed to list subdirectory appdata/trilium/tmp/: open /data/user/appdata/trilium/tmp: permission denied
2026-05-14 21:54:19.955 WARN LIST_FAILURE Failed to list subdirectory appdata/triliumnext/log/: open /data/user/appdata/triliumnext/log: permission denied
2026-05-14 21:54:19.956 WARN LIST_FAILURE Failed to list subdirectory appdata/triliumnext/tmp/: open /data/user/appdata/triliumnext/tmp: permission denied
2026-05-14 22:13:37.916 ERROR UPLOAD_CHUNK Failed to upload the chunk b92d9a1692df1c6ff75f09232956f6cf12f53a6f555a7e80323c9046ea61d370: write /data/disks/ZZ30ENHE/chunks/b9/2d9a1692df1c6ff75f09232956f6cf12f53a6f555a7e80323c9046ea61d370.tueutpfn.tmp: no space left on device
2026-05-14 22:43:57.665 INFO INCOMPLETE_SAVE Incomplete snapshot saved to /cache/localhost/0/.duplicacy/cache/backup2/incomplete_snapshot
Failed to upload the chunk b92d9a1692df1c6ff75f09232956f6cf12f53a6f555a7e80323c9046ea61d370: write /data/disks/ZZ30ENHE/chunks/b9/2d9a1692df1c6ff75f09232956f6cf12f53a6f555a7e80323c9046ea61d370.tueutpfn.tmp: no space left on device

"no space left on device" ist definitiv falsch. Die Platte ist komplett leer - das ist haufenweise space left. Und ich weiß nicht, warum er mir das jetzt so plöztlich ausgibt.

Edited May 14May 14 by Mephistopheles

7 hours ago, Mephistopheles said:

Die Platte ist auch nicht "read only" gemounted und ich kann aus der Unraid-UI auch Dateien darauf schreiben.

wie ist Sie denn mounted ? und dazu, die Platte wurde auch vor dem Start des Dockers in Unraid mounted ?

zeig mal eher auf wie

1/ das im Main Tab aussieht mit der UAD disk

2/ der docker mount aussieht

3/ in duplicacy dein Ziel konfiguriert ist

na ja, was fehl schlägt, ist das Lesen der Originaldaten.

"Zugriff verweigert" bei Appdata usw.

Guck Dir mal die Dateiberechtigungen da an und wem sie gehören. Eventuell läuft der Backup Docker mit dem falschen Benutzer und darf nicht an die Daten ran (und was man nicht lesen kann, darf man auch nicht kopieren...)

Es gibt zwar unter Tools den Knopf "Docker save Permissions", aber der sorgt öfters für noch mehr Ärger. Also lieber von Hand gucken und ggf, korrigieren.

55 minutes ago, alturismo said:

wie ist Sie denn mounted ? und dazu, die Platte wurde auch vor dem Start des Dockers in Unraid mounted ?

zeig mal eher auf wie

1/ das im Main Tab aussieht mit der UAD disk

2/ der docker mount aussieht

3/ in duplicacy dein Ziel konfiguriert ist

Ich glaube, der gute Hinweis war tatsächlich "war die Platte vor dem Start des Dockers gemounted". Ganz ehrlich: Das war mir gar nicht klar, dass es da eine Reihenfolge gibt... vielen Dank für den Hinweis.

Mir sind dabei allerdings Fragezeichen aufgekommen. Vielleicht hast du dazu auch eine Idee:

Ich hatte mir gedacht, es würde reichen, den Container einfach neuzustarten. Das hat nicht geklappt.

Dann bin ich also hergegangen und habe die Platte unmounted und von USB abgezogen und den Container gestoppt. Dann wieder angesteckt, gemounted, den Container gestartet.

Die nächste Meldung war dann "Storage not initialized".

Kannst du mir erklären warum?

Lösung war jetzt, dass ich das Storage einfach noch mal hinzugefügt habe - genau so, wie's vorher auch schon hinzugefügt war - und jetzt schreibt er das Backup.

Ich würde aber gern verhindert, dass es beim nächsten Mal wieder fehlschlägt und wieder sagt, dass es "not initialized" wäre. Also - ich will nicht bei jedem Unmount und Stopp des Containers (oder bei einem Neustart von Unraid wegen Update) die Backup-Konfiguration verlieren...

UAD sieht so aus:

Einstellungen in Duplicacy sehen so aus:

Wie genau zeige ich dir den Docker-Mount? 🤔

14 minutes ago, Mephistopheles said:

Wie genau zeige ich dir den Docker-Mount? 🤔

duplicacy docker icon, edit

dann hast du unten irgendwo ja deine externe disk dem lokalen docker mount zugewiesen, edit

da gibt es auch eine mount "slave" Option, genau dafür ... das man nicht immer alles neu starten muss, geht dann zumindest "meistens" ;)
sofern die UAD auch sauber mounted ist und den gleichen Namen/Pfad hat.

Mhm. Nö, musste ich da nicht zuweisen. Gibt's da auch gar nicht. 🤔

Der ganze Rest sind VPN-Konfigurationen, die ich nicht brauche.

hmm, das wird dann wohl "/data" sein... (oder das ist der Pfad zu den Quelldateien?)

Üblicherweise gibt Dir ein Hover mit der Maus oder ein Aufruf von "Edit" mehr Infos zum Sinn der Einstellung (hoffentlich :-) ) )

Musstest Du in dem DuploDingsDa irgendwo den Zielpfad unter /data einstellen?

genau, die externe Festplatte wäre unter /mnt/remotes/... zu finden.

Deinem docker übergibst Du /mnt als /data, also findest Du die Platte unter /data/remotes, sofern sie unter unraid gemountet ist.

Die Platte jetzt in Duplicati selbst zu suchen und mounten als /data/disks/ZZ30... geht vielleicht (hab ich noch nicht probiert), aber das wird problematisch, wenn du die Platte abziehst oder den docker Container stoppst (keine Ahnung, ob er diese Konfig überhaupt speichert).

Am saubersten ist es sicherlich, den Pfad per Docker Konfig zu übergeben und hier dann den Typ "Slave" einzustellen, damit sollte es auch klappen, wenn der Docker läuft und du die Platte nachträglich ansteckst/mountest.

1 minute ago, _alo_ said:

genau, die externe Festplatte wäre unter /mnt/remotes/... zu finden.

Deinem docker übergibst Du /mnt als /data, also findest Du die Platte unter /data/remotes, sofern sie unter unraid gemountet ist.

Die Platte jetzt in Duplicati selbst zu suchen und mounten als /data/disks/ZZ30... geht vielleicht (hab ich noch nicht probiert), aber das wird problematisch, wenn du die Platte abziehst oder den docker Container stoppst (keine Ahnung, ob er diese Konfig überhaupt speichert).

Am saubersten ist es sicherlich, den Pfad per Docker Konfig zu übergeben und hier dann den Typ "Slave" einzustellen, damit sollte es auch klappen, wenn der Docker läuft und du die Platte nachträglich ansteckst/mountest.

Ok.. äh.. und für Doofe: Wie macht man das? :D

4 minutes ago, Mephistopheles said:

Ok.. äh.. und für Doofe: Wie macht man das? :D

Du klickst neben dem Pfad in der Konfig auf "Edit" und wählst dann den passenden Access Mode aus.

Hier ein Screenshot von meiner Duplicati Konfiguration (sorry, hatte übersehen, dass Du einen anderen Container meinst), aber vom Prinzip ist das bei allen docker Konfigs gleich:

Du kannst es sonst auch so wie hier machen:

Dein /data so lassen und zusätzlich so ein remotes-Pfad hinzufügen (ganz unten unter über )