itimpi

That does not sound good It sounds as if those drives have had it unless you can get something done via specialist repair company. Sometimes the drives controller cards can be replaced to get at the data and there are sites that specialise in this. You have to decide whether it is worth going that route, and such a decision will probably depend on the importance of the data on the drives and whether you have good backups. What type of power adapter were you using? There have been reports of the type that have the wires moulded in being prone to shorting and causing the type of damage you mention (or even catching fire in worst cases). You can get the remaining drives back into operation by using Tools >> New Config (I suggest you use the option to retain all current assignments); return to the Main tab and unassign the burnt out drives; make any other changes (e.g. re-order drives or add new ones) and then start the array to build parity based on the new drive assignments. Unraid will recognise any drives that have previously been used by Unraid and leave their data intact.

As you only seem to have 2GB of RAM on the system I suspect that you are simply running out of RAM to hold the temporary files. Unraid releases are tending to get larger as new functionality is added, so this is not unusual on systems with only 2GB of RAM for the upgrade via the GUI to fail (maybe a warning should be added for this ). In such a case doing it the old manual way is the way to proceed.

Just stop the array, assign the new parity drive in place of the old one and restart the array to build parity onto the new drive. No point in doing a parity check as you are about to discard the current contents.

Q1: As long as you can boot Unraid you will be able to install the pre-clear plugin so that you can test those drives. You can do it via USB but that will almost certainly make it slower. Note that the preclear is not a fast process as it involves reading and writing every sector on the drive. With 10TB drives it is going to take days for each drive. There is then the question of whether the ‘preclear’ state will survive moving the drive from a USB enclosure to a SATA connection. It depends on whether the USB enclosure presents the drive to the system identically to the way a SATA connection does. In my experience most enclosure do, but not all. However as your primary purpose at this point is to stress test the drives that is not important. When you first set up the array whether a drive is pre-cleared or not makes no difference. It is only later if you try to add a new drive to an existing parity protected array that this distinction matters at all, and even then it still works but just takes longer if the preclear state is not recognised. Q2: For your Use Case using the NVME drive as the cache seems a very sensible thing to do. Note that whether ordinary file writes go via the cache is configurable at the share level so it is not uncommon for users to always write directly to the array bypassing the cache for media files and only use the cache for application/VM purposes. during your initial data transfer you definitely do NOT want to go via the cache as it would not speed the process. Also for the initial transfer if you do not mind the data being unprotected do the load without assigning the parity drive as having a parity drive significantly slows down writing to the array due to the way the system maintains parity in real time. If you DO want parity protection from the outset then enable the “turbo” write feature which speeds up writing at the expense of keeping all drives spinning. Parity can be added at any point so when to do it is up to you.

I assume that the problem disk is disk5? If so it looks as if it has dropped offline and as a result got lots of write errors (which is why it is disabled). Because it is offline there is no SMART information to give an indication of its health. i suggest that you stop the system and carefully check the cabling (SATA and power) to the drive as cabling issues are far more common than disks actually failing. If on powering back up it comes online it will still show as disabled, but you will be able to see the SMART information by clicking on the drive on the Main tab. If that shows SMART information I suggest you post new diagnostics so we can give an assessment of the drives health. If it does not come back online then the drive has really failed and you will need a replacement. While the disk is disabled Unraid will be using the combination of the other data drives plus the parity drive to ‘emulate’ the missing disk so you can still see its contents via this emulation. If you cannot see the emulated contents for any reason then let us know exactly what you are seeing so we can advise on how to fix that. To clear the disabled state you need to rebuild the contents of the ‘emulated’ drive to a physical drive and the process for doing that is documented here in the online documentation. Whether that is to a replacement drive or back to the current disk5 will depend on the assessment of the health of disk5.

WireGuard IS a VPN and is now built into Unraid ! It has the advantage that the array does not need to be started to use it.

I would think this would de a good idea as it protects you against cache failure

I think technically that is the “User Contributed Content” part of the wiki . The official documentation all has URLs that start with https://wiki.unraid.net/UnRAID_6/

In principle the owner/permissions on appdata folders and contents should be determined by the docker container. I think the folders directly under appdata always end up owned by root, but that is definitely not always true of any files/sub-folders. That is why there is a Docker Safe New Permissions script that acts like the standard New Permissions except for the fact it always leaves appdata folders and files alone.

A disk gets disabled when a write to it fails. You have to take manual corrective action to remove the disabled state which is normally to rebuild the disk either to another drive or back to itself (if you think the drive is OK). The process is documented here in the online documentation.

Unraid will only show one of them (I think the one on the lowest number disk) at the User Share level. You can now get some unexpected behaviour because if you delete/rename/move the first file at first glance the file seems to still be there. Actually you are now seeing the second copy as the first copy is no longer masking the second one.

