JonathanM

No. Yes. Maybe, depends. Not enough information.

It would appear your VM was infiltrated, if it were me I'd delete that vdisk and start over. Unraid itself is a little more resilient, but since they were in your VM, who knows where else in your network they poked around. Each device on your network needs to be examined and possibly reset, including your router.

That command doesn't give "errors", it tells you a list of files which don't match and would be transferred if you didn't have the n in the narcv

Sounds like you may have the source and / or destination paths wrong. Try it on a pair of folders that you know for a fact are identical.

That's not a permission issue, it's a container path inconsistency. You haven't posted the container config for your downloader, so no way to tell you what field to change, but if you can wrap your head around the issue it's easy to fix for yourself. https://forums.unraid.net/topic/57181-docker-faq/?tab=comments#comment-566086

If you are replacing the drive, why not just do the normal drive replacement procedure? For parity to remain valid, the bits on the drive you are removing must be exactly the same as the bits on the replacement. So, either both the old and new drives must be all zeroes, or the new drive rebuilt from parity to match the old drive, or rebuild parity based on the new drive content. I suppose you could pause the zeroing process, I've never tried.

There is a sticky post in this general forum. Pretty hard to miss.

You can do that already, but it's not a button, you have to put the tag in yourself manually. Like that.

That's normal with or without cache dirs, as windows will attempt to open files on the drive for thumbnail or content preview. That's why I said... Opening the drive letter in windows explorer is a much different thing than listing the directory in a command prompt. Cache dirs only works for the names of the files, not the content.

Settings, Global Share Settings, Cache Settings, Min Free Space.

What is the alternative? I'm not understanding the scenario and what you want to change.

One solution. https://www.monoprice.com/product?p_id=34898

Asus will allow you to change to whatever subnet you want. Easiest thing would be to make a note of any customizations on the current router, and duplicate the setup on the new router, including the dhcp range. Note, current dhcp dynamic reservations will obviously change, however if you leave all the dhcp devices connected, they will likely be able to get the same reservation they had previously as there should be no conflicts when they ask for the same IP. Worst case you would need to disconnect all the network cords to force a renewal.

Here is a port list. https://support.plex.tv/articles/201543147-what-network-ports-do-i-need-to-allow-through-my-firewall/ It's much easier to allow plex to manage them in host mode than to add them all manually.

Please don't hijack someone else's thread. Start you own thread and post diagnostics. Most likely cause would be copies of the files already in place, or free space issues.

If the VM option is still showing on the GUI menu, it won't move the files because they are in use. Make sure you disabled the VM service in settings, when you get it right the VMS text will no longer show in the GUI.

It's also faster. Krusader and Dolphin both seem to be slower copying. A properly configured network is probably faster than a locally connected USB as well. USB data transfer can be very temperamental, I'd recommend connecting to a SATA or eSATA port for mass data transfer.

Please don't take offense at this, but you probably will anyway. If the only or overriding reason you are running this is to be directly compensated in some way, don't run it.

Quickest way. If the new blank disks are tested and known good, then just build parity on everything at once. If the new disks are unknown condition fresh from shipping, then building parity first before adding the new disks will force unraid to do a full capacity write to the new disks when they are added, possibly exposing any manufacturing defects or shipping damage before they participate in protecting the rest of your data. Either way works.

Some subset of downloads will work fine. Some downloads will be crippled. YMMV

Not at all. I am currently running debian, mint, pfsense (freebsd based), windows7, windows8, and a couple other distros. Not all at the same time, I only have enough ram for 4 simultaneously, pfsense runs constantly, along with mint and windows7. I boot up the others 1 at a time as I need. VM's are hardware specific, and the specifics of getting any particular distro running are particular to the motherboard and other hardware in question.

That's rather normal when ReiserFS is trying to recover from a bad shutdown. I remember waiting over an hour on a 2TB drive, I can't even imagine how bad ReiserFS would be on an 8TB. When getting data off a ReiserFS drive, COPY, never move. Moving causes the filesystem to attempt to delete files on the source, which is painfully slow and can seem to hang the box. Once everything is copied, format the drive. The format takes seconds, deleting that much data from ReiserFS could take hours. You are seeing up close and personal why it's necessary to get away from ReiserFS, it was bad enough on 2TB drives, it gets much worse the larger you go.

No. No. Nothing. If the include exclude section no longer matches what is physically installed, you will need to update it manually. If you move a disk containing a share to a slot that was previously excluded by that share, new files written to that share will no longer be written to that disk slot, instead they will be written to the disk slot that is listed in the include / exclude rules, following the other allocation rules of split level and minimum free space. If you mean the global include / exclude, strange things can happen, especially if you move a disk to a slot that is globally excluded, the files, while still on the disk, will not be visible in the user shares. I don't recommend using include / exclude unless you know what you are doing and why. The parity disk(s) are built from the new list of data disks.

You should be able to point the client at a mounted share.

At the very least, the drive you removed should be usable. DON'T put it back in the system until you are told, it could cause issues with mounting the new drive.