Junker der Provinz

Done, that's in now. The Run History on the dashboard is scrollable and shows the full recent window instead of just the last few, and there's a Day dropdown to filter down to a specific day's backups. Hover a row's time and you'll get the exact timestamp too. It's in the latest image (2.7.2). Grab the update and have a look.

Good news, the update should make that one go away. That fsfreeze message isn't a failed backup, it's the safety fallback: when Home Assistant's guest agent can't freeze the filesystem, BombVault just takes a crash-consistent snapshot instead of bailing, and the backup still completes and restores fine. The reason it reached you as an error is that it ran on an older build, which surfaced that fallback as an error notification. The current build (2.7.1) handles it silently and reports the backup as a success, so with "notify on error" you won't get pinged for it anymore. I also added the running version to the startup log in 2.7.1, so you can open the container log and confirm which build you're actually on. So let's see how the next one goes, it should be clean. If it still comes through as an error on 2.7.1, that would mean both the frozen and the crash-consistent snapshot failed (a real one), so grab that log line and I'll take a look.

That one's not a failure, it's the safety net doing its job, so your backup is fine. Here's what's happening: for a live VM backup BombVault asks the guest agent to briefly freeze the filesystem (fsfreeze) so the snapshot is application-consistent. Home Assistant's qemu-guest-agent has an fsfreeze hook wired into HA's own backup manager, and it often blocks or fails (especially around HA startup). Rather than fail the whole VM backup over that, BombVault retries the snapshot crash-consistent (without the freeze) and carries on. That's the message you saw. Crash-consistent just means the disk was captured as-is, exactly like a clean power-cut. HA recovers from that on boot like nothing happened (its SQLite recorder DB journals/recovers), so the backup is fully restorable. The only thing you lose vs a frozen snapshot is the "guaranteed quiesced at this instant" guarantee, which for HA isn't worth failing the backup over. If you want a guaranteed application-consistent HA backup, set that VM's method to Graceful (it shuts HA down for the snapshot, then starts it again) instead of Live. Otherwise Live + crash-consistent is perfectly safe to keep using. One thing to confirm: on the latest image (:2.7.0) this is just an informational line and the backup still reports success. If you're seeing it pop up as an actual red warning/failure, tell me the image tag you're on and where it shows, and I'll take a look.

Thanks a lot for trying it and for the really useful report. All three turned out to be the same root cause: the manual "back up all" was driven entirely by your browser, so anything that interrupted the browser killed the run. You found a genuinely nasty edge of it. All fixed in the latest image (:2.7.0 / :latest): "Select All" including BombVault itself. Yep, that was a self-inflicted one: when the loop reached BombVault it stopped its own container mid-backup, which killed the whole process. BombVault now knows its own container, refuses to back itself up, and is excluded from "Select All" (its card shows a short note instead of a backup button). Its own settings are recoverable separately via Discover anyway. Browser/session dependency (the Chromium one). Spot on. Each backup ran on the HTTP request that started it, so when the backup reached the Chromium container hosting your UI, stopping it dropped the connection and cancelled the running backup. Backups now run under a detached context on the server, so losing the browser no longer interrupts them. The random stops after Fenrus. Same cause: the loop lived in the browser, so any connection hiccup (or a request timeout on a long-held POST) stopped the whole sequence wherever it happened to be. "Back up selected" is now a real server-side batch: one request kicks it off and the server backs up each container in turn, fully independent of your browser. Close the tab and it keeps going; reopen it and the progress reconnects. Only one batch runs at a time. Update to the latest image and give "Select All" another go. If anything still stops, grab the container log around the point it stops and I will dig in. Thanks again, this was a great catch.

@manilx Good catch, and you're reading the policy right: with keep-daily 14 you'd expect 22/6 and 23/6 to each collapse to one snapshot. The reason it didn't happen: "Prune" only ran restic prune, which reclaims space but never applies your keep-rules. The retention (restic forget --keep-daily) runs automatically after each backup, so a policy you just set takes effect on the next backup, not on a manual prune. I've changed the Prune button so that when a retention policy is set, it now applies it (forget --keep-* --prune): clicking it collapses snapshots per your policy and reclaims space in one go. So your 22/6 and 23/6 pairs will each reduce to one. With no policy set it stays a plain space-reclaim, so it can never wipe a repo. Quick heads-up since this makes Prune able to actually remove snapshots: the confirmation dialog now spells that out. It's in the latest image (:2.6.0 / :latest, multi-arch). Update and force a prune on that VM repo and the same-day pairs should merge. Thanks again for the sharp report.

