itimpi

Not sure why you are getting orphaned images with such regularity, but it is quite normal to see them being dated sometime in the past. The date on them will be the date that layer of a container was downloaded - not the date at which it became orphaned.

which one did you find? There is this one in the documentation accessible via the Manual link at the bottom of the UnRaid GUI.

Not quite it will go to the next disk that has at least 20GB free as that is the Min Free Space setting. If there is less that 25GB free the transfer will now fail due to running out of space. That is why it is recommended that the Min Free Space be bigger than the largest file so that once a disk is selected there is guaranteed to be enough space for the current file. There are no notifications along the lines you suggest - the closest is the disk warning levels that are not related to the Min Free Space setting. You can over-ride the global setting for any drive by clicking on it on the Main tab.

Not sure why the problem resolved itself but at least you are back in operation Have you also set the Minimum Free Space settings as suggested? This might help you avoiding this issue in the future.

Are you trying to download lots of files or a single large on? Files cannot be split across drives so if it is a single large file that is larger than the Minimum Free Space setting you would have to download it directly to a drive that has sufficient space. The drive selection logic never takes into account the size of the file when selecting a drive.

I can see the syslog is full of messages about there being no free space on selected drives. I would suggest that: you run a File System check on all drives in case some corruption has occurred and the free space is incorrectly being treated as zero set the Minimum Free Space value for both the pool/cache and for the shares to stop UnRaid selecting them when free space gets low That may cure the problem, but if not hopefully that will result in a tidier syslog to help with diagnosing further.

You should post your system’s diagnostics zip file (obtained via Tools -> Diagnostics) so we can get a better idea of how you have things set up and it would also help to give an example of something you think should be moved that is not being moved. You also might want to turn on mover logging to get some feedback on what mover is doing (or not doing).

You definitely do NOT want to go any route involving a rebuild as that cannot change a drives content. If you want to reformat the drives the procedure is covered here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI.

Sounds about right. Even a drive with no files on it will have space used to hold the file system structure information, with the amount used varying by file system type. Surprised the values are not the same if the disks are the same size and using the same file system. Having said that the more recent versions of XFS have a larger overhead when creating an empty file system so maybe that explains the difference?

it is not clear if you are asking about copying configuration information so the second server is set up to be similar to the first or if you are talking about the data on the servers (or both).

Wha do you mean by you ‘stopped the parity’?

You seem to have it backwards from what I can see? The Minimum Free Space setting works at the individual file level and is used when a file is first created (and at that point the code doing the drive selection makes no assumptions about how large that file is and has no access to that information). That is why the recommended value is for it to be at least bigger than the largest file you intend to download because you are not protected against trying to put a file that is larger than that on a drive - you are protected against smaller ones as they will fit. Once the free space on the a drive falls below that value a different drive is selected for the NEXT file (assuming other share settings such as Split Level allow this). If you are downloading multiple files in parallel then the Minimum Free Space needs to be bigger than the sum of the file sizes to avoid problems. if you are downloading directly to a drive rather than to a share you are by-passing the User Share system so the setting then is not relevant as it only applies to shares.

The free space CAN go below the value you set. It is about whether a drive can be selected fo a new file and what it does is stop a NEW file going to the drive when the value falls below that value, As an example if you had the valu set to 50GB, had 60Gb free and tried to write a 40GB file then this would be allowed and there would only be 20GB free after writing the file finished and the NEXT file would go another drive, If the file had been 70GB then the drive would have been selected and the write-failed because 70GB was more than the available space,

Time is probably the key criteria for when checks should be done. Most people seem to select something like Monthly or quarterly for scheduled checks.

Did you go into Apps -> Previous Apps and select the container so that the binaries get re-downloaded into the Docker.img file? From you description it sounds as if you may have just restored the appdata part and not the binaries?

Not at all clear. Have you checked what is actually taking up the space? For instance do you have any dockers configured to use the cache/pool directly as this would bypass that setting?

Not that I know off. the process is quite simple (download, unpack, write updated files) so not sure the log would show anything useful anyway

Normally reading is faster than writing. However when writing RAM can be used to buffer the write giving a higher perceived speed, while reading can never go faster than the drive can deliver.

Could mean the drive dropped offline? Suggest you plug it into a PC and let Windows check it. Assuming that is OK, download the zip file for the release and extract all the bz* type files overwriting the ones on the flash drive.

As far as I know this is not possible unless the disks are passed through as network shares or as USB devices. Editing the configuration of a running VM is not a supported option.

As was mentioned simply copy the all the files. I think on Unraid v5 the flash drive was automatically exposed as the 'flash' share so it can be done over the network. Best to do it with the array stopped so that you do not get an automatic parity check (due to an unclean shutdown) if you ever need to use it.

I believe you will be prompted for the password if you reboot. I do not use encrypted disks on my live server so I may be wrong about that

Unassigned drives can handle drives dropping offline and re-appearing while the main array cannot.

Did you have parity drives? If so how many and do you know which ones they were?

Unraid will never automatically move files between array drives. You may be able to achieve what you want using the unBalance plugin. The alternative is to manually move the files between drives.