DesertCookie

Can confirm that you need to add your chat id with echo "MyChatIDnumber" > /boot/config/plugins/dynamix/telegram/chatid. To get your own chat id, do the following (from here): Find UserInfoBot: Search for @userinfobot in Telegram. Start the Bot: Open the chat with @userinfobot and send the /start command. Retrieve Your CHAT_ID: The bot will respond with your chat ID, which is the unique identifier used by Telegram to direct messages to your chat.

Do you plan to somehow offer a way to find a buddy to back up with? Perhaps via a discussion thread on GitHub?

Ran for over a day without any issues. Now, that's half a month ago already, but I hope it's not gone bad since then. But I will retest it before and after I swap the mainboard.

I just started experiencing this with version 7, after having upgraded to it a few days ago after running the betas for a little while. The whole web UI went haywire too and be barely usable. It first started with the Apps page not loading, then the whole UI randomly reloading and returning to Main, where it would show all my drives popping out and back in over and over again. I think it started when I updated the Community Apps Application earlier today. There was a second update that seemed to fix it for a short while but then made it worse. A restart brought the system back to a usable state, showing three errors upon startup: ``` Jan 15 20:50:07 STower24 kernel: traps: mongod[24128] general protection fault ip:151b7d0c79a2 sp:7ffc5eab0230 error:0 in libc.so.6[151b7d0c7000+188000] Jan 15 20:50:09 STower24 kernel: traps: mongod[25705] general protection fault ip:1493b20eb9a2 sp:7fffe9d1d0f0 error:0 in libc.so.6[1493b20eb000+188000] Jan 15 20:50:12 STower24 kernel: traps: mongod[27290] general protection fault ip:1473acfef9a2 sp:7ffe7bbe1420 error:0 in libc.so.6[1473acfef000+188000] ``` Will soon swap the mainboard as that seems to possibly be wonky (threw some NIC errors that made me use a PCIe x1 NIC for now).

Thanks. It keeps happening with BTRFS. Already had changed my cache SSD to XFS a few months back due to other issues. Now I did the same for my Docker image. Has been more stable so far.

After a recent restart Docker won't start. I tried stopping the array, as well as restarting completely. I even attempted to manually restart my daemon which yielded this: root@STower24:~# /etc/rc.d/rc.docker stop rc.docker: Stopping containers... rc.docker: Stopping network... rc.docker: Stopping Docker daemon... rc.docker: Docker daemon... Already stopped. root@STower24:~# /etc/rc.d/rc.docker start rc.docker: Starting Docker daemon... rc.docker: Docker daemon... No image mounted at /var/lib/docker. rc.docker: Starting network... stower24-diagnostics-20241229-1752.zip

Had a lockup shortly after making this post. I've removed my parity disk since then and have had no issues for four days (let's see if that holds). For now, I'm keeping most frequently served data on the former parity HDD which I've added as a second cache pool and back that up using the Mover Tuning plugin, as well as Borgbackup for things such as Nextcloud.

To give a little status update (I will investigate further and try to pinpoint the issue): My issue is not technically solved, but I've made some progress and have had no critical lockups for three days now. My stop-gap solution: Isolate two out of 12 threads. Also, I upgraded to v7.0.0-rc.1, but seeing as this has been an issue even in v6.x I don't see that as a major contributor to the improvements. This points at some Docker container using up too many resources or potentially causing I/O wait, which, depending on the severity, would lock up the system for minutes or hours before. Now, three days by no means indicate that I am in the clear, but it definitely is a milestone. Especially considering that my monitoring tools (Uptime Kuma) reported fewer lockups than before and all of them shorter than 60 seconds where before they would be 10-20 minutes long (or longer, but if by that point the server got locked up, monitoring would stop too which has not happened again so far). These are sub-60s timeouts on my Nextcloud server. These usually aren't noticeable, as they quickly resolve themselves without the user encountering a 504 error. Looking at the time around 7:42 today that had such a lockup, I am not able to see anything out of the ordinary in Grafana, hinting at Nextcloud being the issue; however, this wouldn't explain why other services sometimes are impacted too. I/O wait is not especially high. Overall, the highest I've seen is 24% over the past three days. Uptime Kuma, running on a secondary system now, reports numerous timeouts but ultimately only rare 60s-downtimes. Again, my main instance that only warns after downtimes of 300 seconds did not respond a single time the past days, where before it would regularly report timeouts across almost all of my services. --- A hardware issue definetely isn't out of the question. I'll leave the server running like this for a little longer to potentially find out whether it is some container or other service causing CPU usage or I/O wait. Next step would be swapping out the mainboard. After that, potentially the parity drive, as it has a read and write error rate in the millions. `sdc`, which previously threw a lot of UDMA CRC errors seems to have calmed down now with me having reseated all cables again. SMART tests pass. I'm monitoring it. In theory, it's the youngest drive in my server at 3 years power-on-time.

