JonathanM

Because port mapping only applies to bridge mode, where the container shares the host's IP address. Other modes require port changes to be made in the application itself, there is no remapping because the container has total control over a unique IP instead of sharing the hosts IP.

One way is to use the dynamix file manager plugin, copy from the damaged pool to an array disk or another pool. Pick a destination that has plenty of free space.

Yes, that's what fixed it. A corrupt filesystem will keep files from being read successfully.

Move requires a write to delete the source file, so no, you can't move things from a read only volume. What you can do is COPY what you need, then deal with the issue. Files with corruption detected won't be able to be copied, so work in small batches. If the file copies without error, it should be intact.

Whatever you do, don't cancel the unbalanced run unless you are fine with it leaving the files behind on the source disk. Personally I prefer to copy and compare, then delete when I'm sure the copy is accurate when I can, moving is too final for me.

Why not just use the dynamix file manager plugin?

restart the container

Another option is to treat the VM's like bare metal machines and back them up using traditional methods. I use UrBackup, it does full image and file backup, keeps the backups up to date automatically with no user intervention needed. I have successfully restored full machines from scratch as well as recovered just a few needed files. Much more granular and flexible than vdisk image backups.

I don't know if anyone has ever tested one. Maybe buy from a vendor with a generous return policy and attempt to set up a trial of Unraid?

What is your use case for hard links? I'm not understanding what you are trying to accomplish.

That's not really a thing, each share has it's own settings that determine what the mover will or won't do. Go to the shares tab, and look at the storage column for each share in question. Also click on "calculate", it will show you where the share exists currently.

Contact support, they can look up the email address you used and see if you have a valid license. If not, yes, you can purchase a license and upgrade. I suggest you look up Spaceinvader One on youtube, he has a load of very helpful videos to get you up to speed dealing with your system.

The built in browser is only updated when a new upgrade of Unraid is released, so the chances are good that a vulnerability may be exposed with no way to immediately mitigate it. Given that it's running on the base OS, if it's exploited your entire Unraid install is vulnerable. The only reason the GUI browser was included at all was to give the local console the ability to manage Unraid. For general use, it's highly recommended to only use the built in browser to launch a VM or container that can be used as a daily driver. If the local GUI becomes unusable for any reason it would be very bad. Consider what could happen if you accidentally open a page with an exploit that allows remote access, or starts ransomware. It would have access to your whole server. Much safer to sandbox your activities with a container or VM.

If you have docker containers, the customized templates are stored on the flash drive, so those will need to be redone. Many times they will run with their last config, but they won't update or edit properly.

It's the command that tells the drive's firmware to pretty much start over with data allocation, it can help if there are cells that couldn't be optimized for some reason or another.

Different motherboards have different settings exposed, I don't know what options you have available. Exhaustively go through each CMOS item and subitem, sometimes advanced settings are hidden under sub menus.

If it is, then it's specific to your setup, so very difficult for Unraid to fix. So it restarts with no containers or VM's while in safe mode?

Possibly not bad, it may be ok after a full blkdiscard.

I suspected that was the case, but since you didn't volunteer your local IP addresses, all I could do is point you there. That's the question I asked, and you just confirmed they weren't on the same network segment.

And you've tried all the different USB port modes in BIOS?

Try disabling fast boot.

Maybe it would help to chart out your IP schema, and which can and can't ping each other. Router IP (most likely the gateway address) Surface IP Workstation IP Unraid IP At the command prompt of the Surface, workstation and Unraid, check which ones can and can't be reached. You should end up with a list of which devices can successfully reach each IP. e.g. from the command prompt of the Surface - pings router, workstation and Unraid OK from the command prompt of the Workstation - pings router, Surface, but not Unraid from the command prompt of Unraid - pings router, Surface, but not Workstation or something like that.

If the main PC is using windows of some flavor, is the network connection set as private or public?

Same subnet? Can you ping the router IP from the PC and Unraid's console?

Can you ping the IP from the PC?