Unfortunately, since My Cloud OS 5, Docker is no longer included. The community Docker app filled that gap, but it has been stuck on Docker 20.10 since 2022, a version that no longer receives security updates.
I needed a current Docker for the services I run on my PR2100, so I built a new OS 5 app package with Docker’s official, unmodified binaries and docker compose. When Docker publishes a new version, a matching version of the app is available on GitHub within a day, built automatically.
2. In the dashboard, go to Apps > Install an app manually and select the file.
Tested on a PR2100 (OS 5.33.102). The PR4100 should work too, but it is untested, so reports from PR4100 owners are very welcome. ARM-based models (EX2 Ultra, EX4100, etc.) are not supported at the moment.
R4100 confirmed working: migrated from the community Docker 20.10 to Docker 29.9.3
Thanks @polius for this package. Here is a field report from a My Cloud PR4100 (OS 5.33.102, kernel 4.14.22), since you asked for PR4100 feedback.
Result
Migrated from the WDCommunity Docker app (20.10.15) to Docker Engine 29.9.3 and Compose 5.7.0.
8 containers are running again: Duplicati, Portainer agent, a Docker socket proxy, a corosync-qnetd (QDevice for a Proxmox cluster), and a few small custom ones.
Survived a reboot test: Docker and every container with --restart unless-stopped came back by themselves.
Remote clients (Portainer, “What’s Up Docker”) work against the new engine. Docker 29’s minimum API version is 1.40, so older clients are fine.
Before installing
I checked the package before trusting it. I unpacked the .bin and compared the SHA-256 of dockerd, docker and docker-compose with Docker’s official docker-29.9.3.tgz and Compose v5.7.0. All three match. dockerctl.sh inside the .bin is identical to the repo version, and the release’s SHA256SUMS matches the file I downloaded.
I ran export-docker-run.sh first. It is read-only and wrote one recreate script per container.
I also archived the old app folder for rollback, and docker saved images that don’t exist in a registry.
Findings you may hit
1. Don’t skip the reboot after uninstalling the old app (or clean up manually). I skipped it, to save time. The old Docker’s network bridges stayed in the kernel, with the same subnets (172.19–172.24) as the recreated networks. Duplicate routes pointed at the dead bridges, so published ports on user-defined networks were unreachable (published ports on the default docker0 bridge worked). Deleting the leftover br-* interfaces fixed it. A reboot would have avoided the problem.
2. security.capability can’t be written on this ext4 volume. The kernel returns ENOTSUP. Docker 20.10 pulled such images fine, probably by ignoring that error. Docker 29 aborts with:
failed to register layer: lsetxattr /opt/base/sbin/nginx: xattr "security.capability": operation not supported
The image that failed was jlesage/dupeguru. Only one file in the image carries the capability, nginx. Other jlesage/* images use the same base and will probably do the same.
Workaround: on another host, export the container, strip the SCHILY.xattr.* PAX headers from the tar, and docker import it on the NAS. The original ENV, CMD, EXPOSE and VOLUME settings go in as --change lines. The result is one flattened layer with the capability gone. The web UI started normally.
The cost is that docker pull can’t update that container. You have to repeat the import.
Question for @polius: could the package or docs mention this? I’m not aware of a daemon setting that tolerates it.
3. Already documented, but worth repeating.
vfs storage driver: images take several times more space, but my 8 images use about 1.3 GB.
DOCKER_INSECURE_NO_IPTABLES_RAW=1: it drops a hardening rule, so other LAN hosts could reach container ports through routing. Published ports work as usual.
Thanks @gsabbe for confirming that it also works for PR4100.
I will update the GitHub repo to note that it has also been tested and works on a PR4100, and I will also document that the NAS must be rebooted after uninstalling the old Docker app.
I’ve been working on the same problem from another direction and thought it might help some people here. Since Docker isn’t specifically my focus, it’s just part of a replacement app store for OS 5 (though it can be installed alone):
The Docker app (also 29.9.3 with Compose 5.7.0 and Portainer 2.45.2 LTS) fixes two problems on WD’s firmware:
Faster storage that also fixes the jlesage/* pulls. WD’s kernel ships without the overlay module, so Docker falls back to vfs, which stores a full copy of every layer. This version builds overlay.ko from WD’s own GPL source for firmware 5.33.102. Docker uses it through the containerd image store with the overlayfs snapshotter. WD’s ext4 doesn’t support security.capability attributes, which is why images like jlesage/dupeguru fail with “operation not supported”. containerd skips those attributes, so the images pull and run.
Container network protection. It also loads a matching iptable_raw.ko, so Docker’s firewall rules stay on. That means DOCKER_INSECURE_NO_IPTABLES_RAW isn’t needed, and containers can’t be reached from the LAN except through the ports you publish.
It also has a web management page that shows the storage state, plus log limits, and its containers come back after a reboot.
If you’d like to test it and you’re switching from another Docker app, remove the old app first, then install this one. Images need pulling again and containers need recreating. Your data is kept if it’s in bind-mounted folders. If old networks are left behind, docker network prune clears them.
I’ve tested this on a PR4100, so reports from owners of other NAS types would be very welcome.
