junkerderprovinz

Hey @JesterEE thanks for putting both images through their paces and writing it up. That was useful feedback, and all three points were fair. They are fixed in v2.5.0, which is out now. Quitting the app You were right that ich777's behaviour is the better one. The session now watches Krusader: close it in the browser and a fresh one starts, so refreshing the tab brings you straight back without restarting the container. Diff tool Kompare is bundled and wired into File > Compare by Content. RAM This turned out better than I expected. The heavy part is not the encoder but the X server: it reserves its whole framebuffer up front, about 4 bytes per pixel, and the base image sizes that screen at 15360x8640. That is 530 MB for a resolution nobody uses, and it also explains why your 3070 barely moved the number. GPU rendering changes where frames are encoded, not that allocation. The screen size is now a template setting rather than something I decided for you: a dropdown of presets with the memory cost written on each entry, plus a free field if you want a size that is not in the list. Nothing is capped unless you pick a cap. Measured here on a live container: full 15360x8640: ~700 MiB 3840x2160: ~295 MiB 3440x1440: ~210 MiB 1920x1080: ~200 MiB At your 3440x1274 the ultrawide preset should put you near 210 MiB, which is well under the bar you named. I would be curious whether your numbers match mine. One small ask: reports like this are very welcome as issues on GitHub (https://github.com/junkerderprovinz/krusader/issues), where they are easier for me to track and to link a fix to. The forum works too, though, and I would much rather read it here than not at all.

StrawDroid: a real Android emulator for UnraidA phone you can break. What is this?A straw droid is a practice dummy shaped like an Android phone: built like the real thing so somebody can strike at it without anybody getting hurt. This container runs the real Android emulator, the same AVD Android Studio starts, headless on a Selkies desktop. The screen arrives in your browser over WebRTC and is encoded on the box's own GPU, and adb reaches it over the network, so Android Studio deploys and debugs on it exactly like a phone on a cable. It is deliberately not Android-in-a-container. ReDroid and Waydroid run the Android userspace on the host kernel: no battery, no motion sensor, no power HAL. Doze therefore never fires and the limits on background work never apply, so a test rig built on one is green because it never asks the question. A real AVD asks, and it answers on demand. HighlightsAndroid 16, API 36, google_apis, x86_64. The newest level on purpose: it is the strictest about background work, and it carries Play services and a real SAF folder picker adb over the network: adb connect <ip>:5555 and Android Studio lists it as an ordinary device Doze on demand, which is the whole point of a real AVD: adb shell dumpsys deviceidle force-idle A share that reaches the phone: anything dropped into /share turns up on the device under Download/share, so a build can be installed by tapping it, without a terminal WebRTC, not VNC: judging how an app feels is judging its scrolling and its transitions, which is exactly the part a framebuffer diff smears The device arrives set up: wallpaper, dark mode, an empty home screen and monochrome icons everywhere, done once on the first boot and never written again, so anything you change afterwards is yours Persistent by design: /config holds the device itself, including installed apps and granted permissions, so a restart is not a factory reset A phone in full: a SIM that takes calls and SMS, front and back camera, sound in the browser tab, and every sensor the image offers, heart rate and wrist tilt among them Tools for testing on board: Shizuku, started again after every boot, and PCAPdroid. ROOT=true gives apps root when a test needs it sk in the terminal: seed contacts, photos and music, switch the language, save the whole device and get back to it in seconds, record which hosts an app talks to, take screenshots and screen recordings Nothing lost on stop: Android writes its files to disk before the emulator ends Image: ghcr.io/junkerderprovinz/strawdroid:latest, and Android 14 as latest-api34 RequirementsUnraid 6.10+ /dev/kvm on the host, passed in via Extra Parameters (--device=/dev/kvm). On bare metal it is simply there; inside a VM it needs nested virtualisation. Without it the emulator does not start, and the container log says so in as many words Memory: an emulator is a virtual machine and holds its memory whether anybody is testing or not. Measured idle, with no app installed, about 6 GB. The template caps it at 8 GB and four cores For Flutter apps, vm.overcommit_memory=1 on the host. Without it the emulator crashes as soon as one draws. Add sysctl vm.overcommit_memory=1 to /boot/config/go to keep it after a reboot; the container log warns while it is missing amd64 only. The system image is x86_64, so there is nothing for an arm64 build to run It is deliberately not set to restart on its own. Start it when it is needed and stop it after 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 StrawDroid Whether /dev/kvm is present on the host: ls -l /dev/kvm Whether you changed EMULATOR_GPU, EMULATOR_DEVICE, EMULATOR_RAM or the /config mount GitHub issues with the same information are just as welcome: github.com/junkerderprovinz/strawdroid/issues CreditsBuilt on the Android emulator and Google's system images, on LinuxServer's Selkies base image. The device ships with Lawnchair (Apache-2.0) and the Arcticons icon pack (GPL-3.0) by Donnnno, and installs Shizuku (Apache-2.0) and PCAPdroid (GPL-3.0) for testing, all unmodified. budtmo/docker-android did this first and is well kept; this one differs in putting the emulator on a hardware-encoded desktop rather than behind noVNC. If StrawDroid saves you a spare phone, you can buy me a coffee. Self-hosted, AGPL-3.0 licensed. You run it, you own your data and the responsibility.