I added a TP-Link 2.5Gb NIC and reseated all SATA cables, yet continue to experience freezes. I did change some UEFI values that now allow the CPU to clock down to 800MHz on idle. stower24-diagnostics-20241206-2014.zip

Thanks. I don't have any PCIe cards connected. It must be the on-board 10 GbE NOC then. Darn; really didn't want to replace the mainboard. Is this a plausible cause for the server getting hung up occasionally, only responding very slowly? The ATA errors have been coming back every time I've changed ports or cables. I assume it's with the drive, but I can't replace it currently.

For a couple of months now, my unRAID server has been suffering from occasional lockups. Sometimes, the server would recover, most of the time not. Docker containers, even new SSH connections and the WebUI would not load most of the time. I recently managed to have an htop SSH connection running while it happened and the dashboard page open. The CPU seemed to be pinned at 100%. Culprits would change though. Even after having killed the processed pegged at 100+% in htop, the system would stay unresponsive. Any SAMBA connections made before the system locked up would still be usable, though, transferring at below 10 MB/s instead of the expected 2.5 Gb/s (to cache). I've been hard resetting the system. One time, however, I checked in via HDMI and saw the console was still up and blinking. While I couldn't log in, it would show that it was trying to shut down when I pressed the power button correctly. That one time I left it to shut down on its own. It was stuck on `Generating diagnostics` and then later on `Starting diagnostics collection...` for multiple hours until finally having turned off sometime in the night. Diagnostics and screenshot of that time are attached (the image errors on the screenshot are due to my monitor, not the server). Upgrading to v7 in mid-October seemed to solve the issue for a few weeks, but it came back soon thereafter. Rebuilding the thumb drive always seemed to buy me a week or two without issues, but considering I've changed USB ports and thumb drives multiple times now, buying brand new ones, it might be another issue still. I've tried removing unneeded devices, such as a GPU (GTX 1650) and an M.2 riser to see if those could be the culprit, but saw no change in behavior. The 11400 in this system is set in UEFI to not boost and to power saving to reduce energy consumption. Under normal operation I see around 30-50% utilization, only spiking when some Dockers transcode or run a game server. I don't experience IO-wait from my cache or array. stower24-diagnostics-20241117-1934.zip

Does `/usr/libexec/netdata/plugins.d/go.d.plugin` have anything to do with this plugin? I've encountered this application multiple times now using 100% of my CPU and completely locking up my system.

Well, one Docker container is not working properly. That alone could be an indication of a faulty thumb drive. For me, only the WordPress container and another container would have networking issues and only half the time. More than 20 other containers had no issues at all. Especially networking only requires one tiny thing to be wrong to break in unexpected ways. It literally takes ten minutes to reflash your thumb drive. Couldn't hurt to try. Again, make sure to copy your "config" dir and license file though.

