JonathanM

For some, me for one, we use cache : no with files staying on the cache on purpose. Cache : No means new files added to the share go directly to the array, and files placed on the cache manually for high speed access in the share will stay on the cache without being disturbed by the mover. So, in my opinion, it's not a problem at all, but a needed feature.

Very unlikely to happen.

Bridge works fine if all the ports are set properly and your devices know the correct hostname to connect to for adoption. @jademonkee hit all the major points. I'm using bridge and new out of the box AP's find the controller just fine, and as long as the override is set in the controller options everything continues to work. I have 5 AP's on the local LAN and 30+ managed over the internet. My set inform points to a FQDN which forwards in to the container without issue.

Yeah, people don't seem to realize that when you are running a VM, all the jobs normally done by the motherboard are now handled in software. So, the more resources you give the host, the faster the virtual motherboard can run. It's a balancing act, but generally giving the VM the bare minimum needed will result in a faster running machine. Anything you allocate to the VM is locked away and unusable by the host.

Parity is NOT backup, only high availability for drive failure. Plenty of ways to lose data that don't involve outright drive failure, so you must keep backups of any important data. Part of your statement makes me think you are keeping a copy for a backup, but then you sort of imply that after a parity sync keeping backups is less important.

It emulates a physical keyboard, mouse and monitor. Whatever comes up on a monitor connected locally is what you will see with a pikvm. It doesn't change any capabilities of the connected system.

Parity alone doesn't protect anything. Parity plus all the remaining good disks emulate the failed drives. There is NO readable data on the parity disks. https://wiki.unraid.net/Parity

Technically it can be used on an emulated drive, but there is no benefit and significant unprotected time penalty to zeroing an emulated drive, as it would be quicker to either rebuild to a new drive if there is needed data on the emulated drive or rebuilding parity if there is no need to save the emulated slot data. Your first priority with a failed drive should be to get back to a protected state ASAP.

Depending on the drive model you may need to swap a chip from one board to the other to get a good read.

But you have /mnt/user/Downloads/Done/tv/ in your screenshot. The whole path must match on both sides.

What is the mapping for /data on your torrent or usenet application?

Close, but not correct. You have to write zeros to the entire capacity of the drive, which is WAY more time consuming. It's faster to rebuild parity.

Did you put your original license key file in the config folder on the new USB?

So, if you don't use macvlan, does it still crash?

Since the message is gone it should be fine.

Remove both cache devices from pool, start array to force Unraid to forget them, stop array and assign both as they were, the all existing... message should go away.

Root should always have a strong password.

Try reducing to 8096. Unraid needs resources to emulate the hardware for the VM.

How much RAM did you assign to the VM?

If you select the option stating parity is already valid, then nothing will be erased, and a parity check will be started.

No, only the disk in the parity slot. The screen you just posted is different than what you had in your previous post, is it current?

https://wiki.unraid.net/Manual/Storage_Management#Adding_disks Read through that section and see if that answers your questions.

Assign the disks as they were, assuming you haven't changed any disks since.

Just don't mix /mnt/user paths with /mnt/diskX or /mnt/<poolname> paths when manipulating files manually. Typically I only use /mnt/user paths to consume media or files, and disk paths to manage stuff in the background, but less technical users are encouraged NOT to directly access the disks, just use the user shares and the accompanying settings to allow Unraid to manage the initial and final file locations. Much work has gone into removing the need to directly use disk paths for almost any scenario. One of the ways I manually manipulate the system is to use the /mnt/user/domains stock location with cache : only settings, which means that when I use the wizard to create a VM, it's initially created on the assigned cache pool. However, I can manually move the VM subfolder for VM's I don't use very often from /mnt/cache/domains/NewVM to /mnt/disk1/domains/NewVM and everything still works without changing any VM path definitions. All my VM's show up in /mnt/user/domains, and I control which ones take up fast expensive SSD space, and which are relegated to slow cheap array space. cache : yes and cache : prefer both tell the mover to do something, cache : no and cache : only tell the mover to ignore the share.