trurl

Yes. Go to Main - Array Operation and click Move Now.

The next thing you need to do is set those 3 shares that appeared in your latest screenshot (those that have files on cache) to cache-yes and run mover so we can get them moved off cache. After mover finishes post another screenshot just like that one so we can make sure nothing is still on cache before we reformat.

Nothing on cache is "missing". Cache is part of the user shares, and your appdata share is on cache (where it ultimately belongs). Probably what is wrong with your plex is a corrupt database, which is in the appdata, but not missing in any way. As mentioned you might have to start over with that. We will get there.

OK that agrees with what I had seen from looking at all of your shares cfg in diagnostics. Let me address your other question before continuing.

From looking at your latest diagnostics it seems you have been working on some of these things yourself, so for example, your appdata is all on cache now. What we need to do next is get everything moved off cache so it can be reformatted. Just to make sure we don't miss anything, go to Main - Cache Devices and click on the folder icon at the far right then post a screenshot.

Personally, I would recommend not even considering adding any more disks than you currently have. If anything you should try to get to fewer larger disks. I always recommend fewer larger disks instead of more smaller disks. Larger disks are more cost effective and perform better due to increased density. Every disk you have is a point of failure so the fewer the better.

If you decide to add one more cache drive it ideally would be another SSD close to the same size as the one you already have. The total capacity of the pool would be equal to the size of the smaller of the SSDs. Other possible configurations are possible, but that is simplest and gives redundancy using default settings. If you think you might like to have a pool of more than a single cache drive, then that will restrict you to reformatting cache as btrfs. That is what many of us have for cache since it is the only choice for multiple cache pool. You can do that and add the additional SSD later. But that is getting ahead of ourselves. We need to get everything off your cache first.

It is not about space, it is about redundancy. You can setup a mirrored cache pool. Then you wouldn't get those warning yellow triangles. Whether or not it is important to you we can decide later.

Are those diagnostics from after all that?

OK, that looks good. Post a new diagnostic so we will have the latest to work from.

It should have been in the config folder of your backup, or possibly in the top folder of that backup. Do you still have the email from when you received your key?

There are 2 main ways dockers can get out of hand and fill things. This one is due to settings within the application. If the application is writing to a path that isn't mapped, that is writing into the docker image and filling it. Common mistakes are not using the same upper/lower case as in the mappings, or not using an absolute path (beginning with /), or possibly even not actually having a mapping for the path. This one is due to settings of the docker. If a host path isn't actual storage, it is in RAM possibly filling it and bringing the server down. Note that this also applies to a path to an Unassigned Device that isn't actually mounted. We can take a look at this later.

That may be true. Just thought I would mention the main advantages of the Unraid design as opposed to RAID in case you weren't completely aware of them. You can mix disks of different sizes in the array. You can easily add or replace a disk without rebuilding the entire array. Each disk is independent and can be read on any linux.

Have you actually tried to start the array?

Your are still unclear since you still haven't

Also, I noticed you have a ridiculously large number (150) of share .cfg files in your diagnostics. Many of these don't appear to be actual shares with any files. Possibly you accidentally created them at some point by writing to the root of one or more disks. Any folder at the top level is automatically a share. It would help future diagnostics if you could just delete all these extra share .cfg files from your flash. They are in config/shares on your flash drive. And, I notice you have 40G allocated to docker image. I usually recommend 20G and your are very unlikely to need even that much unless you have misconfigured applications. Have you had problems with docker image filling? Making it larger will not fix that, it will only make it take longer to fill.

Have you done a memtest? (on the boot menu)

You can begin by posting in the correct place. You posted in the section for bug reports, but you were not reporting a bug. I have closed that report and copied your post to a new thread here in the General Support forum.

Copied to General Support

Changed Status to Closed Changed Priority to Other

Why are you trying to cache so much? I always recommend NOT caching the initial data load. Cache and Mover just get in the way since cache won't have the capacity. There is no way Mover can move to the slower array as fast as you can write to the faster cache. And if you are trying to do both at once they will just be competing for the disks. Mover is intended for idle time. Many of us including me don't even bother to cache user share writes. Most of my writes are from scheduled backups or queued downloads, so I am not waiting for them to complete anyway. I only use cache for my dockers (no VMs for me), for temporary storage for DVR performance, and for copies of some frequently accessed files so my array won't have to spin for those. Unraid is linux, and linux will use free RAM for I/O buffering. All that space on the graph described as "Cached" in the legend, between "Used" and "Free" is just that I/O buffering, and completely normal.

You didn't actually mention whether or not you still had the problem after booting in SAFE mode. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

And the fact you have allocated 40G to docker image also makes me suspect you have misconfigured docker applications. I usually recommend 20G. Have you had problems with docker image filling? Making it larger will not fix it, it will just make it take longer to fill. There are 2 different ways you can get problems with misconfigured dockers: If you have an application that writes to any path that isn't mapped, it will be writing into the docker image, filling it up. Common mistakes are not using the same upper/lower case as in the mappings, or not using an absolute path (beginning with /). If you have a host path that is not actual storage, that path is in RAM. This includes any path to an Unassigned Device that isn't actually mounted.

Maybe if you had some screenshot or description of how things were before it would help clarify.

I'm not sure I understand. Is there something you are concerned about other than the fact that the drive "letters" have changed? The drive letters are not expected to stay the same from one boot to another though they often do. Only the serial numbers are used to identify the disks.