I recently faced this issue on a frequent basis. It turned out to be a faulty thumb drive. Are you experiencing issues with other containers too? If so or if unsure, recreate your boot drive. Simply copying over the config folder will have your server start up as if nothing changed. If the issues vanished, you need to get a new thumb drive ASAP (if you haven't already).

Did both of these. Had enabled macvlan after some issues with Docker containers being unable to see each other; that seemed to fix it back then. tower-diagnostics-20240510-1851.zip

Thanks, forgot to add that I made sure my configurations were still as they were beforehand. I added some pictures to the OG post. I have also attempted to create a new share that's fully public, in case the existing share's configuration was somehow borked. That share too was inaccessible via the network.

My unRAID server's shares don't appear in the network. Not even the server appears in the network tab of my Windows computers that used to have connected network drives that are now offline. I can, however, access the server's root directory via its IP; here, no shares are being shown and manually going into a share via its path of `\\IP\PATH` does not work. This behavior follows a restart of the server after having solved a different issue a couple of days ago. As far as I am aware, no settings beyond removing the cache SSD from accidentally being passed through to a VM were changed. I have checked from multiple Windows and one Android device. The server is not visible in the network via SMB. SSH and any other applications (running lots of Docker containers) are working though. Only SMB seems to be faulty. Thanks. tower-diagnostics-20240510-1251.zip

That's... what? Thanks for pointing that out! That VM has been dormant for months now and I never started it up since removing its GPU. I never had the NVMe drive passed to it, but had a HDD passed though that I removed when upgrading to 6.12. Does it make sense that the NVMe bound itself to the VM and that this causes issues, despite the VM not being turned on? Perhaps the new USB I made reassigned the VFIO IDs and the SSD thus moved up into the place of the now removed HDD...? I assume this is not expected behavior. Do you think it's worth investigating and potentially opening a bug report?

I've tried reformatting for the third time now. I've used a brand new SSD. I've used a carrier card. I've swapped RAM. Every time, the cache turns read-only within minutes of starting the array. tower-diagnostics-20240505-1843.zip

I do not have an AIO backup. As with every other Docker container, I simply automatically back up the volumes on a nightly basis. I was assuming AIO would be able to deal with that, as any other container does.

Thanks. However, as far as I can see, the guide does not mention how to change the volume locations. There actually is a comment by `dude` asking my very question. You may be confusing the `NEXTCLOUD_DATADIR` with the volumes of the database, redis, talk, etc. as that is the only data location that is actively changed in the linked guide and is what you refered to as `/mnt/user/aio/data` earlier.

In terms of installing, all I did originally was install the AIO docker. I left everything on default. This created several volumes in `/mnt/user/system/docker/docker/volumes`. That was with using a directory instead of a vDisk (meaning there were other folders such as `/mnt/user/system/docker/docker/btrfs`. Now, I'm using a vDisk and have that in `/mnt/user/system/docker/docker.img`. What I don't have is a `volumes` folder next to it into which I could copy my existing files from the original install.

Due to issues with Docker and my cache drive (see here) I had to switch from using Docker with a directory to using it with the default BTRFS vDisk. I had originally used a directory due to Nextcloud AIO using volumes and storing its database and such there. Now, obviously, with a vDisk the location of volumes has changed. I've been trying to locate the new location for the past two days to copy my exisiting data to. Has anyone had to go through this before and knows more than I was able to find out? Thanks a lot!

In hoping that I might have done something wrong earlier that you can point out, here's how I already did that this morning: 1. Stop the array. 2. Remove the SSD from the pool. 3. Delete the partition via Unassigned Devices. 4. Add the SDD to the pool. 5. Start the array and reformat the pool drive. 6. Restarted the server for good measure. Edit: After reformatting again, I still get this issue. Docker, for example, says: `docker: Error response from daemon: error creating temporary lease: file resize error: truncate /var/lib/docker/containerd/daemon/io.containerd.metadata.v1.bolt/meta.db: read-only file system: unknown.` Edit 2: For now, I've removed the cache drive entirely and running everything off the array HDDs. I'm still unsure on how to proceed due to the cache drive's behavior (especially it appearing twice).

I recently had issues with my iGPU and this recreated my entire USB. The only thing I kept is the data on my three data drives. Beforehand, I had copied all data off my cache SSD and reformated it with the new install. Now, after copying all Docker data back over, I now encounter issues with reinstalling the old containers. Via SSH, I get the message that my cache is read-only. The SSD sometimes appears twice (see image); once in the cache pool and a second time as an unassigned device. tower-diagnostics-20240426-1508.zip