domori

Hey, install of the plugin seems to be broken with the current version of OpenClaw. When using openclaw plugins install unraidclaw you'll get an error saying that unraidclaw is a skill and to use openclaw skills install unraidclaw. When using that it installs fine, but once you configure it as a plugin in openclaw.json you'll break the installation as the gateway won't restart. Added the output of my shell. shell.log

Thanks Jorge. Changed it to image yesterday. Didn't have to reinstall anything today. So I guess that works. Thanks a lot!

Hey, since updating to 7.2.3 I've got a strange problem. I updated to 7.2.3 on Friday. Everything was fine. On Saturday all the Dockers went missing. I rebooted the server and reinstalled the containers. Everything fine. Come today, again everythings missing. Was greeted with those two notifications and thats it. I didn't change anything except updating to 7.2.3. Any ideas what could be wrong? I don't get it. After yet another reboot everythings gone again and I have to reinstall all the containers. storage-diagnostics-20251221-1237.zip Alright... After rebooting, I'll get the following error when trying to reinstall for example Duplicacy: docker: Error response from daemon: open /var/lib/docker/overlay2/6195fc31a5568f729c5c1093b70133634c030a1291f3940bc66a6c9702703bed/.tmp-committed1929448033: no such file or directory.

As of now, it still appears to be working, so I'll mark that as solved. Thanks a lot JorgeB! Tried shutting the array down a couple of times over the last days and it worked every time. So I'll stop that now and I guess I'll see whether or not that was the final fix when I'm updating the next time.

Great, thanks for the heads-up. The thing with the overlay driver completely slipped past me. I’ve made the changes, deleted the directory, and pulled the containers again. I’ll keep an eye on it over the next few days.

Sorry for the late reply, but I’ve been trying to further trace the error. So… the issue doesn’t always occur. After updating to 7.1.2, everything ran fine the day before yesterday and yesterday. In the evenings, I tried stopping the array a few times, which worked without any issues. Today I tried the same thing again, and once more I can’t stop the array. The error is the same error as before. I’m not sure how to trace the problem if it can’t be reliably reproduced. It seems like the error only occurs after a few days. Every few seconds (around every 2 to 5 seconds), I see write operations on the cache lasting about 2 seconds, with a throughput of about 300-400 KB/s each time. But as far as I know, the cache shouldn’t still be in use. Tried the following, but nothing: root@Storage:~# losetup NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop1 0 0 1 1 /boot/bzmodules 0 512 /dev/loop0 0 0 1 1 /boot/bzfirmware 0 512 Tried that, but nothing, no result: root@Storage:~# lsof /mnt/cache storage-diagnostics-20250514-1915.zip

Hi everyone, I've been having an issue for quite some time now: whenever I try to shut down the array, for example, to perform a reboot, it's not possible. I keep getting the message "retry unmounting disk share(s)" indefinitely. This has been happening since the 6.12 versions and continues with the current version. Just now, when I started the update to 7.1.2, I ran into the same problem again. What I notice is that there are write accesses to the cache with a couple of kilobytes every few seconds, but I have no idea where they're coming from. Before shutting down the array, I always stop the Docker and VM services and unmount any mounted SMB shares. At this point, I genuinely have no clue what else could be accessing it. As far as I'm aware, I don't have any open terminal sessions either. Is it possible to trace anything using the diagnostics? storage-diagnostics-20250512-1325.zip