itimpi

The FAQ for the licence says the last 2 releases get updates. It says that once a release has reached beta status it counts. In practice that means most of the time this will be the last stable release and the one currently being worked on.

Not quite sure what you are saying? The Parity Swap procedure is for exactly the Use Case you described. Are you just saying that you have no issue at the moment and want to know for future planning?

I suspect it is not quite that simple if many of their employees work from home much of the time so you may get responses outside any quoted hours.

I think all the Unraid team are based on USA West coast which will probably be what times you should assume for support being online.

Glad to hear that it now works. If anything similar happens again it is a good idea to post your system's diagnostics zip file so we can see how things are configured and look at logs. Saves us having to guess.

You cannot get the blacklist removed. As the message indicates the fact you get this suggest the USB drive has either previously been used for Unraid and you transferred the licence off it, or it has been found that the GUID for the drive is not actually unique as it should be (because a manufacturer reused the GUID on multiple drives). If you contact support they should be able to tell you what was the reason for the blacklist. To clear this you would a new USB drive that DOES have a unique GUID and that has not previously been used for Unraid and then go through the licence transfer process to get the Unraid licence registered for the new USB drive.

You are likely to get better informed feedback if you attach your system’s diagnostics (with everything in the one zip file) to your next post in this thread. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

Very relevant. It needs to be UNRAID (all capitals) for it to normally be recognised. It is possible to provide an alternative name in the boot parameters but that is normally only relevant if also trying to run another copy of Unraid in a VM for development purposes.

That error almost certainly means you have something configured (probably a docker container) to use /mnt/cache. Since you do not have a pool called ‘cache’ that location is only in RAM and its contents do not survive a reboot.

Those settings only set the server up in listen mode. To get the server to save its own log entries you either need put its IP address into the Remote Server field or set the option to mirror the syslog to the boot dtive.

That makes sense. The first run fixed what it found and the second one then found no new errors. Files ending up in lost+found means that the repair process could not find the directory entry to give them their correct path/filename. These, unfortunately, typically end up with cryptic numeric names and need manual inspection to work out what they are to then correct the path/name. The Linux ‘file’ command can at least tell you what type of content is in a file which can help the manual process. Having said that if you have decent backups it is probably easier to restore any missing files from them and then delete the lost+found folder and irs contents.

Note that was just a check - not an actual fix. As you can see at the end you had the ‘no modify’ flag set. Were you offered a ‘Fix’ button after the check completed? If not there was probably nothing to fix.

As you have found the syslog in the diagnostics is the RAM copy and only shows what happened since the reboot. Enabling the syslog server to get a log that survives a reboot so we can see what happened prior to the reboot is the correct thing to do. The mirror to flash option is the easiest to set up, but if you are worried about excessive wear on the flash drive you can put your server’s address into the Remote Server field. If you are not sure how to do this post a screenshot of your syslog settings so we can advise you what you might have wrong.

If you have done that and you open the share settings then check if it shows there that this share is being treated as exclusive. If not then this will almost certainly mean that not all the files/folders for the 'appdata' share are on the 'cache' pool. In that case post diagnostics if you want more informed feedback.

I would recommend changing the mapping back to /mnt/user/appdata and then check that you have enabled Exclusive Shares under Settings->Global Share Settings. As long as all files/folders for the ‘appdata’ share really are on the ‘cache’ pool and there is no secondary storage set for the share then this will also bypass the Fuse layer. It will also continue working if for any reason files/folders for that share end up on another drive or pool albeit then with slightly lower performance. I would recommend posting your system’s diagnostics zip file so we can check settings and look at logs.