itimpi

If you are moving lots of small files (as if often the case for the appdata share) then mover will be slow as there is a significant overhead per file for checks that mover does before it moves a file. It can be faster to use something like Dynamix File Manager to move the shares from the cache to a specific disk,

Assuming you intend to keep the drives, then you could just use the process for reformatting a drive to create empty file systems on them.

The whole point of this technique is to update parity as you go to reflect the fact that sectors on the drive to be removed have been zeroed. That is why you can later remove the drive without affecting parity as zeroed sectors have no effect on parity ones.

I think in Finder you are looking at what is on the cache drive, whereas in the other cases you are including what is on the main array as well.

You should make sure that the Minimum Free Space value for the pool (cache) is set to be larger than the biggest file you expect to want cached and then Unraid will start by-passing the cache for any further files once it drops below this value.

That is expected - the repair process updated the emulated disk, not the physical one. It takes a rebuild to clear a disabled state. does the rmulateddisk now have a lost+found folder on it? That is where the repair process puts any files/folders for which the name cannot be found.

You might find this section of the online documentation to be of use.

You might find this section of the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page may be of use.

It is worth noting that hardware IDs can change after an update, so it is always possible that the contents of this file are no longer valid if you are passing hardware through to a VM.

Don’t quite understand what your problem is Not sure why you expect the files on disk1 to appear on cache? Perhaps you need to explain the exact problem in more detail? You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

It should not as Mover is meant to ignore any files that are open.

What you really want to determine is what path within the container is getting files written by Plex at that time, and map that to an external location. If it is not the /transcode path within the container then what is it? I also notice that the screenshot does not show the mapping for the plex config folder - where is that mapped to? In terms is where to map a location for temporary files I would think that a pool is better than the array for performance reasons, and if you have lots of spare ram you might want to consider a RAM based location.

It may be because you have not mapped the /transcode folder within the Plex container to a location external to the docker image so any temporary file in /transcode are written inside the image.

Jumbo frames can cause more trouble than they are worth for only a small performance gain (if any). I would leave them set to current value. They are something that sounds much better in theory than has proved to actually be the case.

Unassigning the drive would have exactly the same effect as physically removing it. In both cases the drive will be emulated using the other drives plus parity.

Unraid can use SSD in PCIe slots as I have one in my server that supports a SATA m2 SSD and a NVME SSD. Whether that card will work on your hardware I have no idea, but no obvious reason why it should not.

You could have but no point as a format is MUCH quicker than a rebuild, and it would still need to be formatted afterwards anyway as a rebuild does not clear an unmountable status.

From my reading of this thread it is not clear there ever really was a problem, or if you had just never got around to formatting the drive after adding it to Unraid (as new drives always show as unmountable until they are formatted from within Unraid).

Have you checked for a folder called ‘appdata’ even if it is empty? If it is empty then you can simply delete it.

Have you confirmed that a clean install boots OK?

Have you made sure that there is no top level folder corresponding to the share name on any pool or array drive that is not the pool configured as primary storage as this will stop the Exclusive mode from being available?

these syslog server settings only set up the server to receive syslog entries from elsewhere. If you want entries from this server you either use the Mirror to Flash option (best and easiest) or put the IP address of this server into the Remote syslog server field.

This is a known issue with FireFox. Not sure if it is understood why FireFox has this issue as it does not seem to happen with other browsers.

It will not affect it at all. Unraid does not move data between array drives by itself.

Looking at the syslog in those diagnostics I see this: Jun 17 22:18:50 T2 emhttpd: shcmd (2956): /usr/local/sbin/mover &> /dev/null & Jun 17 22:18:50 T2 kernel: shfs[29898]: segfault at 0 ip 000055d7967cb59c sp 0000151246774810 error 4 in shfs[55d7967c9000+c000] Jun 17 22:18:50 T2 kernel: Code: 48 8b 45 f0 c9 c3 55 48 89 e5 48 83 ec 20 48 89 7d e8 48 89 75 e0 c7 45 fc 00 00 00 00 8b 45 fc 48 63 d0 48 8b 45 e0 48 01 d0 <0f> b6 00 3c 2f 74 4d 8b 05 67 dd 00 00 85 c0 78 39 e8 9e da ff ff which indicates that the shfs process used to support User Shares immediately crashed when mover started - no idea why. The good news is that restarting the server will get all your shares back as they were. You could manually move the files from the drive on the array on to the pool to bypass mover if needed.