trurl

Almost certainly flash disconnect. Be sure to boot from a USB2 port. And be sure to make a new post with your diagnostics so we will know to visit this thread again for the new information.

The archives of the OS live on the flash drive. Those are unpacked fresh at each boot into RAM, and the OS runs completely in RAM. I always like to think of it as firmware, except easier to upgrade without bricking anything. Also, the specific configuration is stored on flash so it can be reapplied at boot, and changes to the configuration are written to flash, but for the most part, the configuration is also loaded into RAM for use. @jdlancaster13, as you can see from these posts, Unraid isn't exactly "installed" onto some other disk that you boot from later. In fact, how did you expect to boot it up again since you had presumably told BIOS to boot from flash? Did you have a paid license, or were you using trial? Either way I'm not sure if you can get the license back without contacting support, even if you use the same flash drive. The most important thing for avoiding data loss in your situation is DO NOT assign any data disk to any parity slot, or it will be overwritten with parity. If in doubt, don't assign any disk to any parity slot. And, even after you get through all this and have it working again, you must always keep a current backup of the Unraid flash. You can download a zipped backup of flash from Main - Boot Device - Flash - Flash Backup.

Looks good, appdata, domains, system all on cache. Probably a good idea to delete and recreate docker.img anyway. You might even consider reducing it to 20G. That is what I usually recommend and it is usually more than enough if no application is misconfigured so it is writing into the image instead of to mapped storage. I have 17 dockers running and they are using less than half of 20G. After you recreate docker.img, the Previous Apps feature on the Apps page will reinstall your dockers exactly as they were. If you were using any custom docker network (such as with letsencrypt) you should recreate that after recreating docker.img and before reinstalling the containers.

Those settings are good. By themselves those settings won't do anything with existing files though, and even mover might not move everything. It won't move open files, which is the reason for disabling dockers and VMs. And it won't move duplicates, those have to be cleaned up manually. I will probably have split your post and my response into their own your other thread if you want to continue the discussion so this that other thread can concentrate on the OP.

post new diagnostics

USB2 port more often makes a difference, don't know if it would help here.

Might be useful to other users if you would share your solution.

Go to Settings - Docker and disable then delete docker.img. Go to Settings - VM Manager and disable. Go to Shares - User Shares, click on domains share to get to its page, then set it to cache-prefer. Go to Main - Array Operations and click Move. Wait for it to complete then post new diagnostics.

docker.img is corrupt, can't tell if you filled it up or not since it didn't mount, but the 20G you have allocated should be enough unless you have an app writing into it instead of mapped storage. I see your system share has some files on the array instead of all on cache so in addition to recreating docker.img it would be good if we could make sure it and the rest of system share is on cache. Do you actually have any VMs?

Each user share has a setting for Minimum Free. I am assuming you are writing to a cache-yes user share and not directly to the cache drive.

In my opinion, your cache is too small for much actual caching, since you will want to keep appdata, domains, system shares permanently on cache so your dockers/VMs won't have performance impacted by parity, and so they will not keep disks spinning.

You have to set Minimum Free for the user share to get a cache-yes user share to overflow to the array, otherwise it just fills up and fails. You should set Minimum Free to larger than the largest file you expect to write to the share. Unraid has no way to know how large a file will become when it chooses a disk for it. If a disk has less than Minimum, it will choose another.

Something not working about your network obviously. Have you tried rebooting server, router, switches?

You still have no /mnt/user0 which would be expected if cache were participating in user shares. Try editing config/shares.cfg on flash drive. Change this shareCacheEnabled="no" to this shareCacheEnabled="yes" You might be able to make this edit from command line or in mc with the server still running and then just stop and start the array to get it to take effect.

appdata, domains, system share will typically be cache-prefer so docker/VMs will not have performance impacted by parity, and so they won't keep disks spinning. Have you tried setting up dockers or VMs yet?

Instead of syslog, we much prefer the complete Diagnostics zip, which includes syslog, SMART for all attached disks, and a lot more information about your hardware and configuration. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

I don't see it on yours either. Not sure how yours got set to no or how to change it to yes except maybe editing the file on flash and rebooting.

Cache-Prefer means try to keep the files on cache. Cache-Yes means move them to the array.

Looks like dual ethernet ports. Are you using both? Have you tried each alone?

Lots of this in syslog: Sep 12 12:41:37 unraid kernel: traps: node[18277] trap invalid opcode ip:561baad9070f sp:7fff2093b428 error:0 in node[561baad8c000+77b000] Sep 12 12:41:39 unraid kernel: traps: node[18343] trap invalid opcode ip:555bf6e6370f sp:7ffdf4287d78 error:0 in node[555bf6e5f000+77b000] Sep 12 12:41:40 unraid kernel: traps: node[18368] trap invalid opcode ip:559dd34a670f sp:7ffcb4b7c288 error:0 in node[559dd34a2000+77b000] Sep 12 12:41:43 unraid kernel: traps: node[18431] trap invalid opcode ip:55c31874e70f sp:7ffd845efdf8 error:0 in node[55c31874a000+77b000] Have you done memtest lately?

What is the exact model of your motherboard?

In those, config/shares.cfg has shareCacheEnabled="no" That doesn't seem to be the usual setting in other diagnostics I have looked at. I don't see where to change that in the beta I'm running but that may just be a bug due to the introduction of multiple pools. Maybe we can find it in your version. Go to Main - Array Operation and Stop the array. Then get 2 screenshots from Settings and post them, Disk Settings and Global Share Settings.

Parity is updated realtime. Any time a disk in the parity array is written, parity is calculated and updated. There are 2 different methods for updating parity and these have tradeoffs, but both are slower than writing without parity. See here for more details:

Unmountable, possibly unrelated to the beta. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.