@luke.smith.name Glad that got you further, and the edit answers it: the password is in the recovery kit. Worth adding, because it is the part that catches people: for a repository you RECEIVED, the password comes from the sending instance's APP_KEY, not the receiving box's. Deriving it from the wrong key looks exactly like a corrupt repository. You do not need the kit either. It is computed, not stored: printf 'bombvault:restic-repo' | openssl dgst -sha256 -mac HMAC -macopt hexkey:$APP_KEY -r | cut -d' ' -f1 On "repository contains errors": try restic repair index first, then restic repair snapshots if snapshots stay unreadable. BombVault only reads a received repo, so it will not repair it for you. All of this is in v8.5.0: the Receiver page now says it when a check fails, the encryption card names the kit, and the derivation is in the docs. Bugs and feature requests are best on GitHub, that way I can link them to the fix and come back to you when it ships: https://github.com/junkerderprovinz/bombvault/issues

Hey @luke.smith.name, thanks for taking the time to write all that up. It was genuinely useful, especially that you separated what went wrong from what you thought was causing it. All six points are in v8.4.0: https://github.com/junkerderprovinz/bombvault/releases/tag/v8.4.0 1. Receiver location. A path under /mnt is a host path, and BombVault runs in a container where the host's /mnt sits somewhere else. The error blamed the APP_KEY, which sent you off in the wrong direction, and I'm sorry that cost you time. It now names the relative path to use instead. One more thing worth knowing: the Sending APP_KEY is the sending box's key, not the receiver's. That one catches almost everybody. 2. Tamper test. A 404 from the far side was being read as a pass. It now says "inconclusive" rather than claiming a protection nobody actually demonstrated. 3. The restic container. You were right about the symptom. The docker run itself is fine, I checked it against a real rest-server, but a container Unraid did not create from a template has no Edit form behind it, so falling back to a CA container was a perfectly sensible move. The wizard now also gives you an "Unraid template (XML)" tab: save it under /boot/config/plugins/dockerMan/templates-user/, then Docker > Add Container. Every field stays editable and --append-only stays where you can see it. 4. Docs. There's now a worked two-box example with real values, five steps, and a table for what protected / NOT protected / inconclusive each mean. It calls out both traps from point 1. Translated into all 25 languages. 5. "Immutable baked in." Half done, and I'd rather say so than pretend otherwise. The recipe path is fixed above, and the protection card now marks an off-site copy that isn't append-only as an amber gap instead of a grey dash. What's still missing is BombVault deploying the receiving container itself. That touches the receiver model, which is new, so I'd rather give it its own round than rush it in here. 6. Sources / jobs / repositories. This one deserves a proper discussion, so it has its own issue: https://github.com/junkerderprovinz/bombvault/issues/190 Interesting thing I found while writing it up: all three axes already exist in the data model. What's missing is a name for a combination and a screen that shows them. I'd really like your take there, especially on what you went looking for and didn't find. And a small favour, if you don't mind: for bugs and feature requests, GitHub issues are the best place. https://github.com/junkerderprovinz/bombvault/issues It just means I can link them to the commit that fixes them and come back to you when it ships, which is harder to do from a thread. Questions, ideas and general chat are always welcome here though, and thanks again for the detail.

Hey @Retrolamer1337, that one is on me. I said "in Settings" and left it at that, but the Settings page has seven tabs, so it was not much of a direction. It is on the Schedules tab, and it is the last card on it, below the five per-domain schedules. Adding #schedules to your Settings URL jumps straight to that tab. The card is titled "Backup Everything" and it has been in every release since 8.0.0, so 8.3.0 has it. If it is still not there once you are on that tab, say so and I will dig further.

