JonathanM

If your unraid box can handle VM's, try replicating that same TimeMachine server in a VM and see how it performs.

Yep. Barcodebuddy is an addon specifically for grocy. Doesn't do anything else, so it's not a good candidate for a separate thread.

That's for grocy, not barcodebuddy.

Incorrect. The server should still be fully functional, just sluggish for anything involving data on the array disks, and any utilization will prolong the rebuilds, sometimes drastically if something is continually writing to the parity protected array. But you can still use everything.

Remove the CPU heatsink. That large mass of metal will reek havoc if it gets loose. I've seen one total everything inside the case, no circuit board or connector was spared.

Are you positive about that? I just pulled an update for LE, and it's not in there. Regardless, I got it working just fine. Yeah, I initially had some issues, but it turns out it wasn't (directly) my reverse proxy. When you scan the 3d barcode to automatically connect the smartphone app to the server, it turns out the url it generates is http, and my server is only exposed on https. As soon as I manually changed that before proceeding, everything worked great.

Are you running the unofficial version of Unraid with nvidia drivers?

I strongly advise populating the file with the why and how this is currently working. It may work so well you totally forget about it in a few years, and something changes to make it not work, or you need to "fix" something. Even worse, it might start to feel like this file is being parsed on purpose by Unraid, or someone else needs to manage the server and thinks the file has special meaning to Unraid.

I use this option for my domains share. I like to experiment with VM's, but don't want them all on my cache, only the ones I keep running regularly. When I fire up a new VM, it defaults to the array, which has virtually unlimited space at the cost of speed. If I want to, I can leave it there, or manually move the disk image to the cache, or from the cache to the array, if I replace one of my regular VM's with a newly spun up version but want to keep the old one around. I never want mover to mess with my VM files, and I don't enjoy editing XML files just to point to a new location when I move between cache and array. I don't want newly created VM's to take up space and IO on my cache disk and possibly disrupt my always on VM's for pfsense, home automation, theater room, etc.

That's much better. Easier to implement. Just a little text file Keep.txt in both /mnt/cache/Media/RawFootage and /mnt/disk1/Media/RawFootage would work.

Since mover won't touch open files, a workaround could be to keep a token file held open in the deepest folder that you need to keep.

Just to be clear this is on the Docker tab in the GUI in the version column?

The container is downloaded from here. It is not modified in any way. https://registry.hub.docker.com/_/nextcloud On that page, who is listed as the Maintainer?

As long as you are NOT passing through a video card, and have selected VNC as the Graphics Card in the VM template, remote is the only access you have.

Something is wrong somewhere with your situation, as you should be seeing something in the VNC viewer. Have you tried a different VNC client? Sometimes the NoVNC client built in doesn't work well with some browsers or add on's. Try starting a windows VM fresh, and use a VNC client like UltraVNC Viewer or similar pointed to your unraid's IP and port 5900

https://forums.plex.tv/t/official-plex-media-server-docker-images-getting-started/172291 The official Plex docker is supported by Plex. Which is one of the reasons people choose to use one of the plex dockers actually directly supported on Unraid.

No. The Unraid GUI is totally separate from any container. If the container has a GUI, it's hosted within the container, and any tweaks must be applied specifically there.

Given your options, I prefer renaming the current "No" to something else, and the new "No" move from cache to array just like yes does. What I really think needs to happen is a total redesign of the cache pool settings. Divorce the two concepts of file placement and mover action, like this. Each user share can define both initial and final file location. New files destination (array, cache pool 1, cache pool 2, etc) Mover destination (leave in place, array, cache pool 1, cache pool 2, etc) That way when somebody updates a share allocation and runs the mover, it's obvious what should happen. Bonus points for conditional mover behaviour based on age or space thresholds. Extra special bonus points for second conditional destination, i.e. move files to cache pool 2, move files already in cache pool 2 older than 1 week to array.

If you remove them, you will break parity and need to rebuild. Keep them active in the array, and format them there. That way no lengthy parity rebuilds and running at more risk of drive failure. Just be sure never to format a drive that has data you haven't copied to another drive already.

Is all your switch and router gear on UPS? Hard to communicate when the network goes down.

If you select cache:no then new files will write to the array, but mover won't touch existing files on the cache. Read the descriptions on the help text with those settings. You want cache:yes to clear those files off the cache drive.

I have no solid test to confirm or deny my hunch, but this feels like a RAM or network issue, and I'm not sure on which end of the wire, client or server. Can you retry your tests with a totally different client machine and possibly different network connection? I'd be curious if for example a laptop connected wirelessly to the server behaved in exactly the same manner.

Screenshots? Same in safe mode? Do you have the docker folders plugin installed?

I can pretty much guarantee they are going to say use Windows, we don't support 3rd party software monitoring solutions. (apcupsd) I suggest to try using NUT instead of apcupsd and see if that works any better.