itimpi

You have not mentioned what port forwarding you have set up on the router(s). in particular ports 442 and 3306 which are required for the containers

You are no longer allowed to have any files on the flash drive with execute permission. You either need to copy files elsewhere to be able to change the permissions or precede the script name with the command needed to run it (e.g. bash path-to-script)

The version of memtest that ships with Unraid only works when booting in legacy mode. If you want a version that works in UEFI mode then you need to download it from the memtest86+ web site.

You might want to look at this section of the online documentation.

If you try and access the server by IP address rather than name does it work? If so that would at least point out the issue may be related to name resolution in some way.

No - merely an observation. I have shares on my system with far more files/folders and never see this problem I would suggest you post your system diagnostics zip file (obtained via Tools >> Diagnostics) after the problem has occurred (giving an approximate time to help when checking logs) to see if anyone can spot anything that might be relevant.

You can do an automated transfer to another one once a year (and the old one then gets blacklisted). If for any reason you need one sooner that then you need to contact Limetech via email. Make sure you have a backup (obtained by clashing on the flash drive on the Main tab) any time you make a significant configuration change as this makes it very easy to transition to a new USB drive with all your configuration details intact.

If you have not already tried them then the steps listed here are worth trying.

Not possible as far as I know. it is worth emphasising that you do not run Unraid from the USB, what you do is load Unraid from the USB on boot - Unraid actually runs from RAM.

The docker.img file will always be set initially to whatever size you set on the Docker Settings tab as it creates a file of that size set up as a virtual disk image. That is different to the image being filled up with content so that there is no spare room inside it.

You require IOMMU to be enabled before anything can be passed through. If your hardware supports it then you need to find the relevant BIOS setting to enable it. I know it can often be hard to find being several layers down in the BIOS settings tree.

The screen shots do not show that clicking the Container Size button at that point showed no container was using excessive space! That is what I was thinking was inconsistent with a total of 3TB being used! Something is using up all that space as the behavior you describe is not normal BTW: Folders like appdata are irrelevant to this issue as they are external to the docker.img file.

It might be worth pointing out that neither file system will allow for rebuilding files from parity - that is not how parity works (parity is about recovering failed drives). You can only recover corrupted files from backups (which is one reason why you need a good backup strategy for important files). At the moment only BTRFS has built-in checksumming to detect corruption when a file is accessed (it does not fix it - it just detects). XFS is meant to be adding checksumming as part of the developments in the Linux 5.x series kernels but when it will be ready for use I have no idea. In normal operation a correctly functioning hard drive should detect corruption at the hardware level before the OS even gets involved and return a read error so for most people that is sufficient.

The mistake was doing the format as that would end up formatting the emulated drive and updating parity to reflect the fact that the disk has an empty file system. The rebuild would then have rebuilt the result (an empty file system) from the emulated drive. The correct steps would have rebuilt the disk with the data intact. What version of Unraid are you running. In the 6.8 release a big warning pop-up was added to try and stop people formatting the drive when they should not (in previous releases the warning was still present but less intrusive so easier to overlook) as format is NEVER part of the rebuild process. If you DID get this pop-up how could the wording have been improved to make you realise this was not the correct action to take?

This statement seems inconsistent with the fact you said the docker.img file has maxed out a 3TB drive

This is not something I have seen anyone asking about before so it is probably not something that has been considered as an issue. I did a quick web search and it appears it should be possible to get Samba to re-read it’s config without restarting the service. Maybe worth raising a feature request for this? Not sure if it has any non-obvious implications that might mean such a feature could cause problems.

I think in this case Samba is stopped/restarted to apply the settings change which causes the problem.

There is a known issue For some time where once you have made changes in XML view can no longer use the form view without losing changes made in XML view.

It is not clear exactly what steps you took and in what order? Did you ever take steps to get the drive treated as disabled or missing in Unraid? If not then it will be looking at the current contents. Have you tried starting Unraid without the disk actually plugged in to see what happens? Depending on exactly what you did then if you are lucky and parity is valid it might show the disk is now being 'emulated' with contents available (and then a rebuild becomes a possibility).

First time I have heard of IP addresses that are internal to your network not being considered as anonymous! If there are other IP addresses that you think are not anonymous then maybe it is worth mentioning examples. You also mention 'other stuff' - examples are always welcome to see if things can be improved. Unraid works perfectly well with Windows for the vast majority of users. Nearly all problems have tended to be because Microsoft have made changes at the Windows end.

That is the only difference.

If share6 is set to be Private then nobody has any default access and you control explicitly what access each user has.

The normal way is to create checksums of both sets of files. You can then easily compare the two sets of checksums to see which files do not have the same checksum in both the live and backup copies. However creating the checksums in the first place is a non-trivial task. In practise you may just have to assume the rebuilt drive is fine with the ability to check specific files against your backups on demand.

I would just remove the drive so that Unraid starts ‘emulating’ it from the combination of the other drives plus parity. You can then look at the contents of this emulated drive to check that they look OK, as that is what will end up on any rebuilt disk. keep the removed drive intact as that is your fallback. One of the strengths of Unraid is that each disk is a self-contained filing system that can be mounted and read outside of the array which can be a great help if any data recovery is needed.

Just replacing the drive should be enough. As to whether you should backup the drive contents that is independent of whether you are going to replace the drive - you should always be backing up any important files regardless. Impossible to be certain unless you have backups (or at the very least file checksums) that they can be compared against. In normal operation one can expect a drive itself to detect corruption, but once a drive starts to fail I am not sure how reliable that detection actually is.