Hi @Retrolamer1337, sorry for the slow reply, and thanks for the request. It landed while v8.0.0 was being built, and it turned out to be one of the things that release adds. 8.0.0 went out today. You were right that per-container hooks were the only thing on offer. v8.0.0 adds Backup Everything: one pass that runs containers, then VMs, then flash, then folders, then BombVault's own config, with its own pre-hook and post-hook. Those run on the host shell, not inside a container, so a curl is exactly what they are for. You will find it in Settings, and it takes its own schedule. The post-hook fires once, after all five have been attempted, and it fires whether they succeeded or not. That is deliberate: a hook that only runs on success is no use as a dead man's switch, because the case you most want to hear about is the one where something went wrong. The single exception is a pass that could not even be recorded as started, where firing would be a false "done", so silence still means something. Where it does not match your list: you asked for five hooks, one after each group. What ships is one hook after the whole pass. If a single ping when everything is done is the goal, that is covered exactly. If you need a different endpoint after the containers than after the VMs, that is not there yet. Say so and I will look at it. One caveat worth knowing: the per-container hooks you have today run inside the container, these run on the host shell. Different environment, so a command that works in one will not necessarily work in the other.

TL;DR:your OpenCloud share is cache->array, so it goes through Unraid's FUSE layer, and there is also a real crash-on-timeout bug on the OpenCloud side that a burst of small-file uploads triggers. That combo explains both the fatal crashes and the GUI hang (php-fpm workers backing up on blocked I/O). Cheapest next step: run opencloud storage-users uploads sessions --processing inside the container to check for a stale-session backlog like opencloud-eu/opencloud#3283 hit. If that is not it, moving the data volume off the array (or at least NATS_NATS_STORE_DIR) onto a direct pool path is the storage-side fix. Detail below. Hi @BlindOwl, sorry you have been fighting this for two weeks. I run OpenCloud on Unraid myself and went down the same rabbit hole from the OpenCloud side, so hopefully some of this helps. I put the OpenCloud-specific details in the GitHub issue that is already cross-linked here (opencloud-eu/opencloud#3271), so I will keep the deep stuff there and stick to the Unraid side in this post. First off, your Aug 7 isolated test is the most useful thing in this thread. Only the OpenCloud stack running, everything else stopped, and the Work folder still killed the box within seconds. That takes contention with your other containers off the table. It is OpenCloud's own I/O pattern on its own, and 2000+ small files is exactly the shape of workload that does it. I also went through your syslog and the docker log you attached, and the timing lines up exactly: a burst of uploads starts, and about 6 seconds later OpenCloud's own postprocessing service hits a fatal error trying to publish to its internal message bus and the whole process exits. To your three questions. Fair warning up front: this is my reasoning from how Unraid is put together and from the logs you posted, not something I confirmed by reading emhttpd's source, so treat it as a well-fitting theory rather than gospel. 1. Why the web UI eventually goes unresponsiveThe webGUI is nginx plus php-fpm, and a lot of its pages stat /mnt for the dashboard graphs and various status pages. Your syslog shows exactly this: repeated "upstream timed out... auth-request.php" errors every 20 to 40 seconds, then "server reached max_children setting (50)" a couple minutes in. Once the pool is maxed out, every request gets a 504, including the /sub/session,var,notify subrequest that drives the live-updating parts of the GUI. That matches your symptoms very neatly too: the Processor graph reads /proc and touches no disk, so it kept working, while System, Interface and the VMs tab all stat /mnt and died first. 2. Why diagnostics and powerdown -r do nothingSame root cause, I believe. Both of them walk your shares and disks, and both wait on emhttpd. If php-fpm and whatever it is calling into are backed up on I/O, emhttpd gets stuck behind the same queue. SSH stays alive because Unraid's root filesystem is a RAM disk, so a shell works fine as long as you do not touch anything under /mnt. 3. Whether a graceful reboot is possible in that stateProbably not, once it has gone that far, though I want to be upfront that I could not fully confirm the mechanism here. My first instinct was that something ends up stuck in uninterruptible D state in the kernel, which nothing in userspace can kill, and that would also explain your own observation that opencloud processes were still in htop after the stack was stopped. I looked for the kernel's own hung-task warnings in your syslog to back that up and did not find any, and the diagnostics you managed to grab were from after the reboot rather than during the hang, so I cannot actually confirm D state versus plain heavy queueing at the php-fpm/application layer. Either way the practical answer is the same: once php-fpm and the GUI are backed up this badly, catching it early is the real win, not fighting a clean shutdown after the fact. Which brings me to MowMdown's IOWait tip, which is the right next step and I would build on it a bit. Have top open before you kick off the Work sync and watch the wa number. If it climbs and stays high while the GUI degrades, that confirms I/O saturation directly on your hardware. While you are in htop, the state column is worth watching too, since an opencloud process flipping to D would settle the question above either way. One bit of context that is likely relevant. Your appdata and domains shares are exclusive, so they bypass shfs entirely through the symlink Unraid sets up for that. But your OpenCloud share is cache to array, and a cache to array share can never be exclusive (that needs primary set to a single pool and secondary set to none). So OpenCloud's data volume, which holds its embedded NATS message bus, its KV buckets, the file tree metadata and the upload staging area, goes through FUSE every time, and once the mover has run, across the parity-protected array as well. That is not a great home for thousands of small synchronous writes landing at once. There is a genuine bug on the OpenCloud side making it worse too: their postprocessing service currently treats any transient failure publishing an event to the internal NATS bus as fatal to the whole server process, with no retry, which is exactly the "fatal error - exiting" line in your docker log. A burst of small-file uploads is precisely what sets that off. That plus the mitigation options (short version: get that data volume off the array path) are written up in #3271, I did not want to dump all of it in here. Last thing, Traefik stopping outright is the one piece I cannot explain cleanly. If its own logging or healthcheck touched a blocked path, or the docker daemon got sluggish under host-level I/O pressure, that would do it, but I am not going to pretend I know which. Hope some of that is useful. Happy to compare notes, I am on the same stack.

