Junker der Provinz

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.

Hi @Kayn , thanks a lot for the detailed log, that pinpointed it right away, and sorry for the trouble. What happened: a routine dependency bump built one of the container's helper components (the dialog agent) with Java 25, but JDownloader itself runs on Java 21. The Java 21 runtime refused to load the newer class ("class file version 69.0 ... up to 65.0"), so the JVM aborted at startup and the autostart kept relaunching into the black screen. A fresh install couldn't help because the broken build was already in :latest. I just released v4.2.1, which compiles that component for Java 21 regardless of the build JDK, and hardens the CI check so this can't slip through again. The fixed :latest is already published. To recover: run a Force Update on the container in Unraid (or "docker pull" on the CLI), then start it. If it doesn't pull the new image right away, you can also point the repository tag at :v4.2.0 as an immediate stopgap. Both get you running again. Thanks again for the report, and let me know if anything is still off after the update.

Great idea, and a smart one — you're right that SemVer level alone isn't enough. It's live in v2.4.0. New setting in the Updates tab: "Never if changelog mentions" — a comma-separated word list (e.g. breaking, migration required). If the pending update's own release notes contain any of those words, ShipLog blocks it — never applies it — no matter what your level policy would otherwise allow. So "breaking" catches exactly the immich-v1 case: a minor or patch bump that calls out a breaking change in its own notes. Blocked updates aren't silent — they show up in the run summary (ShipLog log + Matrix, if you use it), including in Dry run, so you can watch the safety switch actually catch something before you trust it on a real schedule. It's off by default (empty list = no effect on anyone who hasn't opted in). Thanks again for pushing on this — this is exactly the kind of feature that's better for having a real use case behind it. Looking forward to see your feature requests on GitHub. 😉

Thanks for the thorough second round, @btTeddy, and for marking what the reinstall already fixed. That kind of testing is gold. ShipLog 2.3.0 is out with the rest of your list: Readable changelogs. Release notes are now rendered properly (headings, bold, code, links, bullet lists), and stray HTML entities like the literal   from your screenshot are cleaned up. Everything gets escaped before rendering, so no upstream HTML ever runs in the page. Your precedence idea is in, exactly as proposed. The chain is now: manual override, then curated default, then the template's Project page (when it points at GitHub), then the OCI source label. And yes, the curated defaults are a small hardcoded map in the engine, currently the common LinuxServer apps with real GitHub releases; a manual override always beats everything. With the Project page in the chain, media-preview-generator should now pick up its own repo instead of the ffmpeg base label, and seerr from hotio gets a source at all. Plex staying on the LinuxServer changelog is correct, as you guessed: those updates really are image rebuilds. Uninstall no longer touches your data. You are right that a read-only advisor should not delete a user-visible folder on its own. Removing the plugin now keeps /mnt/user/appdata/shiplog, so a reinstall resumes with the full version history, and the removal message tells you where it lives if you want it gone. One small ask: bug reports and ideas like these are very welcome on GitHub too (https://github.com/junkerderprovinz/shiplog/issues). They are much easier to track and work through there, and you can see exactly when something ships. The thread stays open for everything else, of course. Thanks again, this round made ShipLog noticeably better.

Thanks for the really precise report, @btTeddy. That per-symptom breakdown made the root cause obvious. All of it traces back to one thing: ShipLog took the changelog repo straight from the image's OCI source label (org.opencontainers.image.source), which for a lot of images is the packaging wrapper (the LinuxServer docker-* repo), inherited wrong from a base image (that's your media-preview-generator pointing at linuxserver/docker-ffmpeg), or simply missing (hotio/seerr). Fixed in v2.1.0, pretty much exactly as you suggested: - Per-image source override, right on the status page at IP:8484. Click "source" on any row and point it at the correct GitHub repo (owner/repo or a full github.com URL). The engine then mines the changelog and the link from there for that image, and it sticks to the image so it survives container recreation. That covers the wrong-link and missing-changelog cases. - Common LinuxServer apps now resolve to their upstream project out of the box (Radarr, Sonarr, Lidarr, Prowlarr, Readarr, Whisparr, Bazarr) instead of the wrapper's dependency-bump log. A manual override always wins over that. Precedence is: override > curated default > OCI source label > version-delta fallback. Update the plugin (or reinstall from the .plg URL below) and it's there. If you find an image where the override or a curated default is off, tell me the image and the repo it should point at and I'll sort it. .plg: https://raw.githubusercontent.com/junkerderprovinz/shiplog/main/plugin/shiplog.plg

