MowMdown

/dev/shm is limited to 50% of your max memory, it does not take up 50% of your system memory. Edit: I am assuming you thought that if you don't use it, that 50% of your RAM is going to sit empty. Otherwise yes you can resize it or create a separate tmpfs and make it whatever size you want using user-scripts

All I can say for now is if you're using br0 networking for containers you need to enable the host access setting in docker settings: (set to enabled) It will flat out not be able to reach other containers on bridge/host network modes if you don't. Honestly, you really shouldn't be using br0. You would be better off just keeping it on bridge network and moving the unraid webgui ports off of 80 and 443 to something else like 81 and 4430.

Your system has not ran mover yet, the data will sit on your primary storage (when a secondary storage is set) until mover is ran and then any files not in use, will be moved to your secondary storage location (or from the secondary storage location to the primary depending on which direction you set mover to opreate)

The best advice I can give is (what I personally do) is use /mnt/user/... for everything and then just properly assign my shares to the correct storage locations and also enabling "Permit Exclusive Shares: Yes" With this setting enabled you will be able to use /mnt/user/... and bypass the FUSE system for any shares that reside on a single disk or pool. I would say there are limited use cases where you need to specify the actual disk or pool when using paths such as /mnt/disk1/... or /.mnt/cache/... when using exclusive shares.

next time you have consistent writes to the array, open the console/terminal and type in top look at the wa indicator and see what it says, the higher the value the slower the system will feel like. If it's a low number then there could be other issues. (not sure what though)

What files are being wrote to the wrong cache pool? You may need to review each one of your docker container templates to make sure all the paths you're using are pointed to the correct locations. For example if you have a direct disk/pool mount it will bypass FUSE and write directly to the location specified.

probably the cache drive one since that is set to cache only and you probably have your docker.img configured to be wrote to /mnt/user/system/docker/... which would have re-created it on your cache drive after you set the share to use cache only. docker.img can almost always be deleted and re-created with minimal downtime. You often just have to re-install the containers as the appdata is store separately.

Well first take a look at what's physically on disk1. Confirm it's not just an empty "system" folder. After that set mover logging to YES -> Settings > Scheduler > Mover Logging: Yes (hit apply) Stop the docker service entirely -> Settings > Docker> Enable: No (hit apply) Then run mover again, and post new diagnostics after it's complete. We'll go from there.

Because you still have system share on disk1 system shareUseCache="only" # Share exists on cache, disk1

Unraid has no control over the linux kernel. The linux kernel is what decides what GPUs are supported or not. If you're not aware limetech only ships unraid with the LTS kernel which stands for "Long Term Support" Unraid does not use bleeding edge linux kernels. If you want to use bleeding edge hardware you're going to have to wait for the LTS kernel with the hardware support. LTS kernels are not fast to release. Intel battlemage GPUs will not work on kernel 6.12 as battlemage support wasn't added in until 6.14. 6.14 is not an LTS kernel. If you need more info on LTS kernel releases: https://www.kernel.org/category/releases.html

You may want to run it for an extended period of time, it might take 10-15-20 passes to detect errors.

Have you ran a btrfs scrub? there's FS corruption detected. Edit: You're also having read errors. Might be more severe than I thought.

Not really. btrfs has a lot of similar features to zfs like snapshots and compression. I will say there are more GUI tools available to manage zfs snapshots and datasets. These tools are however 3rd party and could be deprecated at any time if the community devices to stop keeping them up to date. (zfs master is kinda dying off right now anyways) I would argue that you 100% should mirror them unless you keep regular full backups of the entire pool contents. I prefer to minimize my downtime by doing a mirror but that's a personal preference. Not really. There's not really a right or wrong answer.

Once you've enabled that setting, you should see this on the share setting page: If this says "No" you still may have files on other disks or pools, you will need to remedy that first. Also, on the share page itself you will see little triangles next to the pool name the share is located: In this example, the bottom share is cache exclusive the top and middle ones are not.

This wont work, you cannot use Krusader to move docker container files because you will need to stop the entire docker service to move them. Instead you will need to use the built-in file manager by using the buttons at the bottom of the screen when browsing your shares/disks. Alternatively you can use mc from a terminal/console screen/window. Just be aware if you use this you need to leave the window open for it to remain active otherwise closing it will stop the operation. (this only applies to using the console/terminal window from the unraid webgui) shown here -> Edit: Also closing an SSH session will terminate the active mc operation.