HandBrakeNVIDIA, Intel and AMD hardware encoding, an automated watch-folder converter, Selkies — the most complete HandBrake container for Unraid. What is this?A modern, plug-and-play Docker image for HandBrake, the open-source video transcoder. You get the full transcoder GUI in your browser via Selkies, dark by default using HandBrake's own native GTK dark mode, plus a watch-folder daemon that transcodes anything dropped into /watch without opening the UI at all. Hardware encoding is supported on all three major GPU vendors — NVIDIA NVENC, Intel Quick Sync and AMD VCE — which no other HandBrake container on Unraid covers. Built on Ubuntu (via linuxserver/baseimage-selkies), so NVIDIA's proprietary glibc libraries load without issue, something the Alpine-based community image has never been able to ship. Everything is configurable from the Unraid template, no SSH or config-file editing required. HighlightsGPU-accelerated hardware encoding on every major vendor — NVIDIA NVENC, Intel Quick Sync (QSV) and AMD VCE — the only HandBrake container on Unraid that covers all three Selkies instead of noVNC — a hybrid VNC/H.264 web desktop with a real bidirectional browser clipboard, native file upload/download, high-DPI ready, no separate VNC client Dark by default — HandBrake's own native GTK dark mode, not a repaint; switch to light with one variable Automated watch-folder conversion — drop a file into /watch, get a transcode in /output; atomic output so a media scanner never indexes a half-written file 5 conversion hooks — before/after every job, end of a scan pass, per-file custom arguments, and a hook for conversions started manually in the GUI Staging directory — keep in-progress transcodes off the array while they run, on a cache pool or elsewhere Web file manager, a web terminal (Ctrl+Alt+T) and desktop notifications, all built into the browser session Shared-watch-folder locking — run two containers against one watch folder to convert twice as many files at once, safely Multi-arch — amd64 + arm64, both gated by a CI smoke test that really transcodes a clip before anything is published Image: ghcr.io/junkerderprovinz/handbrake:latest RequirementsUnraid 6.10+ For NVIDIA hardware encoding: the Nvidia-Driver plugin (ich777) and --runtime=nvidia in Extra Parameters For Intel or AMD hardware encoding: --device=/dev/dri in Extra Parameters, and the host's open-source i915/xe (Intel) or amdgpu (AMD) kernel driver A reverse proxy is optional — the container already serves HTTPS itself on port 3001 with a self-signed certificate 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 handbrake Your GPU_VENDOR setting, and if it's not none, the output of docker exec handbrake cat /config/handbrake-gpu.log Whether you changed any AUTOMATED_CONVERSION* variable, or the /watch / /output / /storage mounts GitHub issues with the same info are also welcome: github.com/junkerderprovinz/handbrake/issues. Got AMD hardware, or Intel hardware older than a Gen12 iGPU? A hardware report helps close the last unverified gaps. CreditsPackages HandBrake (GPL-2.0, artwork CC BY-SA 4.0) on top of linuxserver/docker-baseimage-selkies and the Selkies web-desktop project. If this saves you a trip to a proprietary transcoding tool, you can buy me a coffee. Self-hosted, AGPL-3.0-licensed wrapper around GPL-2.0 HandBrake — you run it, you own your data and the responsibility.

