OpenCloud - OpenCloud.eu

[Kroooms]

Hey DietPi-Team,

first of all, thx for this fine plattform!

An installer for OpenCloud would be awesome.

OpenCloud is a very good alternativ for NextCloud or OwnCloud.
It is DSGVO conform (relevant for users in Germany) and should have a better performance than Open- and NextCloud.

Unfortunately I can't help in anyway but testing, because I'm not good in coding stuff.

I tried to install OpenCloud on a DietPi System on a RaspberryPi 5, but I didn't get it working.

Cheers!

Krooms

https://github.com/opencloud-eu

https://opencloud.eu/de

[homer276]

Hi,
I'm also looking for a way to install opencloud on a Raspi 5 with Dietpi as a foundation. Unfortunatly also no success. On a Raspi 4 with "PI Os" it was quite easy to make it work. I used this "recipe" ( https://www.heise.de/ratgeber/OpenCloud-auf-dem-Raspberry-Pi-installieren-10751093.html )
Tks
Henning

[Joulinar]

Unfortunately the article is behind a paywall

[homer276]

Oops... sorry . This link : https://github.com/opencloud-eu/opencloud-compose basically is the same/similiar. What I read that there might be a problem for a Raspi 5 systen and / or the version of docker-compose.
Tks

[MichaIng]

The problem is this: #7830
With Traefik it is the same/worse, since they use the previously oldest possible API version 1.24. But same workaround works, until Traefik updated their API calls:

G_SUDO G_CONFIG_INJECT '"min-api-version":' '    "min-api-version": "1.24",' /etc/docker/daemon.json '^\{([[:space:]]|$)'
sudo systemctl restart docker

EDIT: Oh, although Traefik fixed this already (quite elegantly): traefik/traefik#12256
Should work from v3.6.1 on. Hence try again, just assure that the local Traefik container image is up-to-date.

[homer276]

Hi, tks :-) At least I can see now the opening screen on a raspi 5 and basic functions are available. For testing I just use it internally in the local network. Step by step .....

[Joulinar]

Bootorder is 1 4 6

You have to read the boot sequence from back to front. To boot from the SD card first, it should look like this.

BOOT_ORDER=0xf461

See RPI docs https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#boot_order-examples

[homer276]

Tks, done that and boot was succesfully into the 2nd SSD. But result same as before : meaning no connection to opencloud. Just blank screen. I will first sort out the other "problems" and keep the Rpi4 running Opencloud

[MichaIng]

Can you verify the regular v8 kernel is used:

uname -a

And are there any error messages in container logs?

[homer276]

Linux DietPi 6.12.47+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1 (2025-09-16) aarch64 GNU/Linux

Thats the kernel used on the RP4 and same on the RP5 . In the container log I can't see anything suspicious. But I'm not an expert in this field :-)

[MichaIng]

Strange. Last idea I have then is that one of the related containers is using an outdated ARMv8 binary. E.g. our old stable dietpi-dashboard did not support RPi 5 either, which uses ARMv8.2-A CPUs instead of ARMv8-A. A rebuild with recent Rust tools solved this. This was causing a segmentation fault in our case, so I would expect to see something like this, or less likely "illegal instruction" or so emitted by one of the binaries of those containers.

Is there some report/issue at OpenCloud about this already?

The beauty of AI-assisted search machines:

The 1st link is about installing ownCloud on DietPi via dietpi-software. The 2nd is indeed about installing the legacy PHP-based ownCloud via Docker, with abuses Docker for getting ancient PHP 7.4 😄. They even have an own repository for this now: https://github.com/owncloud-docker/php/blob/master/v22.04/Dockerfile.multiarch
Seems to be less work than just adding support for recent PHP versions to this abandoned code base 😢.

[MichaIng]

I had another look, and it actually is just a single Go binary, barely worth to warp a container around. Although not sure whether it supports HTTPS directly, or requires a reverse proxy for that. They provide binaries for all architectures but RISC-V:

cd /tmp
wget https://github.com/opencloud-eu/opencloud/releases/download/v3.7.0/opencloud-3.7.0-linux-arm64 -O opencloud
chmod +x opencloud
./opencloud init
./opencloud server

So we could theoretically just wrap a systemd service around it with a service user. Surely some preconfiguration is possible with config files, or via CLI or so.

[MichaIng]

Did you do the opencloud init? That is supposed to create a default config, as far as I understand.

[Joulinar]

yes I did but it will create a yaml file and not the json one

[MichaIng]

Ohh, I first thought the init would generate a YAML while the server expects a JSON, which would have been funny. But these are two different configs for different purpose. The JSON is generated by the server itself, but only if OC_URL is set to the actual URL:port used to access it. I wonder why the ìnit is not doing this already ... or maybe it would as well if OC_URL was set. Testing again ... nope, it is not stored on disk it seems.

So e.g. I run:

OC_URL='https://192.168.1.25:9200' ./opencloud server

Now web UI works. But I cannot login because, it seems, the auto-generated TLS cert is valid for 127.0.0.1 only, even when using OC_URL='https://192.168.1.25:9200' for the init. Hence trying with certificate checking disabled.

Some related difficulty is, if a login failed what whatever reason, I cannot get back to the login mask. It seems to remember the user and just returns the same error again, even after restarting the server and clearing all browser data 🤔. I needed to remove the whole ~/.opencloud dir and start over.

Yeah, but with certificate checking disabled it works. I wonder how to force it to generate the self-signed certs for a custom IP or hostname, like 192.168.1.25 in my case. It generates a lot of certs, an own for every single "service" (all just one process, but internally split into so called services for e.g. user backend etc.

... another thought, it actually makes sense that the backend certs are valid for 127.0.0.1 only, if the intended setup is using a local proxy, as that one is accessing via 127.0.0.1. If there is no way to alter this, a central part if OpenClouds security concept seems to be impossible without dedicated proxy server. A bid unnecessary IMO, since a proxy does not inherently add anything to security.

... checking docs again regarding bare-metal installation: indeed there they state to disable cert checking as well: https://docs.opencloud.eu/docs/admin/getting-started/other/bare-metal#build-process-and-opencloud-initialization

If no obvious way to alter the IP for those certs can be found in the source code, something to make a topic/ask about. Until then, we could implement it in combination with a webserver, or HAProxy, or frp, and of course the Docker Compose instructions work, e.g. installing Docker Compose via dietpi-software, then folllowing their docs from this section on: https://docs.opencloud.eu/docs/admin/getting-started/container/docker-compose/docker-compose-base#clone-the-opencloud-repository

[balleny]

this is quite a detailed explanation about getting it running (generic, not specific on Raspi), what to configure etc. that might help or fill a gap - you will need to translate it from German to English tho:
https://decatec.de/home-server/ein-erster-blick-auf-opencloud-installation-inkl-collabora-apache-tika-und-clamav/

[MichaIng]

Well that is just the Docker Compose method that is well covered by the official docs as well.