JonathanM

ROTFL. Autocorrect?

Depends on your definition of browse. If you mean list the file names, yes.

I think I remember something like that happening, where the first parity check after a "successful" parity build ends up with thousands of errors. That could be nasty if a user happens to add a larger data disk in that state before parity is truly correct.

The fuse filesystem that makes up the user shares keeps its own inodes list AFAIK. Hardlinking only works inside the same filesystem, each disk has its own individual filesystem, and the user share fuse is another filesystem all its own.

Same as any graphical file explore for the past 20+ years. Double click on the folder, which reveals the contents of that folder. Repeat until you reach the files that did not copy successfully.

Drill down to the folder in question, the full path will be at the top of the window.

What is the full path name that krusader sees for the files in question? If you would rather not post the real path, substitute xxx for letters, 1111 for numbers, and leave all symbols as is. Don't shortcut, if the the folder is ./thisismyprivatestuff/etc make sure you don't skip any letters ./xxxxxxxxxxxxxxxxxxxx/xxx for example.

This one works well. https://hub.docker.com/r/hexparrot/mineos/

Isn't docker compose command line?

It is supported. It's part of the nerd pack plugin.

Might I suggest that those of you requesting games that ich777 doesn't currently own a license for should contribute by either obtaining a license or working together with other requesters to obtain a license for ich777? You are asking for a significant amount of work to be done on your behalf, the least you can do is make the work easier to accomplish and support.

What Benson said. See if there is a BIOS option to continue on error, instead of halting on error. The beeps may be informational only, not a show stopper.

Do they give a specific file and time period?

Click on the shares tab in the webGUI, click on the compute link in the line with appdata to see what disks are currently in use, click on appdata itself to see settings.

A very likely outcome to this would be that you would actually ERASE all your appdata. DO NOT DO ANY OF WHAT YOU ARE PROPOSING. /mnt/user/appdata is already on one of your disks, which one depends on the appdata share settings. If you want to learn about how unraid works behind the scenes, then afterwards you can mess around with this type of stuff.

Since each disk in unraid has an independent file system, you can choose BTRFS or XFS freely, even have different file systems on the same array. The fuse overlay isn't a file system, more like a hard link type setup. That's why it can be advantageous to address the disks individually for some situations. Many of us that have used unraid for many years choose to manage our files on a disk by disk basis, and use the /mnt/user tree as a convenient way to present the files to users and applications, all while maintaining control at the disk level. It's a very powerful system that allows multiple different sized disks with seamless expansion, not something that ZFS or other pure RAID systems can offer. Different philosophies, different strengths. Name another setup that when faced with multiple member failures beyond the RAID recovery threshold still allows easy data recovery from intact remaining disks. For example, with Unraid, no matter how many disks die, you only lose data on the dead disks.

You misunderstand parity protection as it applies to single disks. The mdX devices are protected by parity, so there is no difference in protection whether you use /mnt/user/appdata or /mnt/diskX/appdata. In either case a single disk failure is still emulated by parity. The only thing you are losing is the ability to automatically spread the ../appdata folder across multiple disks and use a single point of access, /mnt/user/appdata. BTW, parity doesn't provide a resilient filesystem, only device failure protection. Each disk has a separate independent file system. The /mnt/user fuse is just the combination of all the root folder paths on each separate disk.

Since "Unraid" is a registered trademark, I don't believe you can use that word. @limetech would have the final say.

Unfortunately performance isn't the only metric. General compatibility and ease of implementation with various advanced functions like hardware pass through and such also tip on intel's side. I would say that you can eventually see progress and things get worked out, like the Ryzen and Threadripper issues, but it seems like by the time everything settles out and works well, the products are stale, and it's time to start the cycle of incompatibility and fixes again. "Maybe next time it will be different" isn't a comfortable way to approach tech. I'd rather spend the extra $/performance on a platform I don't have as much support time invested. If you love tinkering with it, fine. I'd rather buy it and stay hands off as much as possible.

Honestly, the answer is yes, looks fairly normal, but I'd consider replacing anyway. Speed is probably the third criteria I'd use for considering which drive to upgrade. First would be SMART status, second, raw capacity, third, speed. If you don't need more space, don't bother replacing anything until it shows signs of failure. However, if you want to pro-actively replace stuff, get another 8TB drive, replace the slowest 2TB outright with a rebuild, copy the contents of the other slow 2TB drives to it, and remove them. File system type plays into this as well, if the 2TB drives are ReiserFS the strategy changes.

Try a different USB - SATA adapter. I'm betting the one you are trying to use doesn't support a drive that big, or is otherwise not functioning.

One of my test servers has 2GB of RAM, and I was able to successfully update from the webUI, but not if the array was already started. I suspect it's right on the edge, so doing the update after a fresh reboot in safe mode with the array NOT autostarted may possibly succeed. YMMV. It may also help to disable docker and VM services if they are not already disabled on a machine with that little power.

Highlight the file you want to edit, hit F4 or click the F4 Edit button.

You likely confused a few facts and came up with 1+1=3. 1. Mixing /mnt/diskX or /mnt/cache with /mnt/user paths can cause issues if you aren't careful, search "unraid user share copy bug" for a detailed explanation. 2. Writing directly to a hardware disk array member at /dev/sdX1 will invalidate parity. This would typically only happen if you followed some random internet directions for working with linux disks at the partition level. It is perfectly ok to access the mount points /mnt/diskX as long as you understand how /mnt/user paths interact with them. Just don't do it without a thorough grasp on how /mnt/user actually works.

Already available.