Hey @HHUBS, thanks for testing, and sorry for the trouble! A second-instance failure like that is worth tracking properly rather than sorting out here in the thread. Could you open an issue at https://github.com/junkerderprovinz/unraid-apps/issues with the log you posted above? That way it won't get lost and I can look into it properly.

Hi @HHUBS , thanks for the report and the screenshot, that's genuinely useful. This is a bug in the template, not something you did wrong: the "Database" field under Advanced View had a default path, and mounting a fresh empty folder there hides the database this image already ships built in, which then can't start. It's an unfixed upstream issue: euro-office/documentserver#299. Fix for your existing container: open its Edit page, switch on Advanced View, clear the "Database" field completely, then Apply. It should come up clean within a minute using the bundled database. I've just fixed the template so new installs leave that field blank by default, and corrected two other mount paths that were silently pointing nowhere useful while I was in there.

Two separate things here: **Test connection failing:** your config has `type = r2` — that's Cloudflare R2's rclone backend, not Backblaze B2's. B2 uses `type = b2` with the exact same `account`/`key` fields you already have (that `K005...` key is B2's own format). Change `type` to `b2`, save, test again. **Real bug found:** "Test connection" was hiding the actual reason behind a generic "not reachable" no matter the cause — fixed in **v7.8.2**, out now. Pull the new image and it'll show the real error, so this kind of thing is self-diagnosable going forward. Bug reports and feature requests are always best on GitHub, I catch those fastest there: https://github.com/junkerderprovinz/bombvault/issues 🙂

Hi @roachman, thanks for the report, real bug on your end. Off-site credentials: the rclone/S3 cards were wrongly hidden behind Advanced mode in Settings, that's why only the Recovery page worked. Fixed for the next release. For now: enable Advanced mode (top right of Settings) and they'll show up directly on the Off-site tab, no need to go via Recovery. VM backup failing: separate from the above, most likely cause is the SSH connection to your Unraid host (VM backup needs that, container backup doesn't). Check Settings → System → SSH status, and post the exact error if it's still failing. Bug reports and feature requests are always best on GitHub, I catch those fastest there: https://github.com/junkerderprovinz/bombvault/issues 🙂

Hi @stiernacken Good news: I just added a one-click toggle for exactly this in v1.2.0. Quick clarification first: OpenCloud already has search, it matches file/folder names and metadata out of the box. Apache Tika isn't a second search engine, it's a text-extractor the search service uses to read the text inside documents, which turns "search by name" into "search inside PDFs/Office files" too. (That `TIKA=:tika.yml` bit is from OpenCloud's official docker-compose deployment and doesn't apply to this Unraid container.) To enable it: 1) Install a Tika container from Community Applications (search "Tika"), image `apache/tika`, port `9998` (a `-full` tag also OCRs scanned images). Note its address, e.g. http://TIKA_IP:9998 2) Update the OpenCloud container to v1.2.0, then in its template set "Full-text search (Tika)" = true and "Tika server URL" = that address, and Apply. That's it, the wrapper wires up the rest. Heads-up: only files uploaded or changed after this get their contents indexed; existing files aren't re-indexed automatically, so re-upload or edit a file to test. README: https://github.com/junkerderprovinz/opencloud#full-text-search-apache-tika-optional Docs: https://docs.opencloud.eu/docs/dev/server/Services/search/Search-info/ For bug reports or feature requests, GitHub is the best spot, I see those fastest there: https://github.com/junkerderprovinz/opencloud/issues 🙂 And thanks again, your question is exactly what turned into the v1.2.0 toggle! Shout if it doesn't come up, happy to help debug.

