itimpi

It looks like those diagnostics were taken after rebooting the system when the problem was already present? That means we cannot see what lead up to the drive going unmountable. If you see this happening again try and get diagnostics before rebooting, or else enable the syslog server so we can get a syslog that survives a reboot. At the moment you should start following the procedure documented here for handling unmountable drives. I would suggest posting the output of the check phase before going any further.

@VolodesiHave you fixed the mapping of the plex transcode folder that was mentioned earlier? If so then we probably need to look for another container with a similar mapping issue.

Much easier would be to transfer all the settings from the trial USB to the non-trial USB once you have things setup the way you want as that would avoid the need to do a licence transfer.

The easiest way would be to go the Linux command line using the _> icon at the top right of the GUI and use ls -l /mnt/* To see what folder is there. Chances are it is being created by a bad mapping in a volume container. as an alternative you could use the ‘mc’ command to bring up Midnight Commander which is a simple file manager.

oK. Was not obvious from your first screenshot but it just looks as if you have told the router to log everything it can around possible intrusion attempts.

Cannot really say as the screenshot is cut off at the left However the moment you open a post to the internet expect to see attacks being automatically mounted against that port (within minutes typically) so in that sense it depends on the NextCloud to be defending against them. You can probably get better protection if you enforce the use of SSL or a VPN but not sure how that would work in conjunction with NextCloud.

If you never set it explicitly it was probably picking up whatever was the current default. In a relatively recent update to UD as part of tightening security the default was changed to No. It was mentioned in the changes but I guess you missed that

It is really up to you. The only reason I could see to pre-clear them is to run a confidence check on them. If you say that they have been working fine and as long as you check the SMART information for the drives to see if it all looks looks good then the preclear could be superfluous.

The simple way to express it that the security on a port is as good as that of the application handling that port. Therefore in your case that is the security capabilities of NextCloud. Also, since you are presumably running NextCloud in a docker container then when setting up the volume mapping for the NextCloud container you should not give it any access to more of the Unraid server's filestore than it needs to operate correctly.

There is an option to pause the parity build on the Main screen. However if you shutdown the server Unraid will start the parity build again from the beginning on next boot. if you install the Parity Check Tuning plugin then it has an option to restart the array operation from the point previously reached on the next boot. However that functionality does rely on you achieving a tidy shutdown - are you managing that? There are also temperature related options, but they are geared around the drive temperatures and not the CPU temperature so may not be of any use to you.

Have you checked under Settings->Unassigned Devices->SMB Security that you do not have it set to No (which means do not make it visible on the network). You want at least one of the other modes - probably Public I would guess which used to be the default until security on shares was tightened and the No option was added and made the default.

If going this route no need to wipe it as rebuilding parity overwrites every sector on the disk so existing contents are irrelevant.

I am going to try and add more detail to the documentation to make it cleared how the different file system types should be handled from a check/repair perspective. I guess shortly we will have to add ZFS systems into this mix as well.

The calculations used for parity1 and parity2 are different so the disks cannot simply be moved. If you want to move parity2 to the parity1 position then you would need to rebuild parity. The alternative is just to remove parity1 and run without it leaving parity2 in place

Not disagreeing with that statement - just pointing out that you can normally easily find the required information without using Search. In my view using Search is likely to land you on obsolete information.

Any drive that cannot complete the extended SMART test without a read failure should be replaced. That test is internal to the drive and not something the user can do anything about.

Limetech have stated in the past that they have no intention of making the main Unraid licence subscription based (although they did reserve the right to make additional services subscription based). One of the big plus points for Unraid is the fact that one has always been able to update to the latest release no matter how long ago one bought the licence. Whether that intention had changed in any way I have no idea but I hope not.

This restores the docker containers variable data - it does not restore the docker containers themselves and the settings you used when installing them previously. How to do this (with their original settings intact) is covered here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI or the Documentation link at the bottom of every forum page.

The overall assessment tends to be largely meaningless as anything that makes that fail tends to mean the drive is in a bad state. the best general indication of drive health is whether it can pass the SMART extended test.

That log looks good Restart the array in normal mode and the drive should mount so see if you now have a lost+found folder on that disk. That is where the repair process would put anything it found for which it could not figure out the correct name. Your report looks very clean so there is a good chance no lost+found folder was created.

If you copy share to share and afterwards delete the source you get the behaviour you expect. However a ‘move’ can give the unexpected behaviour. The whole idea of `Dynamix File Manager is that it knows about both User Shares and Disk Shares and how to handle them correctly. It protects from the mistakes you can make with Krusader that can lead to data loss.

The ‘system’ share now shows as being entirely on the cache pool. Be interested to hear if that has improved things - it should for docker containers. For VMs the ‘domains’ share seems to exist on multiple drives (I assume contains vdisk images) so running VMs may spin up array drives.

No! I would expect the correct size to show. How did you set up the new stick (and what was the size of the old one).

The first time you build parity then Unraid will read every sector from every data drive and write every sector on the parity drive(s). probably what you are thinking of is normal running when the number will be much smaller as you are then talking about changed sectors.

Several plugins are now deprecated on the 6.11+ releases as being incompatible. An obvious candidate is NerdPack but I think there are others as well.