T0a

After upgrading to 7.3.1 my container having extra parameters "--network" and network type "none" also failed to start with the error message "Bad Parameter". Looks like there is already a bug report with a solution present here. The solution is to remove the extra parameter configuration and use network type "container". Posting this here, because I haven't found it in the forum yet. I also created a bug report for the problem, because I haven't found the other one. Still wonder why Unraid fails to start with the extra parameter configuration variant though. Hope this helps folks experiencing the same problem.

FYI

I had the same problem yesterday with the tailscale set command. Also couldn’t access the server afterwards. I removed the server via the Tailscale Homepage from the list and rebooted. I was then able to access my server again. Don’t know yet what happened. Have not reconnected the server yet.

Thank you for your reply. Any SSL configuration with a valid top-level certificate or just `*.myunraid.net`? Unfortunately, I cannot issue a letsencrypt certificate for internal use only address home.arpa (RFC).

I use Traefik as a reverse proxy for SSL connections with a self-signed certificate for "*.home.arpa" in my homelab. Will I still be able to use the ControllR app without using the "*.myunraid.net" URL - which I don't want to use?

Update 18.02.2026: I decided to mount "/mnt/cache" as dedicated directory because symlinks are challenging in Docker container. Problem statement I discovered that my Borgmatic setup does not backup my cache only appdata directories (see error message below). While investigating, I found that the fuse mount "/mnt/user" symlinks to the cache directory for my appdata share (see code snippets below). This symlink is not available via the mount in the Borgmatic Container. I assume this changed with Unraid 6.12 & the exclusive shares feature. How to you guys handle this situation in your setup? Do you mount "/mnt" instead and adapt the Borgmatic configuration accordingly? Do you create individual mounts for your cache only shares? ... I also find it alarming that my healthcheck hook wasn't called. Seems like the backup still runs (Update 18.01.2026: Looks like the issue is treated as warning and not error. Starting with Borgmatic 2.1.0, that exit code (127) is considered an error, so you will find out about missing files) Error message: Creating archive at "<redacted>" ... /mnt/user/appdata/paperless-ngx: stat: [Errno 21] No such file or directory: '/mnt/user/appdata/paperless-ngx' ... Share Configuration: Borgmatic Container configuration: From the Unraid server console: root@server:# ls -ahl /mnt/user total 0 drwxrwxrwx 1 nobody users 107 Aug 11 09:11 ./ drwxr-xr-x 11 root root 220 Aug 11 09:01 ../ lrwxrwxrwx 1 nobody users 356 Jul 13 11:50 appdata -> ../cache/appdata/ root@server:# ls -ahl /mnt/user/appdata/paperless-ngx/ total 4.0K drwxr-xr-x 1 root root 8 Jun 5 2022 ./ drwxrwxrwx 1 nobody users 356 Jul 13 11:50 ../ drwxr-xr-x 1 nobody users 292 Aug 11 09:50 data/ From inside the Borgmatic container: /etc/borgmatic.d # ls -ahl /mnt/user/ total 0 drwxrwxrwx 1 99 users 107 Aug 11 09:11 . drwxr-xr-x 1 root root 46 Jul 7 16:53 .. lrwxrwxrwx 1 99 users 356 Jul 13 11:50 appdata -> ../cache/appdata # Cannot access appdata content, because it is a symlink /etc/borgmatic.d # ls -ahl /mnt/user/appdata/ ls: /mnt/user/appdata/: No such file or directory

I have no idea about what feature you are talking about. Can you link the feature you are trying to configure from the paperless-ngx documentation?

What kind of files fill up the space in the tmp directory? Are the troublesome files in /tmp/paperless or /tmp/paperless-scratch? Can you check if setting PAPERLESS_CONVERT_TMPDIR also works for you? You have to add a bind mount with a physical disk pointing to the same directory too. Using this variable rather than the tmp directory has the benefit that we don't rely on internal knowledge of the application. Based on this discussion: I guess for Unraid we would need to schedule a dedicated clean up via the User Scripts plugin then. For example: find <PAPERLESS_CONVERT_TMPDIR>/ -mtime +2 -type f -delete I haven't experienced this problem before, because I restart my server on a regular basis. Once the container restarts its tmp directory including the troublesome files should be removed as well. I also do not have a frequent large import volume. However, I see the problem. Waiting for your response. I will then add the variable to the template and further add a paragraph in the first post of this thread about the clean up job.

Can you give an ETA on dropping those two tiers? Or at least will you inform about the date once you know the timeframe? Under this new circumstances, I plan on buying another Plus license.