v2.4.0 is out. Two things in here matter to everyone, and one is opt-in. Everyone gets a long-overdue Element updateThe build workflow pinned Element Web and the admin UI in its own environment and passed those values as build arguments, which silently overrode the Dockerfile. The published image had been shipping Element Web 1.11.92 while the Dockerfile advertised 1.12.23, and the dependency bot had been dutifully opening update PRs against values that never reached the built image. Versions now live in one place, so this release carries the Element jump that had been stuck. In the same pass the admin UI moved from Synapse-Admin, whose last release was in March, to Ketesa — the maintained continuation by etke.cc. Same URL at :8080/admin/, drop-in replacement, still actively developed. A startup guard that had been decorativeThe init scripts have claimed since v2.1.1 to halt the container on a broken configuration so the problem is visible. They did not. s6-overlay defaults to "continue silently" when an init script fails, so a missing SERVER_NAME or a failed config generation produced a running-but-wrong container instead of a loud stop. It now actually stops, with the reason in the log. QR code device linking, opt-inIf you have ever opened Element's Settings → Sessions → Link new device and found Show QR code greyed out with "Not supported by your account provider", that is not an Element bug. QR device linking is built on OAuth 2.0, and a plain Synapse with password logins has none to offer. Synapse will not even start with the feature flag unless authentication is delegated. So this release ships Matrix Authentication Service inside the image. It is off by default and does nothing until you turn it on. With the switch off, not one byte of the generated Synapse config differs from before — that is asserted in CI on every build, because a container update should never rearrange anybody's authentication. Turning it on is a real decision, not a checkbox. It needs a second empty PostgreSQL database and a second reverse-proxy host with HTTPS, and it changes how people sign in: the password field disappears in favour of a browser flow, login by email address stops working, password changes move to the auth service's own web UI, and encrypted bridges break. Your existing accounts stay in Synapse until you migrate them, which the container can now do for you on the next start — it runs before Synapse comes up, which is exactly the offline window the migration needs. Users keep their sessions and are not signed out. The README section Delegated Auth and QR Code Login spells all of that out, including what breaks. Read it before enabling anything, and take a database backup: once the auth service has started and someone has signed in, only a restore undoes the migration. UpgradingNothing to do beyond the usual update. If you do not touch the Delegated Auth fields, the container behaves exactly as it did before. Force Update rather than a plain restart, since Unraid will otherwise happily reuse the cached image on the same tag. Full changelog: github.com/junkerderprovinz/matrix/releases/tag/v2.4.0 As always, bug reports with the Unraid version, the image tag and docker logs --tail 200 Matrix get sorted fastest.

@Kayn thanks for the report, and glad JD_UI_SCALE is working well for you. Both points are fixed in v4.4.1: 1. Download Overview panel corner icons: the settings (wrench) and close (X) icons in the corner of the Download Overview panel were a near-invisible dark grey on the dark theme. They are now drawn in light grey, so they read clearly like the panel's other icons. 2. LinkGrabber "Customize this Bottom Panel" menu: the active entries (Package or Link Properties, Overview Panel visible, Sidebar visible, Autostart Download and the rest) gave no sign of which were on. Each active entry now carries a small light check badge, so its on and off state is clear at a glance. Pull the latest image (or 4.4.1) and recreate the container to get both. Thanks again for flagging them. I'm always happy to see bug report on GitHub. Feel free to open issues there. It's easier for me to stay on top of everyting there.

Hey @Kazem , back home now and I had a proper look at this, as promised. Right now the per-container option only stops and later restarts the dependencies you name for that one container's backup window; it does not yet model a global restart order or wait for a dependency to become healthy before continuing. That is exactly the gap you hit, with Pi-hole not up yet when Authelia and Nextcloud came back. So the useful feature here is not just a backup order but an ordered restart with a wait-for-that-dependency-to-be-healthy gate, and that is what I would build toward. There is already an open issue on GitHub for backup and restart ordering, #119, and I have added your scenario to it. Feel free to jump in there with anything: your concrete example (Pi-hole first, wait until it is healthy, then Authelia, Nextcloud, Pelican and Wings) is exactly the kind of detail that helps me get the design right. Thanks again for the detailed report.

Hi, thanks, glad it is working well otherwise. That error is a hard 12 hour cap on a single backup run: BombVault detaches a backup so it survives a closed browser tab, but it also stopped a run after 12 hours so a wedged job could not hold the repository lock forever. For a backup over 1 TB, especially to a slower or cloud target, 12 hours is simply too short, which is why it stopped at 11 hours 59 minutes with "context deadline exceeded". That is fixed in v7.2.0: the cap is now 48 hours by default and configurable with a new BACKUP_MAX_HOURS setting (a number of hours, or 0 to remove the cap entirely). Update the image, and if 48 hours is still tight for your dataset set BACKUP_MAX_HOURS higher. Thanks for the report, and feel free to open a GitHub issue any time for things like this so I can track them.

