itimpi

Looking at those diagnostics it looks as if the ‘emulated’ disk1 is mounting fine. You might want to browse the emulated disk to see if the data looks like what you expect as the rebuild process simply makes the physical disk match the emulated one. The process for rebuilding a disk onto itself is described here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI. if the emulated disk does NOT look like you expect then using the data from the physical disk instead can sometimes be a better option, but I suspect not in your case.

With the main array you have specific drives as parity drives and the Unraid specific version of parity handling operates. With multi-drive pools the BTRFS format is used and this supports a variety of its implementation of RAID. Instead of separate parity you get redundancy by more than one copy of any data being stored. The pools tend to be higher performance for given drives than the main array. You can have multiple pools and many people have pools optimised for different Use Cases. there is a roadmap item for Unraid to support multiple ‘main’ arrays but I would expect this to be some way off.

Why did you unassigned the drive? That might make Unraid clear the drive so it again shows as unmountable.

Cannot see what initiated the shutdown. I am afraid it looks like you are going to have to do it the hard way and try disabling/enabling plugins until you find the culprit. If investigating which plugin caused the problem it is worth knowing that if you rename any of the .plg files in the config folder to have a different file extension and then reboot that plugin will not load. Naming it back and rebooting will enable it again.

The diagnostics show no obvious errors, but since the array has not been started we cannot tell if ‘disk1’ is being correctly emulated. Since it takes more than CRC errors to make the data on a drive inaccessible I expect there is more we need to know before suggesting the best course of action. I would suggest posting new diagnostics with the array started. Do you have a spare drive you can rebuild to? It is always best if possible to keep the contents of a disabled drive intact if possible until a rebuild has successfully completed as that gives a fallback option for data recovery if the rebuild fails in any way.

As was mentioned any time you add a new drive then it will show as unmountable until you have formatted to creat an empty file system on the drive. Unraid will be offering the option to format ‘unmountable’ drives, but make sure it is only the drive you expect as you do not want to accidentally format any other drive.

If it boots in Safe Mode then that means that the Shutdown is being initiated by a plugin you have installed. It will be a process of elimination to work out which one. You should also set up the syslog server to get some log information that survives a reboot as that could also give a clue.

You should attach the complete diagnostics zip file. It is highly likely that anyone trying to diagnose your issue will want to look at other parts of the diagnostics -not just s few selected log files.

You might want to check what you have for the SMB Security setting under Settings->Unassigned Devices.

If you format the drive you will lose all its contents. Handling of unmountable drives is covered here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI. You are likely to get informed feedback if you post your system’s diagnostics zip file.

Since User Shares are equivalent to the top level folders on each drive the only way I could see you ending up with a User Share of that name was if you copied somehow created a top level folder with that name. That was one reason for asking for the diagnostics to confirm if this is what happened.

If you delete the docker image file then you can use Apps->Previous Apps to reinstall containers with their settings intact.

One thing to be aware of is that cables are often not interchangeable between different modular PSU, and if you use an incompatible cables you can damage the electronics on a disk drive.

& Always include the whole zip as it is often not clear in advance which bits will include the key information for diagnosing a particular problem.

The problem is always that NerdPack (and DevPack) can potentially overwrite standard Unraid installed components and it is a big job to identify for any particular Unraid release any that might cause problems. It is sometimes only when end-users report one of the installed packages causing a problem that it is realised that a particular component/package needs updating for that particular Unraid release.

You are likely to get better informed feedback if you post your system's diagnostics zip file so we can see exactly what is going on as something else is needed to explain your symptoms. BTW: What release of Unraid are you actually running - 6.10.3 is the latest (stable) release.

As a persistent storage location that survives a reboot. You can store them on /boot, but not set the execute bit. You can add an entry to the /boot/config/go file to move them to a suitable runtime location and set the execute bit. Alternatively you can precede the script invocation with the bash command so it reads bash path-to-script as in that case it is not necessary to have the execute bit set on the script file.

You need to disable spindown while running that type of test as otherwise the spindown terminates the test.- maybe that was the issue?

You might want to check that the SMB security setting under Settings->Unassigned Devices is not now set to No when you probably want the (new) Public option.

No idea. If you can boot from it I would expect it to be readable in a PC/Mac but you said this was not the case. Never before heard of being able to boot from it when it cannot be read in another machine as it is a standard FAT32 format which is nothing special.

This is a known issue with Samsung SSDs. I believe that the 84C message is spurious, but what actually triggers it I have no idea.

Not sure what you mean? The ‘root’ user has never been permitted to have private or secure access to network shares - and accessing a Public share makes the username irrelevant.

An upgrade is one time that quite a lot of data of written to the flash drive. in one go If this 'breaks' the flash drive so it cannot even be seen in windows then that suggests that failure might have been imminent even without the upgrade.

I have successfully used UFS Explorer to recover filed in the past. It is not free to recover files, but you can scan for filedswithout paying to decide if it will be worth it. I use the "UFS Explorer Standard Recovery" version which is not too expensive - if you need a feature that is only in the Pro version (e.g. encryption support) then the price is a different order of magnitude

I noticed this in the syslog in the diagnostics: Jun 23 20:42:39 Tower emhttpd: Autostart disabled (device configuration change) That suggests some recent change stopped autostart from running, but no idea what that change might be.