Junker der Provinz

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.

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!