@effective-accumulation8557 Spot on, both of those were real template bugs and both are fixed now. The "invalid IP-literal" crash was the Public URL. The template used Unraid's [IP] and [PORT] tokens, which Unraid only fills in for the WebUI field, not for environment variables, so OpenCloud received the literal text and the gateway crashed. The template now uses a real https://YOUR-SERVER-IP:9200 placeholder that you replace with your address, and the container also falls back to its own IP if it is left unset, so it boots instead of crash-looping. On the storage driver: you are right that "local" breaks it. One small correction to the "leave it blank" part, because it is a subtle trap: a blank field is actually what caused the greyed-out files, since Unraid passes it as an empty value and OpenCloud treats that empty value as an explicit override that wipes its "posix" default. So the template now sets "posix" explicitly (or "decomposeds3" for S3), never blank and never "local". Pull junkerderprovinz/opencloud:production and refresh the template for the new defaults. On the GitHub issues being restricted: they are open on our side, there is no restriction from me. GitHub itself blocks brand-new accounts from opening issues on repositories they have no history with (an anti-spam measure on their side), which is most likely what you ran into. Commenting on an existing issue or just posting here works fine, and I will pick it up. Thanks for the detailed report, it made these easy to fix.

@stiernacken Thanks, you were right that the storage driver was the problem. The template shipped it blank, and OpenCloud reads a blank value as an explicit override that wipes its built-in "posix" default, so files ended up without proper permissions (visible but greyed out). The template now sets the driver to "posix" explicitly. If you are using S3, set it to "decomposeds3" instead: that keeps the file blobs in your bucket while the file-tree metadata stays on the local Data volume. Either way the local Data volume needs to sit on a filesystem with extended-attribute support (the Unraid array and cache/pool disks have it). Pull junkerderprovinz/opencloud:production and refresh the template to get the new defaults. Thanks again for flagging it.

Hey @Kazem , thanks for your kind words. I'll look into it next week when I'm back home and give you some more details then. I'm always glad to see feature requests on BombVaults GitHub site, since it's easier for me to stay on top of everything there. Feel free to open an Issue there if you want to.

Hi @Kayn, thanks again for the detailed report on the text blurriness. v4.4.0 is out and adds a proper fix for it. The blurriness comes from how a streamed desktop works: Selkies sends the whole display as one video stream, so when you run a high resolution and then zoom the browser to read it, the browser is upscaling that video and the text goes soft. Browser zoom can never be crisp for that reason, at any resolution. v4.4.0 adds a JD_UI_SCALE option. Set it in the template (for example 1.5 or 2), keep the browser at 100 percent, and JDownloader renders its whole UI larger at full pixel density, so the text stays sharp at the desktop's native resolution instead of relying on browser zoom. Update the container (pull latest, or pin 4.4.0), set JD_UI_SCALE, and restart. Let me know how it reads for you.

Hi @Kayn, That grey look after a reboot is a real bug and it is fixed in v4.3.1. What happened: the dark chrome is applied by the container's in-process agent, which registers the Carbon colours with the theme engine at startup. On a slow or cold boot that registration could lose a race against JDownloader installing its own look-and-feel, and the fallback re-apply did not fully take, so the window came up in the plain grey stock dark theme. Restarting did not help because the same race could be lost again. In v4.3.1 the colours are registered the moment the theme engine is class-loaded, before JDownloader sets its look-and-feel, so the very first frame is the Carbon dark theme on every start, no matter how cold the boot. Please Force Update the container in Unraid (or pull the :latest / :4.3.1 image) and start it once. Your /config is untouched. After that the grey should be gone for good. If it ever comes back, grab the container log and I will take another look. Thanks again for the clear report.