That's an outdated practice using direct disk paths now. Instead what you should do is go into the global share settings and set "Permit Exclusive Shares: Yes" this will achieve the samething but allow you to use /mnt/user/... instead of /mnt/pool_name/... while keeping the performance of the direct disk operation.

Honestly with how strict you're trying to micromanage your share and subfolders, you're better off choosing the "Manual: Do not split directories" and then creating the directories exactly where you want them. Otherwise with a Top level split that you have selected, you're going to end up with a Movie share on each disk and then also potentially having one of each subcategory on each disk if the fill allocation changes as you hit the highwater mark on each disk. Basically by the time highwater has cycled through each disk (lets say each disk is 50%) the 2nd round of highwater could leave you with the "Movie" share on each disk and having all of these sub folders on every disk as well: (this is kind of an extreme example but this is what it could look like at the end) Movie (disk1,2,3,4): 720p Horror (disk1,2) movie1 (disk1) movie2 (disk1) movie3 (disk2) movie4 (disk2) 720p SciFi (disk2,3) movie4 (disk2) movie5 (disk2) movie6 (disk2) movie7 (disk3) 1080p SciFi (disk3,4) movie8 (disk3) movie9 (disk3) movie10 (disk3) movie11 (disk4) 1080p Other (disk1,2,3) movie12 (disk1) movie13 (disk1) movie14 (disk2) movie15 (disk3) 2160p Comedy (disk3,4) movie16 (disk3) movie17 (disk3) movie18 (disk4) movie19 (disk4) 2160p Action (disk1,2,3,4) movie20 (disk1) movie21 (disk2) movie22 (disk3) movie23 (disk4)

Well did you open any ports in your router so you can connect to your services? You'll need to open ports or your firewall will not allow external connections. Are you using br0 network mode (custom IPs) for your containers without having enabled the "Host access to custom networks" in the docker settings? Are you on CGNAT from your ISP? If yes, you won't be able to access your stuff unless they assign you a static IP.

Battlemage GPUs aren't fully supported in the current 6.12 unraid kernel. You will need to wait until unraid jumps to the next LTS kernel. Battlemage GPUs got full support in the 6.14 linux kernel. Unraid uses LTS kernels which are still currently on 6.12.XX

No I mean docker network create network_name where network_name is something you created like proxynet or something and also enabled this setting withing docker settings In order for your proxy to understand what "plex" is in regards to set $upstream_app plex; in your proxy config, you would need both your reverse proxy and plex within the same custom docker network. If you're using vlans or br0 bridged networks, you've probably gotta sort those out, I don't use any so I can't advise on those.

You’re not going to have bitrot protection if you don’t use a proper zfs zpool using unraids pools. Zfs disks in the main unraid array will not provide you any of zfs’s benefits you seek. But yes the unraid array can use a mix of filesystems as they are independent disks from one another. Most people use XFS in their unraid array as btrfs is (in my opinion) not great and zfs has no purpose as a single disk zpool which is your only option when used in the unraid array.

/mnt/user0 is almost the same thing as /mnt/user with the exception that it does not contain any pooled devices so it’s only the array devices. You can just ignore /mnt/user0, however if you delete files from /mnt/user0 they will be deleted from the system. They are not duplicate files. If anything shows up under /mnt/user0 it’s been moved to your array disks (disk1, disk2, etc)

did you put your plex container on the same custom docker network as your reverse proxy?

yes your sata power cables and data cables should be checked/replaced. disks are assumed to be dropping from the system due to potentially bad cables.

I do the same method for plex. I have it streamed through SWAG (linuxserver nginx reverse proxy container) and I don't expose any ports except for 443. I've even disabled the remote access within plex's settings. I then had to add both http://plex.domain.com,https://plex.domain.com to the discovery URLs for plex to recognize and serve over the internet. I have not noticed any issues like you're describing. Who is your domain and DNS host, I use cloudflare but I do not proxy it through their dns proxy. I also use adguard on my local network to do a DNS re-write to forward any internal dns requests that hit my domain to my local IP so the lookups don't have to go out to the internet. Here is the plex subdomain config I use