Good news: found and fixed it. Thanks for your patience! Two things could go wrong on a fresh install, and both depend on timing. The dark theme file was not always visible to the Java UI loader at startup, and in some cases the theme file itself got corrupted during the very first install. That is why some installs came up white while others were fine. Both fixes are in the latest image. Please do a Force Update on the container. Your existing setup repairs itself on the next start, there is nothing to delete and nothing to configure. Once the dark GUI is verified, the log ends with a big JDOWNLOADER IS READY banner. About the log command: the part "> jd.log 2>&1" writes everything into the file jd.log instead of showing it in the console, so an empty console was expected there. The output was in that file all along. Even easier: in the Unraid Docker tab, click the container icon and choose Logs. But you should not need any of that anymore.

Thank you so much for testing again and for the detailed report, this one was genuinely valuable. Good news first: your JDownloader was actually running fine at the end, the log you posted shows a fully successful start. It only LOOKED stuck, and that was my fault twice over. What happened: the container has a watchdog that restarts JD if the dark theme is not applied. It correctly protected the very first start, but I forgot to protect the later restarts too. On your machine it judged JD too early while it was still starting up, killed a perfectly healthy process, and did that until its safety budget of 3 restarts was used up. On top of that, the READY banner was only printed once per container start, so after those restarts you had no signal that JD had come up fine again. Both are fixed now: the watchdog gives every restart a proper grace period, and the READY banner is printed again after every internal restart, so the log always tells you the current state. Please force update the container once more and do a fresh install. You should see the banner, and if JD ever restarts internally, a new banner right after. The small "Error" popup you saw twice is JD's tray icon check, it is auto-dismissed by the container and completely harmless. If anything still looks off after this update, please run "docker logs JDownloader > jd.log 2>&1" and attach the whole file instead of the last 200 lines, then I can see the full story from the very first second. Thanks again for your patience, your reports have directly improved the container three times!

Thanks a lot for the extra details and the full log, that confirmed it perfectly. Your log shows JD itself running fine, but the FlatLaf theme extension never got installed, which is exactly why the banner honestly said "theme NOT verified" and the GUI stayed light. You did nothing wrong, and your changed host paths are fine too, this was a gap in how the container installed the theme. I have just released v3.0.0 which rebuilds that whole mechanism from the ground up. The theme now goes through JDownloader's official extension system and the container requests it before JD even starts, so it installs together with JD itself. Fresh installs come up dark from the very first frame with no dialogs at all, and existing setups like yours heal automatically: the container keeps requesting the theme until it is installed, JD restarts itself once, and the READY banner only prints when the dark theme is really applied. To get it, just force update the container so it pulls the new :latest and give the first start a few minutes. You should then see the big ASCII banner followed by JDOWNLOADER IS READY in the log, and the UI will be dark. If anything still looks off after that, post the tail of the log here and I will take it from there. Thanks again for the report and your patience, it genuinely made the container better for everyone!

Hi @Squid, small heads-up on the new app-card layout in the latest CA update: on the cards, the app name overlaps the bottom of the icon. The cause looks like the icon is 8rem tall (img.ca_displayIcon) but .ca_iconArea only reserves 6.4rem and has no overflow, so the icon spills ~1.6rem past its box and the title right below it runs into it. It showed up with the recent "cleaner app-card titles" rework (dropping the category line and lowering the title's padding-top). Two easy options if it helps: .ca_iconArea { height: 8rem; } /* container gets the icon's real height */ .ca_holder .ca_applicationName { padding-top: 2.5rem; } /* or just push the title clear of the icon */ Thanks for all the work on CA!

Thanks @phunky1, really glad it's useful to you! Both of those are good ideas: - Start and end time on the Dashboard "Last Backups": an easy one, since each run already records when it started and finished, so showing the times (and the duration) there is straightforward. - A search/filter box on the Containers tab: agreed, once you have a lot of them the list gets unwieldy. On where to post: GitHub is the better spot for feature requests and bug reports. Filed as issues they don't get lost in the thread and I can track them properly, so if you don't mind dropping these two into separate issues over at github.comjunkerderprovinz/bombvault/issues that would be perfect. I've noted them down in the meantime either way. Thanks again, and thanks for all the reports as ptmorris1, they've been genuinely helpful.