OpenCloud

The 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.

Highlights

• Genuinely 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

Requirements

• Unraid 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 report

Please 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

Credits

All 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.

Thank you for this, i will give it a try to replace nextcloud.

It seems that it is nessasary to give S3 storage driver: posix

Otherwise you have no file permissions.

Hello! Thanks for the UnRAID app template! I can't get it to work, and I'm getting this error: {"level":"error","service":"gateway","host.name":"c009ebc3b63d","protocol":"grpc","error":"unable to register services: rgrpc: grpc service gateway could not be started,: parse \"https://[IP]:[PORT:9200]/data\": invalid IP-literal","time":"2026-08-03T00:34:07Z","line":"github.com/opencloud-eu/reva/[email protected]/cmd/revad/runtime/drivenserver.go:91","message":"reva server error"}

Error: unable to register services: rgrpc: grpc service gateway could not be started,: parse "https://[IP]:[PORT:9200]/data": invalid IP-literal

I can't open a GitHub issue because they are restricted.

Got it working by putting in the actual address. The templatized version is only supported by UnRAID for the WebUI field.

STORAGE_USERS_DRIVER being set to local breaks even local storage. (Should be left blank so that the default of posix applies)

On 8/1/2026 at 1:17 PM, stiernacken said:

Thank you for this, i will give it a try to replace nextcloud.

It seems that it is nessasary to give S3 storage driver: posix

Otherwise you have no file permissions.

@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.

19 hours ago, effective-accumulation8557 said:

Got it working by putting in the actual address. The templatized version is only supported by UnRAID for the WebUI field.

STORAGE_USERS_DRIVER being set to local breaks even local storage. (Should be left blank so that the default of posix applies)

@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.

I would like to use the Smart Search Engine (Apacha Tika). But it seems to be disabled as default.

So i find that i have to edit the .env file and change, but how?

TIKA=:tika.yml #is commented out by default

TIKA_IMAGE=latest

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.

Edited August 11Aug 11 by Junker der Provinz

@Junker der Provinz hello, when I install euro office I get the below error. I just supplied the JWT secret and I get this error.

Edited August 11Aug 11 by HHUBS

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.

Edited August 11Aug 11 by Junker der Provinz

14 hours ago, Junker der Provinz said:

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.

Thanks. But when I tried the updated template and installing second instance of euro office to test, I got the below error. The nginx fail.

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.

3 hours ago, Junker der Provinz said:

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.

Done. Please see https://github.com/junkerderprovinz/unraid-apps/issues/5 thanks.