OpenCloudThe official OpenCloud server, turned into a genuine one-click app — no console, no chown, no config editing. What is this?OpenCloud is a modern, self-hosted file sync and share platform (the actively maintained fork of ownCloud Infinite Scale). The official image is great, but on Unraid it runs as a fixed non-root user with no PUID/PGID support and needs a manual one-time init step, so a fresh install normally fails with "permission denied". This is a thin wrapper image that fixes exactly that: it runs the first-boot init for you, heals the appdata permissions, and drops to your chosen PUID/PGID — so you just fill in the Unraid template and hit Apply. Nothing is forked or modified beyond that; the OpenCloud binary is the official upstream image. HighlightsGenuinely one-click — auto-runs opencloud init on first boot, heals root-owned appdata to your PUID/PGID, then starts the server. No console, no chown, no editing opencloud.yaml Serves HTTPS itself on port 9200 (self-signed by default) — works with no reverse proxy, or hands TLS to your proxy with one setting No database — OpenCloud is not Nextcloud; there is no MySQL/Postgres to set up. State lives in a local metadata tree plus an embedded message bus Optional S3 object storage — point it at any S3-compatible bucket (MinIO, AWS, Backblaze B2, Wasabi) to keep file blobs in object storage (the metadata stays local) Two channels — a stable :production tag and a fast-moving :rolling tag, switchable from the template PUID/PGID like every well-behaved Unraid container (default 99:100) Multi-arch — amd64 + arm64 Images: junkerderprovinz/opencloud:production (Docker Hub) / ghcr.io/junkerderprovinz/opencloud:production RequirementsUnraid 6.10+ Set an Admin Password in the template before the first start (it is applied during init; log in as user admin) Use a fresh, empty Data folder. Do not point Data at an old OpenCloud/oCIS data directory — the on-disk layout and the storage backend (local vs S3) are not interchangeable, and there is no in-place migration Behind a reverse proxy: set OpenCloud terminates TLS to false and point your proxy at the container over plain HTTP on port 9200, with the Public URL set to your external https URL For S3: create the bucket beforehand (the container does not), and keep backing up the local Data volume — it holds the file-tree metadata even when blobs live in S3 Posting a bug reportPlease post: Unraid version (Settings → System Information) Image tag (:production, :rolling, or a pinned version) Output of docker logs --tail 200 OpenCloud Whether you use S3 or local storage, and whether you run behind a reverse proxy Whether you changed the Data/Config mounts, PUID/PGID, or the TLS settings GitHub issues with the same info are also welcome: github.com/junkerderprovinz/opencloud/issues CreditsAll the real work is OpenCloud (Apache-2.0) by the OpenCloud team — this project only packages their official image for one-click Unraid use, with a static gosu for the privilege drop. If it saves you a console session, you can buy me a coffee. Independent, community-maintained packaging — not affiliated with OpenCloud. The wrapper is MIT-licensed; you run it, you own your data and the responsibility.

Hi @Kayn, thanks again for the report. All four points are now fixed in v4.3.0, which is live on GHCR and Docker Hub (:latest and :4.3.0). Pull the new image and recreate the container to get it. What changed: 1. Checkbox almost invisible when unchecked. The unchecked border colour was tuned for FlatLaf's lighter default background and disappeared on our darker Carbon #161616. The checkbox and radio-button icons now use a visible border colour. 2. Black "+" expand toggle. JDownloader bakes that toggle into the file column, so a plain config or icon swap could not reach it. It now renders as a light toggle that matches the rest of the dark UI. 3. Progress bar turning grey while scrolling. The fill colour is now pinned so it stays light and consistent, with no grey flash when the table repaints. 4. Event Scripter script editor would not open. This was the interesting one. On any FlatLaf dark Look and Feel (ours, and JDownloader's own dark theme too) the script editor silently aborts while it is being built, so "edit" and "Add" appeared to do nothing. The cause is two null-pointer errors inside JDownloader's own bundled code that only trigger under FlatLaf and are swallowed on a background thread. v4.3.0 works around both, so the editor opens normally. Since these are genuine JDownloader bugs rather than theme bugs, I have also written them up for the JDownloader developers. If anything still looks off after you update, let me know and I will take another look. Thanks for helping make the theme better.

Hi @te5s3rakt, those Xbox / gamepad lines are completely normal and nothing is wrong. This image is built on the LinuxServer Selkies web-desktop base, and Selkies ships a small gamepad interposer so a controller plugged into the machine running your browser can be passed through into the session. To do that it registers a few virtual controllers at startup, and they advertise themselves as Xbox 360 pads, which is exactly what you are seeing in the log. They appear on every boot whether or not you actually have a controller connected, they do not consume any resources, and they have no effect on Krusader itself. You can safely ignore them. If you ever do want to use a gamepad inside the session, it will just work through that same mechanism. Thanks for checking in, and let me know if anything else looks off.