Yes, the indicator is on all three domains — Containers, VMs and Flash — both on each domain's own page and on the Dashboard (labelled per domain). What you saw is expected: you clicked "Replicate now" on the Settings page, so the feedback there is the button itself flipping to "Replicating…". The Dashboard is a separate page, and a VM replication of an already-seeded repo is quick (restic copy only ships the new bits), so it finished before you switched over. The Dashboard/page indicator shows a replication while you're actually looking at that page — e.g. a scheduled off-site run, or the automatic replication right after a backup (if you leave the off-site schedule blank). Sit on the Dashboard and trigger a replicate, or let a scheduled/after-backup one run, and you'll see it light up.

Glad it's working well for you, and thanks, that means a lot! On the off-site progress: that running indicator landed in 2.5.0, and "Replicate now" has been around since 2.4.0, so if you ran it on an earlier build there was simply no indicator yet. Make sure you're on 2.6.0 (current) and you'll see an "off-site replication running" indicator on the domain's page and on the Dashboard while it copies. One caveat: a flash replication is usually near-instant (small repo, and once it's seeded restic copy only ships the new bits), so the indicator can flash by quickly. I'm making it linger a bit longer so fast replications are easier to catch. Awesome to hear you're running it alongside your normal backups!

@manilx Big update is out: 2.5.0 (it bundles everything from the last round into one release). Off-site backups, now a first-class citizen: - Local + off-site: keep your fast local backup and add an off-site replica per domain (Settings > Off-site copy). Works with any restic backend (rest:, s3:, b2:, sftp:) via Settings > Cloud credentials. The local repo stays primary; off-site is best-effort and never fails the local backup. - Its own schedule: leave it blank to replicate after every backup, or set e.g. "weekly Sun 03:00" to back up locally daily but ship off-site weekly. There's a "Replicate now" button too. - Restore/maintain from either: every backup browser and the Integrity & Maintenance card has a Local | Off-site switch. List, restore, download, verify/unlock/prune and delete against whichever copy you pick. Local repo dead or corrupt? Switch to Off-site and restore from there. - Delete is per-source: deleting only removes the copy you're viewing, never both (stated next to the switch). - A running indicator shows which domain is replicating off-site (on its page and the Dashboard). It's an active indicator, not a percentage: restic copy doesn't expose machine-readable progress like backup does. Flash: - Flash restore is now a .zip download, streamed to your browser, ready for the Unraid USB creator. The live /boot is never touched, and because a zip carries no Linux permissions the old "There were N errors" is gone. It shows live download progress. Fixes from your testing: off-site view no longer shows empty for a remote repo; no more "config file already exists" log spam; stateless containers no longer show a phantom appdata folder; saving settings no longer wipes cloud credentials; REST with password-only works (leave username blank). Update to 2.5.0. Thanks again, this whole wave came straight from your feedback.

Great questions, and both are sorted in 2.4.0 (just released). Delete = per source, never both. Deleting a backup only removes the copy you're currently viewing. So deleting a local backup never touches the off-site copy, and vice versa. That's deliberate, exactly for your scenario: if the local repo is corrupt or gone, the off-site copy is still there to restore from. The restore browser now states this right next to the source switch. Restore from local OR off-site. You were right that you need to choose. Every backup browser (Containers, VMs, Flash) and the Integrity & Maintenance card now has a Local | Off-site switch. Flip it and the list, restore, download, verify/unlock/prune and delete all act on that copy. So a dead local repo is no problem: switch to Off-site and restore from there. Your screenshot is still 2.3.0 (no switch yet). Update to 2.4.0 and it's all there. Thanks again, this feedback shaped the release.

Hey @manilx both of these are done in 2.3.0, and they're tied together nicely. Flash restore "1104 errors": found and fixed. The old restore wrote the files out to a folder and then tried to set Linux ownership/permissions on each file on the /mnt/user share, which the share rejects per file. So your data was always fine, those were metadata-only errors, not data loss. The error box just showed restic's final count without the detail. The fix is exactly your P.S.: flash restore is now a direct .zip download. Pick a snapshot and it streams straight to your browser as flash-<id>.zip, ready to drop into the Unraid USB creator as-is, no copying out of a target folder. A zip carries no filesystem permissions, so the errors are gone. (I also made restic's per-item errors show up in the UI now, so nothing fails with just a number again.) Local + off-site at the same time: also done. There's a new "Off-site copy" section in Settings with a second repo per domain. After each successful local backup, BombVault replicates the new snapshot to that repo with restic copy. Your local backup stays primary and runs as before; the off-site copy is best-effort, so an off-site hiccup never fails the local backup. It works with any restic backend (rest:, s3:, b2:, sftp:), using the same Settings > Cloud credentials. REST with password only: leave the username blank and just set the password, that works. If your server ever rejects it you can also put it in the path, e.g. rest:http://:password@server:8000/repo. One more: saving settings used to wipe your stored cloud credentials in some cases, that's fixed too. Update to 2.3.0 and you've got all of it. Thanks again for the detailed testing, it's been driving most of these.

Update 2.2.0 is live, and it closes out everything from your last few posts. Permissions: yes, fully preserved. restic stores each file and folder's mode, owner (uid/gid), timestamps, ACLs and xattrs, and a restore puts them all back. So appdata that depends on specific ownership or permissions comes back exactly as it was, no manual chown afterwards. Unraid notifications (2.1.0): new option under Settings > Notifications. BombVault posts each backup result straight into Unraid's own notification system, so you set up email/Pushover/etc. once in Unraid and BombVault just feeds it, no separate integration needed. Same policy as the other channels (never / on failure / always), and the Test button covers it. It goes over the host SSH connection (the same one used for VM backups), so that needs to be configured under Settings > VM Backup. Remote targets without rclone (2.2.0): you can now point a Backup Path straight at a restic remote repo, for example: rest:http://your-server:8000/repo s3:s3.amazonaws.com/bucket/path b2:bucket:path sftp:user@host:/repo Credentials go in the new Settings > Cloud credentials card (S3 access key / secret / region, and restic REST user / password). They're stored encrypted and handed to restic as the standard env vars it expects. Secrets are write-only, so they're never shown again after saving; leave a field blank to keep the stored one, or clear everything to remove the config. rclone still works if you prefer it, but it's no longer required for these. Grab 2.2.0 and you've got all of it. Thanks again for the steady stream of input, it's been driving a lot of these improvements.

Both work, you don't strictly need a reverse proxy. A Cloudflare Tunnel is fine for client access and means zero open ports. Two things to know: Cloudflare caps uploads at 100 MB (the README already uses 100M, so that lines up), and for federation you still need the .well-known delegation to 443 (section 6 in the README). Voice/video (TURN) is UDP and can't go through a tunnel or proxy, so forward those ports either way. A normal reverse proxy (NPM, what the README documents) is the cleaner option if you want federation plus bigger media. And if you ever use Cloudflare's orange-cloud proxy instead of a tunnel, set the Matrix subdomain to DNS only (grey cloud), the orange proxy breaks non-browser clients and federation.

@manilx this is gold, thank you. Pretty much your whole list went into 2.0.0, just force-update the container to pull it: - The /mnt/user/bombvault share: fixed. BombVault no longer creates that folder on startup, so no more phantom share you can't delete. It's only created when you actually run a backup. - Delete backups you no longer want: done. Every backup now has a Delete button (containers, VMs and flash). - Prune: retention already prunes after each backup, and there's now a manual Prune button per repo under Settings > Integrity & maintenance to reclaim space on demand. - The lock issue (and "Failed to load backups"): there's now an Unlock button under Settings > Integrity & maintenance, and BombVault also clears stale locks automatically before a backup and when listing backups, so you shouldn't have to touch the locks folder by hand anymore. Same-repo operations are serialised now too, so a backup, prune and unlock can't trip over each other. - VMs shutting down without warning: fixed, and this was the big one. The "live" method now never shuts a VM down. Those shutdowns were an auto-fallback I'd added earlier; it's gone. The real cause for the VMs that kept failing was a leftover snapshot overlay (the .bombvault-tmp file you found and deleted) from an interrupted run. BombVault now detects that and commits it back automatically before the backup, so live keeps working without you cleaning anything up. The method dropdown also spells out graceful = shutdown vs live = no downtime now. - File restore: it's a proper collapsible folder tree now, expand/collapse like a file manager. One I couldn't action yet: you mentioned "something is buggy with log files", can you say a bit more about what you saw (which logs, what looked off)? I'll dig in. Thanks again, genuinely. A big chunk of 2.0.0 exists because of your testing.

Hey @manilx , thanks again for all the testing and the clear write-ups, that feedback shaped a whole release. I bundled everything into 2.0.0, just force-update the container in the Docker tab to pull it. Here's what's in there for the things you ran into: - "Failed to load runs": fixed, and good news, it's not a corrupted database. A backup that was still running or got interrupted left a record the run history couldn't read, and that one record broke the whole list. It loads fine again after updating, no reset needed. Interrupted runs also get tidied up on startup now instead of sitting there as "running" forever. - Containers with no data folder: they now show "Config only" instead of a plain "done", so it's clear no data snapshot was made (the container definition is still saved, so it can be recreated). And there's a new per-container Export button that drops a plain <name>.tar.gz + <name>.xml next to your repo, same idea as the Appdata Backup plugin, if you want the config/settings as readable files. - Containers without an appdata folder no longer fail with "all source directories do not exist". - The dashboard now shows which container/VM a run was for, and the error message when one fails, instead of an opaque snapshot id. - Stop other containers during a backup: each container has a field where you can list other containers (like a database) to stop while it's backed up and start again after. Covers the backrest-style use case, over the Docker API, no scripts. - VM live backups, two things. First, cd-rom / read-only disks are skipped during the snapshot now. Second, and this is the big one for your two VMs: if a live snapshot still can't be created, BombVault automatically falls back to a graceful backup instead of erroring out, so the backup always completes. So those two VMs should just back up now (they may quietly fall back to graceful, which means a short shutdown during the backup). If you'd rather keep them truly live, the snapshot is failing because of how one of their disks is set up. Grab "virsh dumpxml VMNAME" from the Unraid terminal and post it, and I'll get that disk classified properly. One more on the earlier "hash mismatch" on the Windows 11 VM: that one points at the host (RAM or the cache pool), not BombVault. BombVault actually caught it and refused to store a corrupt backup. A MemTest86 run is worth it when you get the chance. Thanks again, this was a great batch of feedback.

Hey, thanks a lot for taking the time to test this properly and write it all up. That kind of detailed feedback is exactly what I needed. Most of it is sorted in the latest version, so here's where things stand. The big one you caught: a backup was starting a container that had been stopped beforehand. That was a real bug and it's fixed now. A stopped container gets backed up in place and stays stopped, and a running one gets stopped for a clean backup and started again afterwards. Restore behaves the same way now, it brings the container back in the exact state it was in when you backed it up instead of always starting it. You also said there was no sign of anything happening during a backup or restore. There's now a live progress bar on each container, VM and flash card that fills up as the job runs, for both backup and restore, so you can actually see how far along it is. On the HTTP_ONLY setting: when it's on, the WebUI link still points at https, so for now you have to open http://[ip]:[port] yourself. I've noted that in the template description. For the Windows VM backup that failed without telling you why, I improved the error reporting, so instead of restic's generic "please open an issue" line you now get the real reason in the UI. About that specific failure: if the message is something like "detected data corruption while saving blob ... hash mismatch", that one is worth a closer look. restic checks every chunk it writes, and that error means the data changed in memory between being read and being written. If you run the backup a few times and it fails on a different block each time, while the disk file itself reads back identical when the VM is off, that points at the RAM rather than at the tool or the disk. The good news is restic refuses to store a corrupt backup, so nothing bad got saved. I'd run MemTest86 (it's in the Unraid boot menu), and if you're using an XMP or EXPO memory profile, try turning it off and testing again. That fixes this kind of thing more often than you'd expect. On backing up other folders: right now it automatically grabs the container's appdata. Choosing which of the container's other mapped folders to include or exclude, plus adding your own paths, is the next feature I'm working on. The Backup Hooks field isn't for that, by the way, it just runs a command around the backup (like dumping a database into appdata so it gets picked up), it doesn't add folders. I made that description clearer too. Good to hear the flash backup and the stopped-VM snapshot both worked for you. And yeah, it's still got room to grow, no argument there. Thanks again for pushing on it, it genuinely makes the thing better. Let me know how the next version treats you.

Thanks for trying it, and for the blunt feedback! 🙏 The "error 400 on some VMs" was a real bug: VM names with a space (e.g. Windows 11) got rejected by a too-strict name check. Fixed in v1.3.4, spaced names back up fine now. The mystery "datastore" is just the restic backup repo, it defaults to /mnt/user/bombvault/ (changeable in Settings → Backup paths). Fair point that it wasn't mentioned anywhere, now spelled out in the description + README. No pressure to switch from your scripts, but if you fancy another go, grab v1.3.4/:latest and it should just work. 👍

ShipLogRead the log before you set sail. What is this?ShipLog is a read-only update advisor that lives right inside Unraid's native Docker tab. Unraid already tells you that an update is available and lets you apply it — ShipLog tells you what actually changes and how risky it is first. Next to each container it adds a small changelog bubble: the version jump, a deterministic risk badge, the release notes, and a DEPRECATED badge when the upstream project is archived. It is a plugin (not a container): a tiny daemon on the host plus the bubble in the Docker tab. It never pulls, recreates, or stops anything — the Docker socket is read-only. Updating stays Unraid's own job. HighlightsChangelog where you need it — a per-container bubble in the native Docker tab, no separate dashboard to open What changes, not just “an update exists” — the release notes between your running image and the newest one Deterministic risk badge — patch / minor / major / digest, computed from the version jump (no guessing) Remembers the running version — even a rolling :latest image shows a real 1.7 → 1.8 jump once ShipLog has seen one update under its watch DEPRECATED badge when the upstream repository is archived (end-of-life) Read-only by construction — the Docker socket is mounted read-only; ShipLog cannot start, stop, recreate or pull anything Optional AI summaries via a local Ollama — a short, plain-language “what changed” per update (off by default) Optional Matrix notifications when a new update is first seen (off by default) Follows your Unraid light/dark theme and language (English + German, English fallback) Runs as a lightweight host daemon — no extra container RequirementsUnraid 6.10+ Outbound HTTPS to image registries and GitHub (to fetch changelogs). A free GitHub token (no scopes) in the settings raises the anonymous API limit — useful if you watch many GitHub-sourced images Optional: a reachable Ollama instance for AI summaries, and/or a Matrix account for notifications Install / updateInstall from Community Applications (search for ShipLog), or add the plugin by URL under Plugins → Install Plugin: https://raw.githubusercontent.com/junkerderprovinz/shiplog/main/plugin/shiplog.plg Open the Docker tab to see the bubble, or Settings → ShipLog for the options (poll interval, GitHub token, Ollama, Matrix). If you ever tested an early date-versioned build, remove the plugin and reinstall it once from the URL above. Posting a bug reportPlease post: Unraid version (Settings → System Information) ShipLog version (Plugins page) — currently v1.0.4 Daemon state and log: /usr/local/emhttp/plugins/shiplog/scripts/rc.shiplog status and tail -200 /var/log/shiplog.log Browser + OS (the bubble is rendered in your browser) Whether you set a GitHub token, Ollama, or Matrix — and, for a specific container, its image reference (e.g. ghcr.io/owner/app:latest) GitHub issues with the same info are equally welcome: github.com/junkerderprovinz/shiplog/issues CreditsBuilt in Go (engine) + a thin Unraid plugin for the Docker-tab bubble. Changelogs come from each image's org.opencontainers.image.source label and GitHub releases; optional summaries run on your own Ollama. If ShipLog saves you from a surprise update, you can buy me a coffee. Self-hosted, MIT-licensed, read-only by design — it advises, you decide.

BombVault – the only backup & recovery tool you need for UnraidYour Unraid data, sealed in a vault — armed with a fuse. What is this?BombVault is a single-binary, Unraid-native web app for one-click backup and full disaster recovery of your Docker containers, KVM/libvirt VMs and the Unraid flash — all powered by restic. The restore is the star: a backed-up container automatically reappears in the Docker tab and a VM in the VM Manager, exactly as before — no manual reinstall, no reconfiguration, even after you deleted it. Everything (backup paths, encryption on/off, schedule, retention) is configured in the modern dark web UI; nothing to hand-edit. HighlightsThree domains, one app — Docker containers (appdata + definition), KVM/libvirt VMs (disks + XML + UEFI NVRAM), and the whole Unraid flash (/boot) Restore that re-installs for you — containers are replayed against the Docker API and VMs re-defined in the VM Manager, so they come back exactly as they were VM backup with no libvirt mount — BombVault runs virsh on the host over SSH (qemu+ssh://), so it can never disturb your VM Manager; graceful-shutdown or live (guest-agent) snapshots Off-site repos — rclone (Backblaze B2, S3, Google Drive, …) plus SMB/NFS; the rclone config is stored encrypted Retention — keep-last / daily / weekly / monthly, auto-pruned after each backup File-level restore — browse a container snapshot and restore a single file back to its original location Integrity checks (restic check) and pre/post-backup hooks (e.g. mysqldump for an app-consistent backup) Incremental, deduplicated and always encrypted (encryption is optional); pre-flight IP/port conflict check before a restore Per-domain scheduling, HTTPS out of the box, optional password, English + German UI Multi-arch — amd64 + arm64. Image: ghcr.io/junkerderprovinz/bombvault:latest RequirementsUnraid 6.12+ The template mounts the Docker socket, your storage root (/mnt) and the flash (/boot) automatically — backup sources and destinations both live under /mnt; pick the exact subpaths in the WebUI A required APP_KEY — generate with openssl rand -hex 32. It derives the restic password, so keep it safe: losing it makes encrypted backups unrecoverable VM backup is opt-in — it talks to libvirt over SSH, so authorize BombVault's key on the host once (Settings → VM Backup over SSH shows a ready-to-paste command + a Test button). No libvirt mount needed Trusted LAN only: BombVault holds root-equivalent control of your host (via docker.sock and the /mnt mount). Run it on a non-exposed network; optional password protection is in Settings (off by default) Companion: BombVault WidgetBombVault Widget is a small, optional Unraid plugin (no container) that puts BombVault's activity log on the Unraid 7 dashboard as a real, native tile — every backup, restore, verify, prune, off-site replication and drill as it happens, plus the next scheduled run, in the same dark terminal-style log. Read-only by construction: it talks to BombVault through a same-origin proxy with a widget token that never reaches the browser. Install it from Community Applications (search BombVault Widget) or one-click from BombVault → Settings → System → Dashboard widget. Requires BombVault ≥ 6.9.0. Post widget questions in this thread too — it has no separate support thread. Posting a bug reportPlease post: Unraid version (Settings → System Information) Image tag (latest or a pinned vX.Y.Z) Output of docker logs --tail 200 BombVault Which domain (containers / VMs / flash) and what you were doing (backup / restore) For VM issues: the result of Settings → VM Backup over SSH → Test connection Browser + OS you're using GitHub issues with the same info are also welcome: github.com/junkerderprovinz/bombvault/issues CreditsThe core idea — one-click backup and automatic re-install of Docker containers — comes from VolumeVault by @Darkdragon14 (Apache-2.0). BombVault is an independent Go + restic rewrite that extends the concept to VMs and the Unraid flash. Built on restic (engine) and rclone (off-site). If BombVault saves your bacon, you can buy me a coffee. Self-hosted, MIT-licensed. BombVault has root-equivalent control of your host — you run it, you own your data and the responsibility.

FireSquireReads the beacon before your reboot catches fire. What is this?A reboot is never 100% guaranteed — but a large class of "it didn't come back right" is predictable from the current state of the running system. FireSquire inspects that state before you reboot and gives you one honest verdict: GO / CAUTION / NO-GO, with the exact findings. It is advisory only: it reads the host and reports — it never stops, mounts, unmounts or changes anything (acting on the host is exactly what tends to cause reboot trouble in the first place). The plugin adds a FireSquire button next to Reboot on the Main tab. Click, read the verdict, then reboot with confidence. HighlightsCritical (NO-GO) — array started & every device assignment OK (no disabled/invalid/missing disk); no parity/sync/rebuild/clear or mover running; no container mounting a host runtime dir (the bind class that can take libvirt/docker down on reboot); no stuck docker.img/libvirt.img loop; flash writable Caution — crashes since boot in the syslog, disk/IO errors (failing disk or loose cable), low free space, running VMs, a stopped core service, missing container bind sources, and SMART health (status + attributes: reallocated/pending/uncorrectable sectors, UDMA CRC, temperature) Advisory only — reads and reports, never changes the host Follows your Unraid theme & language — light/dark, all 26 supported languages (English fallback) No dependencies — a small Bash engine querying the tools Unraid already ships; no daemon, nothing to configure Honest limit: it is an early warning, not an oracle — genuine hardware, BIOS or timing failures during boot cannot be seen from a running system. What it covers reliably is the state-detectable class. RequirementsUnraid 6.10+ Nothing else — install from the Apps tab (or the .plg URL) and the button appears on the Main tab Posting a bug reportPlease post: Unraid version (Settings → System Information) FireSquire version (Plugins tab) The verdict + the lines shown, or the console output of bash /usr/local/emhttp/plugins/firesquire/firesquire-check.sh Browser + OS (for any WebGUI/display issue) GitHub issues with the same info are welcome: github.com/junkerderprovinz/firesquire/issues CreditsBorn from the classic homelab lesson that a green build is not a booting server. The engine stands on the tools Unraid already ships (mdcmd, smartctl, losetup, docker). If FireSquire saves you a bad reboot, you can buy me a coffee. Self-hosted, AGPL-3.0-licensed — you run it, you own your data and the responsibility.

Thanks! Yes, this is the full JDownloader 2, just running its native GUI in your browser via KasmVNC, so all of JD's normal captcha handling works exactly like on the desktop: When a filehost shows a captcha, JDownloader pops its captcha dialog right in the web GUI — you solve it there (click/type), same as desktop JD. All of JD's built-in options are available under Settings → Captcha: JAntiCaptcha (built-in OCR for simple image captchas), the interactive browser solver for reCAPTCHA/hCaptcha, and external solver services (9kw.eu, etc.). You can also link the container to MyJDownloader to get captchas forwarded to your phone/browser. Nothing is stripped or changed in the container, it's stock JDownloader 2, so its captcha features behave identically.

JDownloader — Selkies and Dark Mode edition for UnraidGrab it. All of it. In the dark. What is this?JDownloader 2, the full-featured download manager, running as one Unraid container and streamed to your browser via Selkies — no native install, no SSH. The entire GUI (download list, link grabber and the Advanced Settings table) is rendered in a clean, sleek monochrome IBM Carbon (#161616) dark theme, with light, readable progress bars and a green speed graph. Over HTTPS you also get full two-way browser clipboard — copy a link on your PC and paste it straight into JDownloader. It auto-installs and themes itself on first start and is configured entirely from the Unraid template. HighlightsComplete, sleek dark UI — monochrome IBM Carbon #161616 across the whole interface (download list, link grabber and settings), not just the menu bar; the sleek dark JDownloader you won't find elsewhere (one variable flips it to a matching light theme) Full clipboard support — over HTTPS the browser clipboard works both ways: copy a link on your PC and paste straight into JDownloader, and copy text back out Turnkey & self-healing — auto-installs JDownloader, auto-confirms its first-run prompts, and the theme self-heals after JD's own updates Update-safe — all config, links and session state live in /config; even hidden columns and column layout survive a restart Selkies web desktop — hardware-accelerated rendering, native file upload/download, high-DPI My.JDownloader-ready — pair it once and manage downloads remotely Optional WebUI login (CUSTOM_USER / PASSWORD), or leave it open on your LAN One container, multi-arch (amd64 + arm64), built on LinuxServer's baseimage-selkies Image: ghcr.io/junkerderprovinz/jdownloader:latest RequirementsUnraid 6.10+ Open the WebUI over HTTPS (port 3001) for the seamless browser clipboard — accept the self-signed cert once First start: JDownloader installs itself, so the WebUI stays black for a few minutes — wait for the JDOWNLOADER IS READY banner in the container log before opening it, and don't restart during the install Posting a bug reportPlease post: Unraid version (Settings → System Information) Image tag (latest or a pinned vX.Y.Z) Output of docker logs --tail 200 JDownloader Browser + OS you're using Whether you changed JD_THEME, the WebUI ports, CUSTOM_USER/PASSWORD, or the /config / /downloads mounts GitHub issues with the same info are also welcome: github.com/junkerderprovinz/jdownloader/issues CreditsBuilt on LinuxServer's baseimage-selkies and Selkies. JDownloader 2 is by AppWork. The dark theme is our own IBM Carbon palette, applied through JDownloader's native colour config on stock FlatLaf — see the repo for details. If this saved you a setup evening, you can buy me a coffee. Self-hosted, MIT-licensed — you run it, you own your data and the responsibility.

Hey I submitted my repo featherdrop but it shows the repository/maintainer name ‚featherdrop'. Please rename it to ‚junkerderprovinz' so it matches my other apps (Krusader etc.), or remove the entry so I can re-add it with the correct name. GitHub: https://github.com/junkerderprovinz/featherdrop Thanks!

featherdrop — a sleek, modern file sharer for UnraidDrop a file, get a link — encrypted, self-destructing, no accounts. What is this?A clean, login-free, self-hosted file sharer. Open the page, drop a file, set an expiry (plus an optional password or download limit), and share a short link or QR code. Files are encrypted at rest, uploads are resumable, and metadata is a single SQLite file — no accounts, no separate database, no tracking. Built with Next.js + Mantine, it runs as one small container and is configured entirely from the Unraid template — no SSH or config-file editing. HighlightsEncrypted at rest with age — the original filename and type are encrypted inside the file, so a stolen disk or backup reveals neither contents nor names Optional password shares are end-to-end; set a MASTER_KEY for short links Self-destructing — expiry from 1 hour to 30 days (or never), plus optional burn-after-N-downloads Inline image/PDF preview, a savable QR code, and clean link previews that never leak the file's name 26 UI languages (right-to-left for Arabic & Hebrew), light/dark, picked from the browser Custom branding — app name, logo and accent colour via env vars One container — resumable uploads (tus), a single SQLite file, separate data/config volumes Private by design — no accounts, no telemetry, no third-party calls at runtime Multi-arch — amd64 + arm64 Image: ghcr.io/junkerderprovinz/featherdrop:latest RequirementsUnraid 6.10+ A reverse proxy with HTTPS is recommended — set BASE_URL to your public URL so share links are correct (and so a link's decryption key in the URL fragment stays private in transit) Allow large uploads in your proxy (e.g. client_max_body_size 0 and generous timeouts) for big files Posting a bug reportPlease post: Unraid version (Settings → System Information) Image tag (latest or a pinned vX.Y.Z) Output of docker logs --tail 200 featherdrop Browser + OS you're using Whether you changed BASE_URL, ENCRYPT_UPLOADS, MASTER_KEY, DEFAULT_EXPIRY, the branding vars, or the /data / /config mounts GitHub issues with the same info are also welcome: github.com/junkerderprovinz/featherdrop/issues CreditsA much simpler take inspired by Pingvin Share. Built on age (encryption), tus (resumable uploads), Next.js, Mantine and better-sqlite3. If featherdrop saves you a trip to a third-party host, you can buy me a coffee. Self-hosted, MIT-licensed — you run it, you own your data and the responsibility.

Language bug is fixed now.

Already noticed it. I'll fix it during the next week or two.