Redis wird von Paperless nur für das temporäre Verarbeiten von neuen Dokumenten verwendet und hält keine Nutzdaten. Per default verwendet Paperless eine SQLite Datenbank. Man kann aber auch eine dedizierten Datenbank wie z.B PostgreSQL verwenden, die dann auch extra gesichert werden muss. Ich vermute, dass du Paperless mit einer dateibasierten SQLite Datenbank betreibst. Diese liegt dann im appdata Verzeichnis und ist auch darüber zu sichern. Ich empfehle dir auch mal die Paperless Dokumentation hinsichtlich des Betriebs und Aufbaus zu lesen - damit sollte vieles klarer werden. Langfristig kannst du dir auch mal zur 3-2-1 Backupstrategie Gedanken machen. Insbesondere, wenn du Dokumente digital hast, die du nicht verlieren darfst.

Ich nutze das rsync Script von mgutt hier, um meine Shares auf eine externe Festplatte zu sichern. Die Backup-Festplatte habe ich über das Unassigned Devices Plugin eingehängt. Das rsync Script führe ich über das Script Plugin aus. Für Paperless sichere ich das Paperless appdata Verzeichnis und ein dediziertes Share für Paperless auf dem der media/consume/ etc. Ordner liegt. Ich nutze Paperless mit einer SQLite Datenbank. Daher muss ich keine zusätzliche Datenbank sichern. Ich nutze außerdem das appdata Backup/Restore Plugin, um meine appdata Verzeichnisse zusätzliche als tar Dateien in ein dediziertes backup Share auf dem Array zu sichern. Dieses Backup Share wird ebenfalls mit dem oben genannten rsync Skript auf die externe Festplatte gesichert. Ob du wie ich einzelne appdata Verzeichnisse direkt per rsync sicherst und zusätzlich redundant das appdata Backup/Restore Plugin nutzt musst du für dich entscheiden.

Hi, hast du mal in den paperless-ngx thread geschaut? Dort steht im ersten Post wie man migriert. Hier auch noch mal der direkte Link in die Dokumentation (Sektion „Migrating to Paperless-ngx“). Redis hält bei paperless in der Regel keine persistenten Daten. Verwendest du eine dedizierte Datenbank? Falls nicht ist es ausreichend ein Backup von dem paperless appdata directory und dem Mount deiner Dokumenten zu erstellen. Zur Migration ist es dann am einfachsten, wenn du das neue paperless-ngx Template aus der UnRaid CA verwendet und bei der Konfiguration die existierenden paperless Verzeichnisse zu verwenden. Wichtig ist, dass insbesondere das DATA Verzeichnis von der alten paperless Installation benutzt wird. Paperless-ngx führt bei der Installation dann eine Migration deiner alten paperless SQLite Datenbank aus. Falls du möchtest kannst du nach Migration und erfolgreicher Installation inkl. Tests per UI deinerseits den Container ausmachen, die migrierte SQLite Datenbank in den neuen paperless-ngx appdata Ordner kopieren und das DATA dir im paperless-ngx UnRaid Template umbiegen. Du solltest nur sicherstellen, dass du die Verzeichnisse vorher sicherst, falls etwas schief geht. Viel Erfolg.

On startup paperless ist doing some checks such as checking the various paths for existence, readability and writeability (data dir, trash dir, media dir, consumption dir). The path checks tries to write a test file to the mounted directories of your container. See here. In your case the write check fails for your consumption and data dir. I suggest checking the docker mounts and directories on your server first. My guess would be that your container is not allowed writing the mounts.

Das 32GB ECC Modul von Kingston ist wirklich super preiswert. Ich habe für den gleichen Preis vor einem Jahr ein ECC Modul mit nur 16GB von Samsung erworben. Solltest du viel mit Virtualisierung machen, bietet es sich an zeitnah ggf. ein zweites Modul zu erwerben. Ich habe zu Beginn den „Fehler“ gemacht nur ein günstiges ECC RAM Modul zu kaufen und habe zu einem späteren Zeitpunkt ein zweites Modul teurer nachgekauft. Unabhängig davon sind 32GB RAM natürlich auch für viele Szenarien ausreichend. Ich frage mich, ob der Preis mit der Einführung von DDR5 Speicher zusammenhängt oder mit einem anderen Ereignis in Verbindung steht (siehe Update) Viel Spaß beim Zusammenbauen. —— Preisverfall bei RAM (notebookcheck.com) Prognose über steigende RAM Preise (pcgameshardware.de)