I suspect that makes such a change a large amount of effort for Limetech and this not likely to appear any time in the near future (if at all). I would like to be proved wrong though.

That will work just fine I cannot remember if CA backup includes the super.dat file, but if it does make sure you delete it from the USB drive before booting Unraid. it is worth pointing out that you can always get a backup suitable for use with the USB Creator tool by clicking on the flash drive on the Main tab and using the backup option from there.

Hmm - I think I see - you want files to exist in two places - on the cache AND on the array? Things might get a bit messy as Unraid has a built in assumption that a file only exists either on the cache or on the array. You might start getting some unexpected behaviour if the file existed in two places. As an example deleting a file would initially appear to not work as you would be deleting the cache copy, and when that was gone the array copy (which may have different contents) would have taken its place.

As was mentioned by trurl just use your last backup but remove the super.dat file from the config folder. When you boot Unraid you will then have no drives assigned, but you can use the screenshot I mentioned to assign them exactly as before. Tick the “parity” is valid box and then when you start the array everything should come up as before as Unraid will recognise disks that have previously been used in Unraid and will leave their contents intact. The one thing you must NOT do is assign a data disk as a parity drive as that would destroy its contents so check your assignments carefully.

Easiest thing is to make sure you have a screenshot of the Main tab as that has all your current drive assignments. You can then recreate the array using that information if needed. it is always possible that the USB drive has just dropped offline for some reason and that rebooting may get it back. Alternatively plug it into a PC/Mac and see if you can make a copy of the config folder that holds your license key and all your Unraid settings.

It is not clear to me what the advantage the proposed “Both” option has? In fact it seems to have the disadvantage that new files start failing when there is no free space on the cache, rather than succeeding by by-passing the cache and going directly to the array as happens with the current Yes option.

I agree that might be the best thing to try at the moment :). The question asked was what SHOULD have been done (at least that is how I took it)

/mnt/diskX and /mnt/cache is where you will see all physical drives mounted. /mnt/user if where user shares are located. They can provide a logical view that can span multiple drives plus the cache. /mnt/user0 is user shares but excluding anything located on the cache. Limetech have warned this is deprecated and may be removed in the future. Q3/Q4. New Permissions is the recommended way to fix permission issues as it dose not require you to use the command line. If you know what you are doing then using the command line also works.

This is not an issue that anyone else is reporting as far as I know.

That does not take into consideration what SMART tests have been run - just the attribute values. Typically yes

It is a Linux level architectural limitation so not really fixable! This is one of the reasons that dirk shares are not enabled by default as that makes it harder for a naïve user to mic dirk and user shares in the same copy/move command. That is fine The issue only arises if y/u try and mix disk shares and user shares in the same copy/move command. Using just disk shares or just user shares is fine. You need to read up on Allocation Method, Split Level and Minimum Free Space settings for a share that are used to determine which drive Unraid will select for a new file (note that this selection does NOT take into account the size of the file you are trying to write) After selecting a drive, if it turns out these is not enough space then you will get an "out of space" failure when free space is exhausted. That by-passes the user share level so will go ahead. The exclude just applies to where new files will be placed. They will still be found for read purposes.

Not quite (I think you are probably over-thinking this ) as the recovery is simpler: 2. See if you can run file system/check repair on the emulated disk. Ideally after doing this if repair worked you stop/restart the. array and the emulated disk will now mount and you will be able to see its contents. 3 . Decide if the disk marked as disable is actually OK and the failed write was caused (commonest) by an external factor or whether you need to use a replacement disk. 4. Follow the documented procedure for rebuilding a disk (on to itself if not using a replacement). This will rebuild the contents of the emulated drive onto the physical drive. If step 2 failed then you might want to ask for advice if not sure how to proceed.

Once a disk is disabled (because a write failed) it stays in that state until action is taken to bring it back into sync with parity. The normal action is to rebuild the disk to get it back into the array in match with parity. The problem was that you almost certainly took the wrong action to regain access as the commonest cause of an 'unmountable' disk is some file system level correction that can easily be fixed by running the appropriate tool (file system check/repair) as documented here. This can be done on the "emulated" drive before attempting a rebuild. If you had not used the Format option then I would think all your data would have been recovered intact. If you have any suggestions on how the wording of the Warning dialog that pops up when you attempt to format a drive can be improved in a way that might have stopped you proceeding with it then please feel free to make them.

I am afraid that you have erased the contents of disk3. The dialog that was displayed when you tried to do a format would have told you that this was going to erase the contents of the disk happen and that parity would be updated to reflect this. i know it is a bit late now, but the correct recovery procedure would have been the one documented here in the online documentation. Did you actually start the rebuild, or have you still got the physical disk3 in the state it was when it got disabled. If so, then it may be possible to get the data off the physical drive. Do you have backups of the data if necessary?