itimpi

No. The point of the steps I mentioned was to see if you can successfully emulate drive2 as all the rebuild process does it make a physical drive match an emulated one.

In which case I do not think that what you want to do can be done unless it is an option at the BIOS level (which it may well be).

You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

Have you run the check filesystem against the drive yet? I would expect until you do that you will continue to have problems.

The earlier diagnostics shows that your drives were: Parity: WDC_WD40EFRX-68N32N0_WD-WCC7K2TTPE1K Disk1: WDC_WD40EFRX-68N32N0_WD-WCC7K6RETKX4 so I assume that the other drive (which was already disabled even then) was Disk2: WDC_WD40EFPX-68C6CN0_WD-WX22D83RHEP8 although it was showing as not online at the time, but was being emulated so any new writes were only being reflected in parity - not in the physical disk. Have you done a New Config yet as the last diagnostics look like might you have? If so the next steps are likely to be: Tick the Parity is Valid checkbox Start the array in Maintenance mode Stop the array unassign disk2 start the array in normal mode to get disk2 emulated post new diagnostics It is probably also worth seeing if the physical disk2 can be mounted in Unassigned Devices as that would tell us if there is a fallback position if the emulated disk has problems

Have you tried rebooting in Safe mode?

We normally want the whole zip as that stops us making continual requests for more of its contents.

Do not think this is a standard feature on any OS, let alone Unraid.

If you do it from the gui you will find that -n is pre-filled into the options field (which makes it a read-only check). You need to remove the -n to actually fix anything, and add there -L if the xfs_repair asks for it.

If it is being rebuilt then the corruption is probably in the emulated drive so the rebuilt drive will have the same issue and need repsiring.

Looks like you have corruption on disk1: Mar 8 17:47:03 Importimage kernel: XFS (md1p1): Corruption warning: Metadata has LSN (-1723008584:-1473360099) ahead of current LSN (2:2434814). Please unmount and run xfs_repair (>= v4.3) to resolve. Mar 8 17:47:03 Importimage kernel: XFS (md1p1): Metadata CRC error detected at xfs_bmbt_read_verify+0x12/0x5a [xfs], xfs_bmbt block 0x87ffd298 you should run a check filesystem on disk1, and run without -n and if it asks for it adding -L.

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

You may find this section of the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release.

You can delete the docker.img file that holds all the container binaries (and is normally in the ‘system’ share). That will remove all containers. You can delete all the working set files for containers by deleting the contents of the ‘appdata’ share (assuming you used that as the location for them which is the default).

If you disable the docker service under Settings->Docker then no containers will be started.

That look like a message from the Connect plugin.

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

You should consider posting the xml for your vm so we can see how it is configured.

Restart the array in normal mode and the drive should now mount.

You may find the linux 'file' command useful if you need to work out the type of any file in Lost+Found

OK - I can see from that log that the reason it restarted from 0 is that appears to be the saved restart position for some reason? I need to see if I can identify why that might be the case.

You need to restart to clear this.

Your syslog contains: Mar 8 12:48:02 Home root: Fix Common Problems: Error: Invalid folder disk1 contained within /mnt but you do not seem to have a disk1. This means that you have something (probably a docker container) configured to write to disk1 which will be in RAM so could gradually fill RAM up and result in the server crashing.

As before I would need diagnostics with testing mode logging enabled to see why. In my testing the sequence you mentioned worked fine after the update.

You can always make shares like 'system' not visible over the network by not setting them to be exported. If set that way then the different security options are not relevant. Those settings anyway only apply to network access and you should never have your Unraid server directly exposed to the internet so they then only apply to local LAN users. The services you intend to expose over the internet need to be individually configured for security.