itimpi

Each docker container can have its own requirements around any folders/files that are part of its working set located in a folder under the appdata share so the only foolproof way to fix it is to remove the relevant folder in appdata for a particular docker container and let it be recreated from scratch. Any mappings to other shares should be OK. You can do this for just those docker containers that have problems if you can identify them. You can delete the folder using the Dynamix File Manager plugin with the relevant docker container stopped and then restart the container to get the folder recreated. If there are any containers where you really do not want to loose the current working set data then you would have to ask for guidance on that particular container in its support thread.

It can cause havoc and make the whole server unresponsive.

The 'loop' devices are used to support docker and VMs. In your case loop2 almost certainly refers to your docker.img file which by default is formatted as BTRFS internally. You should follow the instructions here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI to create a new empty image file and then re-instate and repopulate this file with your previous docker containers with settings intact.

When you use rsync then trailing slashes on the paths used are important - it looks like you go one of them wrong 🙂 You can probably correct most of the issues by using the 'mv' command from a console session and this would be the quickest. If for any reason there are any issues doing this or you are not comfortable with the command line I suggest you use the Dynamix File Manager plugin to move them. Since you also mention that you were not able to access the folder contents you probably also managed to get the permissions messed up so you should run Tools->New Permissions against disk17.

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.

Your diagnostics show macvlan related crashes and these are known to eventually crash the server with the 6.12.x related releases. You should either switch docker to using ipvlan via settings->Docker (Advanced view) and reboot, or if you want to continue using macvlan make sure you have followed the requirements for this in the release notes.

It all depends on how you read the error message 😊 If it refers to the file mover is currently working on then it is correct. Another point that may not be obvious is that at the point the error occurs it is quite likely that mover has no idea which disk contains the ‘file exists’ file, just that it exists somewhere on the array.

The md2 part indicates it is drive2.

If your cache pool is a single drive then it is expected that the appdata share will show as some or all files unprotected as the cache has no redundancy if it is a single drive pool The whole idea of keeping appdata on the cache is to maximise performance and to avoid spinning up array drives unecessarily. You want to install the Appdata Backup plugin to make regular scheduled backups to the main array, Note that you also want to make sure the System share is also on the cache drive for best performance.

There are a number of ways to detect data being corrupted after it is written: For XFS file systems you can install the File Integrity plugin that will generate checksums for your files. Use BTRFS (or ZFS) file systems which have built-in check-summing of files. Note that in both cases this is about detecting corruption has occurred - it is not about fixing it so backups are still necessary for important data that you cannot easily get again.

The error message I think is referring to the file it wants to move. Move will not overwrite duplicate files and in normal operation you should not get them. If as in your case you find you have got them then you need to manually delete the copy you do not want (typically the oldest).

If there is a saved log it will be in the ‘logs’ folder on the flash drive.

Invalid GUIDs tend to have number sequences with lots of zeros or sequences like 12345678. you can get ones that look like a valid GUID but that is not acceptable because it has been reused on every drive from the supplier so it is not unique. This is common with counterfeit flash drives.

That is the default name if there is no config entry setting something different.

It is not just what the RAM is rated for, but also what the CPU/Memory Controller can handle which is often less than your RAM rating. You have to go for the lower of option.

I thought you said you had the original email with the correct key for the flash drive? if that is not the case then you will probably need to contact support to get this resolved.

As mentioned in the link you can put the Unraid servers IP address into the Remote Server field to get the server to send syslog entries to itself.

Did you put the licence key file into the ‘config’ folder on the flash drive?

I believe that this requirement at the moment is a bug (probably at the server end) that needs to be fixed.

The log in the diagnostics is the standard syslog one that starts afresh each time the server is booted. To get a log that can survive a reboot you need to enable the syslog server. Using the mirror to flash option with that is probably the easiest. You can then post this after a crash so we can see what lead up to the crash.

You need to have secondary storage set to array and mover direction to be array->pool. Now running mover will transfer files when it is run. With the settings you currently have only NEW files are written to the cache and mover does nothing so leaves existing files on the array. After all files have been moved so there are none left on the array you can change the secondary storage setting to none which will allow you to get the performance boost from it acting as an Exclusive share (as long as you have allowed Exclusive Shares under Settings->Global /share settings).

You do not even need a trial licence for this test - just use a new stick.

It also spends some considerable time pointing out checks that you should make to make sure you do not get an unclean shutdown from a regular shutdown. For instance you can always get unclean shutdowns if the various timeouts are too short for your system.

Well done for even discovering they were fakes. This is the first time I have heard of fake SSDs. I thought it was only fake flash drives we had to be wary of.

Difficult to say. Have you read 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 to see if it might give a clue.