trurl

Are you trying by servername or IP?

You can look at your syslog, it has timestamps. If you have dockers that depend on other dockers you would want them to start in a particular order, maybe with some delay. Mariadb for example might be the database for other dockers.

Go to Tools-diagnostics and attach the complete Diagnostics ZIP file to your NEXT post

Have you tried it with turbo write as suggested in that thread?

Perhaps this is a typo, but /usr/mnt doesn't exist normally, and has nothing to do with user shares. Not really a useful report without them: https://forums.unraid.net/bug-reports/prereleases/how-to-install-prereleases-and-report-bugs-r8/ And your symptoms suggest other problems that wouldn't be related to any specific release.

The screen isn't refreshed sufficiently fast for you to claim "exact same time". And there is buffering to consider also. If allocation method is causing it to choose first one disk then another then writing to more than one disk during a brief interval is exactly what I would expect. Do the test if you don't remember.

Not clear why you think it shouldn't. In fact, you have a share with allocation set to Most Free, and many of your drives are very full. It shouldn't be surprising that it constantly switches between disks when it is moving that share.

You can select that in the nvidia plugin

If you have ECC then memory isn't likely the problem, and that would show up differently in syslog anyway.

Have you tried memtest?

That particular btrfs device is your docker img vdisk. It probably lives on your cache though so there might also be a problem there. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post.

yes

Just saw this on another thread, don't know if it is relevant or not:

According to your diagnostics, your appdata folder isn't shared (exported) on the network. In the Unraid webUI, go to Shares - User Shares, click on the appdata share to get to its page. There you can configure the settings for the appdata share, including whether or not to share it on the network.

8TB is what I just bought when I needed to replace a drive (had to do parity swap). Now I will be replacing 6TB drives with 8TB drives as needed. My storage needs don't grow very quickly and my mITX case won't hold many disks. You will still need backups of course, parity is not a substitute. I just finished a rebuild myself, thread here: https://forums.unraid.net/topic/93149-mitx-motherboard-which-can-support-7-drives-on-board/ Some of us have our hardware listed in our sig, but unfortunately, viewing sigs is disabled by default on this forum. You can enable sigs (and create yours) by clicking the dropdown next to your user name in the upper right and going to Account Settings.

It would be more helpful if you wouldn't edit the first post without at least making a new post with the new information. We have no idea you have done this without going and looking for it, and we have no reason to go looking for it.

Are you planning to keep the Synology going, or would you also be thinking of reusing its drives in your new Unraid server? There are several advantages of going with fewer larger newer drives instead of more smaller older drives like you have in that old server.

You don't need to disable DMZ, you just need to make sure nothing is in the DMZ. Don't put anything in the DMZ, your Unraid server or anything else. You forward only the appropriate ports to your Unraid server as needed for your applications. No DMZ needed for any of this.

Yes, a new post in this same thread. The reason for that advice is because old posts that have been edited don't show up as new posts, and those of us that often browse for things to help with will likely not see those edits since there is nothing new to follow up on. When asking for Diagnostics, I almost always say: "Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post." I say NEXT so people won't put it in a previous post, and I say ZIP because many people apparently have their browser configured to automatically open ZIP files, and they seem unaware that they have even downloaded a ZIP. They then proceed to attach all of the individual files in the diagnostics separately. I always just delete all those and make them do it over. Too much trouble to download them separately, and they are much easier to work with in the folders within the ZIP.

Not sure I understand the question. Keep all discussion related to these problems on this thread.

The disk is disabled as well as unmountable. Unfortunately you rebooted before getting the diagnostics so syslog doesn't show us what might have happened. SMART for the disk looks OK to me but since you are already running the extended SMART test let it complete and post new diagnostics. You will have to repair the filesystem as well as rebuild. Post back with the new diagnostics after extended SMART test completes.

Post your docker run as explained at the first link in the docker FAQ pinned near the top of the Docker Engine subforum.

That's why I thought maybe you didn't go through with the New Config without the disk. Those seem like it is trying to mount the cleared disk with it still assigned, and of course, it has no filesystem to mount.

Since you are going to New Config anyway you can just cancel the parity check then do a correcting parity check after the New Config.