Hi,

I have been running Opencloud on my Unraid server for a few weeks without any issues. I am using the official docker compose stack (I followed the official guide) with the Compose Manager Plus plugin.

Last week I upgraded Unraid from 7.3.1 to 7.3.2 and added another drive (disk5, no shares so far) to the array. During an Opencloud sync from my laptop the transfers stopped. It seems like the Traefik container had stopped while the other parts of the stack continued to run. At the same time the Unraid interface became sluggish. On the Dashboard page, the System and Interface graphs stopped working while the Processor graph continued to work. The VMs tab did not work at all. Changing browser from Firefox to Chrome briefly worked (not the VMs tab), until the GUI become completely unresponsive.

I am still able to access the server through SSH. I tried powerdown -r, waited a few minutes but nothing. I eventually run,

echo 1 > /proc/sys/kernel/sysrq

echo s > /proc/sysrq-trigger

echo u > /proc/sysrq-trigger

echo b > /proc/sysrq-trigger

which successfully rebooted the server, but of course triggered an array check.

My other dockers (Immich, LubeLogger, Homepage, Jellyfin, restic-rest-server) and my Home Assistant VM continues to run fine while Opencloud and the GUI stops working. The appdata and domains shares are on the cache with exclusive access. The Opencloud share, which the config and data directories are mounted to, is on cache->array.

I waited until the array check completed, changed the docker btrfs-image to directory, and started the Opencloud stack again. My laptop tried to sync but did not even manage to start a file transfer and the Unraid GUI once again become unresponsive.

The only form of error I have managed to find so far in the logs are:

Aug 3 17:45:17 Weymouth nginx: 2026/08/03 17:45:17 [error] 14583#14583: *10730 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.253.0.8, server: , request: "GET /sub/session,var,notify?last_event_id=1785770904%3A-%2C%5B0%5D%2C- HTTP/1.1", subrequest: "/auth-request.php", upstream: "fastcgi://unix:/var/run/php-fpm.sock", host: "192.168.1.6"

Aug 3 17:45:17 Weymouth nginx: 2026/08/03 17:45:17 [error] 14583#14583: *10730 auth request unexpected status: 504 while sending to client, client: 10.253.0.8, server: , request: "GET /sub/session,var,notify?last_event_id=1785770904%3A-%2C%5B0%5D%2C- HTTP/1.1", host: "192.168.1.6"

Aug 3 17:47:01 Weymouth nginx: 2026/08/03 17:47:01 [error] 14583#14583: *10781 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.253.0.8, server: , request: "GET /sub/session,var,notify?last_event_id=1785770904%3A-%2C%5B0%5D%2C- HTTP/1.1", subrequest: "/auth-request.php", upstream: "fastcgi://unix:/var/run/php-fpm.sock", host: "192.168.1.6"

Aug 3 17:47:01 Weymouth nginx: 2026/08/03 17:47:01 [error] 14583#14583: *10781 auth request unexpected status: 504 while sending to client, client: 10.253.0.8, server: , request: "GET /sub/session,var,notify?last_event_id=1785770904%3A-%2C%5B0%5D%2C- HTTP/1.1", host: "192.168.1.6"

Aug 3 17:47:42 Weymouth php-fpm[9908]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

Aug 3 17:54:18 Weymouth nginx: 2026/08/03 17:54:18 [error] 14583#14583: *11535 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.253.0.8, server: , request: "GET /sub/session,var,notify?last_event_id=1785770904%3A-%2C%5B0%5D%2C- HTTP/1.1", subrequest: "/auth-request.php", upstream: "fastcgi://unix:/var/run/php-fpm.sock", host: "192.168.1.6"

Aug 3 17:54:18 Weymouth nginx: 2026/08/03 17:54:18 [error] 14583#14583: *11535 auth request unexpected status: 504 while sending to client, client: 10.253.0.8, server: , request: "GET /sub/session,var,notify?last_event_id=1785770904%3A-%2C%5B0%5D%2C- HTTP/1.1", host: "192.168.1.6"

I have attached my diagnostics, which were generated after a reboot since the diagnostics command fails when these issues occur. My syslog server is running, so those logs are included as well.

I would very much appreciate it if someone has any suggestions on how to resolve this issue.

weymouth-diagnostics-20260803-1818.zip syslog-192.168.1.6.log

Edited August 5Aug 5 by BlindOwl

Here's a small update:

I started the Opencloud stack with all other docker containers stopped and the VM powered off.

Everything ran fine. I could access the Opencloud web UI without issues as was able to upload and downloaded files sucessfully.

I have three shares in Opencloud: personal, work and shares.

Personal - I started syncing this folder. All files synced as expected, though it only contained a few files.

Shares - This folder is empty, no issues.

Work - This share contains over 2000 files (50-1000 kB each) and over 100 files (100-200 MB each) waiting to be uploaded to the server. Syncing this folder failed within seconds.

I suspect that Opencloud attempts to sync too many files simultaneously and somehow saturates something in Unraid, leading to these issues.

The last output from docker logs -f opencloud-opencloud-1 is attached to opencloud-docker-log.txt.

The diagnostics command did not finish, I have attached what it managed to collect.

Perhaps this is an Opencloud issue and would be better suited for their community. However, I have three Unraid-related questions:

1. Why does this cause the web UI to eventually become unresponsive?

2. Why don't commands like diagnostics and powerdown -r work after the issue occurs?

3. Is is possible to do a graceful reboot of the system in this state?

opencloud-docker-log.txt weymouth-diagnostics-20260807-1606.zip

Please enable the persistent syslog server and then grab diagnostics next time it occurs. There are no logs in the last diagnostics you uploaded and the first one has nothing I can see wrong.

18 minutes ago, MowMdown said:

Please enable the persistent syslog server and then grab diagnostics next time it occurs. There are no logs in the last diagnostics you uploaded and the first one has nothing I can see wrong.

I have the syslog server running but I forgot to attach it. I have now done so.

Related timestamps:

Aug 7

15:14 - Starting the opencloud stack

15:23 - Opening the opencloud website

15:34 - Syncing of Personal folder - Success

15:41 - Syncing of Work folder - Fail

16:04 - powerdown -r

The diagnostics command does not work properly when this occurs, what I've attached is all it generated.

Do you have any suggestions for how I can reboot the system without triggering an array check? Currently, the only way I have found is:
echo 1 > /proc/sys/kernel/sysrq

echo s > /proc/sysrq-trigger

echo u > /proc/sysrq-trigger

echo b > /proc/sysrq-trigger

syslog-192.168.1.6.log

Addition: The docker stack should be stopped, but opencloud server processes still appear in htop.

Edited Friday at 06:55 PM5 days by BlindOwl

I dont really see anything in the logs provided. The opencloud server though should be running in a container not directly on unraid. You are running it in a docker container right?

the only others things to check for is IOWait (check using top and look for the wa: number to be close to 0 as possible.

powerdown is deprecated so no idea if that actually works anymore.