JonathanM

If the inside is much warmer, you need better ventilation.

Two schools of thought, which you choose depends on you. First, traditionally multiple shares are created, as many as make sense to you, for example, tvshows, movies, pictures, music, documents, downloads, etc. You can assign array disks or pools to contain portions of those shares, assign different user access permissions, as granular as you want. Second, create just one media share that has subfolders for different types of content as well as a subfolder structure for downloads of that content. The advantage (the only advantage IMHO) is that you can optionally keep seeding torrents of content without duplicating the storage needs. If you don't use torrents extensively, or are ok with duplicating files that you wish to seed, I definitely recommend the traditional way. Performance will be similar if not identical with either option. It's just a question of granularity of organization and access control.

Go to the support link of each one and make a choice based on issues and responses.

It's not so much how many, but which ones specifically, and what paths are being written to by the apps inside the containers. The app paths aren't something that is viewable in Unraid, you must look at the app's internal configurations and verify that any path storing data that needs to be persistent is mapped to a spot on the array or appdata. The mappings are easily viewable using the Unraid GUI, but the internal app paths to compare them to aren't. All that said, your screenshot doesn't have anything that jumps out at me as bad, you just have some hefty containers. I'd bump up to 30GB and keep an eye on things, if the sizes stay relatively the same over several weeks you are good. Every time a container is updated, the newly installed parts are added to the image, then the newly unused parts are removed. It's the time between downloading the updates and cleaning things up that causes the warning when you are close to the size limit. Filling the image can be fatal though, so it's wise to keep a healthy margin of free space for the update process, and keep an eye on it to make sure the usage isn't creeping up over time.

I'm having a hard time thinking of a situation where an emulated drive should ever be formatted. If it's unmountable it needs a file system check. Normally an emulated drive will be indistinguishable from the drive that has been dropped because of a write error, as long as parity was completely in sync when the drive was dropped. All the normal things you can do to a physical drive can be done to the emulated drive, such as reading the existing data, writing new data, formatting it, scanning for filesystem errors, etc.

I asked a long time ago to move the format option to the individual drive pages, possibly next to the selection of format type, or even better underneath the file system check area so you have to read through the file system check area before you even get to the format button. I don't believe it's a good idea to have a universal format option on the main page. The pushback to my suggestion was that a new array would take forever to go through each drive one at a time to format. My counter was that totally new array drives are a very limited situation, and it's worth the extra time to show the new user where to maintain each disk, in the same area with smart information and file system checks. I felt like I was talking to a wall, nothing was ever acknowledged.

If your rig is in an occupied room and not left running unattended, go for it. If, however, your machine is not 100% supervised while it's running, I'd strongly suggest not doing liquid cooling. If something goes wrong, you need to be very quick to spot the issue and shut down the machine. The amount of thermal mass available to keep the CPU cool is very tiny if the pump quits or the liquid quits circulating, meaning almost instant severe overheating. Plus, slow liquid leaks are very bad for electronics, so liquid cooled rigs need regular direct observation to make sure things are always sealed tight and running well. Liquid cooling is awesome for desktop blinged out gaming rigs, not so great for servers left running constantly and largely out of sight. A big heavy heatsink with even a completely stopped fan can keep a CPU safe for long enough to notice the elevated temperatures assuming any case airflow from other fans.

Urbackup server on both machines, Urbackup client on whatever machines need to be backed up. Duplicati on client, webdav server of some flavor. I use both solutions, some clients actually use both for hyper redundancy.

What happens with the current version of Unraid? Troubleshooting such an old version probably isn't going to happen.

The VNC connection set up by Unraid really should only be used when boot level maintenance needs to be done. For everyday remote access I recommend nomachine or enable RDP. You will have a much smoother experience that way.

If you have a clear understanding of disk vs. user shares, you could temporarily enable disk shares and operate directly on the disks. Just don't use any /mnt/user paths while you are dealing directly on the disks.

Unraid isn't "most NAS". You very definitely can fill each data drive completely full, leaving no room to move data around.

I can't promise you can make it work, but if you use a partitioning and format tool like rufus to create a single bootable partition FAT32 I think some have been able to use the manual installation method successfully.

That thread has examples of 10's of different controllers. "those" tells us nothing.

Sometimes. The good thing is Unraid OS runs in RAM, so any errors tend to be show stoppers, causing crashes instead of lurking in the background. The problem is that RAM errors are impossible to predict, so there is a non-zero chance that a RAM error could corrupt data without overt symptoms.

dynamix file manager would work.

Why?

Shares are assigned the pool functionality in their config screen. You can easily set your movies tv shows and photos to go directly to the final destination until the initial load out it is done, then switch at any time.

Set emby not to autostart, and see if the video folder is still created as long as emby doesn't get started.

You forgot the important part, do any of them reference just /mnt all by itself?

Does the folder still appear if the docker service is disabled in settings?

The link you posted said the board had a "buzzer". Do you see that part on the board? Is there a "spk" or speaker header on the board near the power and led pins? You need to verify with the motherboard manufacturer what the appropriate beep responses should be.

Attach the diagnostics zip file to your next post in this thread.

Pull the board back out of the case and see if it fires up sitting on the anti-static bag that it came in. Don't connect anything except the PSU leads. Briefly connect the power on pins on the motherboard and see if it gives the "no memory" code, typically just long beeps. Turn the PSU back off, add the RAM. Power up the PSU, do the pin connect thing, and see if you get a single POST beep.

All user changes should be stored in the config folder.