itimpi

This suggests you have something mapped (usually a docker container) to this path which is why it continually gets recreated on each boot.

The obvious thing to do in such a case is to have a spare licensed flash drive as the licence is tied to the flash drive - not to a particular server. You can then simply copy the config folder belonging to any live drive to make it a pick up the configuration required. another possibility is temporarily use a trial licence until you can get a new key.

Have you checked the GUID’s on the flash drives you have. If they are genuine I would expect each drive to have a unique GUID despite the fact they were supplied as a 3-pack. in the case of the manufacturer NOT giving each drive a unique GUID you tend to find that you cannot register them in the first place as it is highly likely someone else has already registered a drive with that GUID.

If your server has a fixed address, then if the docker containers use ports mapped to the host address then you can achieve this without the docker containers having their own IP.

The diagnostics do not include the log file produced by the syslog server - they only include the RAM copy that was started when the server boots.

Note that if uou click on the orange icon you will get a pop-up menu and if you acknowledge the error you will only get prompted again if it changes.

Handling of unmountable drives is covered here in 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.

I’m assuming your parity drive(s) are at least 18TB as no data drive can be larger than the smallest parity drive? when you rebuild to a larger drive the last step is to expand the file system to fill the drive.

This is not possible in the current release as you cannot have pools as both primary and secondary storage, and mover therefore will not move files between pools. It is possible that this restriction may be removed in a future release (perhaps 6.13) but until it happens what you want cannot be done.

The key is checked for the licence only at the time you start the array. The reason it needs to stay online is that it also holds all your configuration information (in the ‘config’ folder) and a small amount of status information (such as whether the array is started). There are therefore occasional reads of this configuration information and updates to the status information. It sounds as if in your case it dropped offline

Note that any share that has Use Cache=Prefer will try to move data onto the pool. I suspect that you do not want this for the ‘data’ share? The other ones set to Prefer are normally kept on the cache for optimal performance. You should also set a sensible Minimum Free Space value for the cache to prevent it filling up completely if everything configured to go there will not fit.

You need to decide which one is the one you want to keep. You can then use Dynamix File Manager (plugin) to move files as needed or to delete ones that you no longer need. You want to end up with any given file on only one location.

What plugin?

That will always fail as /mnt/vmstorage/domains is part of /mnt/user/domains so you are telling Unraid to overwrite files with themselves. In fact in a worst case it will end up destroying the contents of the 'domains' share by truncating files to 0 length. You must never mix user shares and physical drives in the same command as it can cause data loss. If you must move files manually use the Dynamix File Manager as it will protect you against this doing this and getting data loss as a result. You probably need to set the VM and Docker services to be disabled in settings to allow this share to be operated on by mover as is the case with the 'system' and 'appdata' shares.

You need to set the pool as Primary storage (i.e. the location where new files get put) , and then the array as secondary storage. Then set the mover direction to be array->cache.

That is the only file that can show what was happening leading up to the reboot. Do you have your server set to automatically boot if power is applied? Do you have a UPS? A reboot (as opposed to a crash) is normally triggered by something external to Unraid or is hardware related.

This file only gets created if you go the network settings and make a change there. Until then it simply uses default settings.

Why would you think the licence is invalid? If it works it is valid! The current flash drive gets blacklisted if you transfer the licence to another flash drive, and you would only do this if the current one fails. You can do one automated transfer every 12 months (if you need one), and if for any reason you need a second one before that you go via support.

What share are you having this problem with? Have you tried running Tools->New Permissions on the share?

There is little that can go wrong if you follow the instructions in the link that I provided. The main thing when using Unraid is make sure you do not ever use format on a drive unless you intend to wipe its contents.

Ok - that means the correct device name would be selected . I assume you are now getting dots displayed as the disk is searched for a secondary superblock.?

Was that running from the GUi or the command line? Is a secondary super block found?

That requires the docker and VM services to be disabled in Setting as they keep files open that will stop files being moved.

Yes. Unraid will no longer let you have a pool and a share with the same name.

You mention trying to run an XFS repair, but you do not say in what way it failed! Were you trying from the GUI or from the command line (as the command line is prone to error). Were you doing anything different to the instruction in this section of the online documentation that covers handling unmountable disks.