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 August 7Aug 7 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.

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 unresponsive

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

Same 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 state

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

Thank you @Junker der Provinz , this is really informative.

The issue has now been resolved by updating OpenCloud to 7.5.0. Bugfix: https://github.com/opencloud-eu/opencloud/pull/3347