itimpi

Looking further at your diagnostics I think this might be a bug in FCP and it’s handling of pools? The floor is now set individually at the pool level (by clicking on a device in the pool), and it appears for the ‘cache’ pool you currently have it set to 0. You can probably manually edit the config/share.cfg value on the flash drive and change the value there (which I believe is no longer used on 6.9.x releases) to 0 to stop FCP complaining.

Just to check that you do not have a ad-blocker installed in your browser? While this would not explain the shares not being visible on the network it could explain them not being visible in the webGUI. Some ad-blockers do not seem to like the Shares tab in the webGUI If you do have such an ad-blocker installed then you need to whitelist the unRaid server to fix displaying the Shares in the webGUI.

Just thought I would let you know that tracking down the cause of this bug is proving more elusive than I had expected. As I mentioned I can reproduce this bug on one 6.9.1 system and not another. I have checked and they both have identical copies of the script for displaying the history, and on one it works without error and the other displays the error you see. Still trying to pin down the difference that causes this issue.

according to those diagnostics you have the cache floor set to be 90GB and the free space on the cache pool is 83GB

That suggests the you have the Parity Check Tuning plugin installed and that it is not up-to-date. There was a version released about a week ago that had that syntax error, but it was updated the next day with a version that cleared the error.

The plugin replaces the standard script with a slightly enhanced version that handles the extra fields the plugin handles to display history records which explains why you only see that error if the plugin is installed. Looks like something has crept into the multi-language support part of the script although I am not sure yet what it is. Thinking about it I have not checked the changes to produce the enhanced script against the standard 6.9.1 version. I have been able to reproduce this so will be able to fix it. Interestingly it happens in one of my test 6.9.1 systems but not another one on that same release. Not sure yet of the cause but I am sure it will be relatively easy to track down and fix. Thanks for reporting this.

The -L option virtually never causes corruption, and even if it does it will only be to the last file(s) written to the disk. That warning message reads a lot more ominously than turns out to be the case in practice.

It is normally recommended that you set the monthly parity checks to be non-correcting. The rational behind this is that you do not want a disk that might be playing up to end up corrupting parity, but you do want to be know if there is a mismatch so you can investigate why. You then only use correcting checks after a problem has been identified and if it was identified and (hopefully) resolved.

Rebuild finishing correctly is a good sign so you are probably good to go May want to run an extended SMART test as a confirmation but that is probably unnecessary.

in principle that plan should work. One step you have omitted is a step 5a where you use Tools->New Config to reset the array to an uninitialised state so you can now assign the 14TB as parity and the data drives as you want them. When you start the array the data drives will be left with their contents intact and unRaid will start building parity on the 14TB drive. Just make sure that you have cleared all data off the 14TB drive as building parity will completely over-write its contents.

The Unraid.net plugin does automated backup to the cloud (on Limetech servers). If you want local backup then the manual method is the long term solution.

You are correct in that the a€cone parity drive only needs to be at least as large as the largest data drive. Giving the exact error message (or even better a screen shot of the Main tab) that you get when you try might allow us to give a better view on why it might not have worked for you.

In case anyone else encounters this issue I’ve updated the relevant part of the “Getting Started” section of the online documentation (accessible via the manual link at the bottom of the unRaid GUI) with these steps so hopefully in the future other Linux users will also be successful

It might be worth emphasising to anyone using a trial licence that once you purchase a licence then Unraid no longer needs to check back with the key server and can function quite happily without an active internet connection.

No. If you start the array without the parity disk present then unRaid will want to rebuild parity if you then try and later add it back. Note that the check for the number of attached drives is done every time you start the array - not just once when you first start using unRaid. Also it is not recommended to use USB drives in the array as they tend not to be reliable enough to avoid issues. You might be better off running without parity and just making sure you have good backups of anything important - possibly using the USB drive for that purpose.

You would have to actually unplug the 7th drive as unRaid will not let you start the array with it present if you have a Basic licence. if that drive happens to be a USB drive then you could unplug it to allow the array to be started and once the array is started it can be plugged back in and used as an Unattached Device as the check on the number of attached drives is only carried out at the point you start the array meaning you can plug in removable drives (e.g for copying or backup) once the array is already started.

Did not look at the diagnostics as you mentioned you had rebooted. Now I look at them I see there is was I/O error on the disk so it is possible there really is a bad sector. However if that is the case it could get reallocated next time it is written.

The SMART information for the drive looks OK so it could have just been a temporary glitch that caused a write to the drive to fail. If you want to make sure you could try running an extended SMART test on the drive. Worth pointing out that if this happens again you are likely to get better informed feedback if you provide your system's diagnostics zip file (obtained via Tools->Diagnostics) before rebooting the server so we can see what lead up to the drive being disabled. If you want to try and continue using the drive then instructions for rebuilding a drive onto itself are here in the online documentation that can be accessed via the Manual link at the bottom of the unRaid GUI.

The main difference that Pools provide over UD is the ability to participate in User Shares which UD devices cannot. If this does not matter then it is up to you which you choose. I believe that the expectation going forward is that pools will be chosen over UD except when there is a good reason to use UD so that they can take advantage of any enhancements in the future in pool support.

You might need to use the New Permissions tool on any shares that have problems if you messed up the permissions when using,Krusader. Ideally run the Docker Safe version installed by FCP, but as long as you avoid the appdata share the standard version will also be fine.

I have just released the version of the plugin that will make it easy to create a log file on the flash drive when logging level is set as Testing. I would be grateful if you can set that to be active ; recreate your issue; and then send me the resulting log file.

Not sure why you should get this if on the latest release of the plugin To help with diagnosing the cause can you install the new version of the plugin (2021-04-02) I have just released and then in the plugin's settings set the logging level to "Testing" and select the one of the options for logging to flash. The plugin will now create a file called 'parity.tuning.log' in the plugins folder on the flash drive when it is running so if you can recreate the issue and let me have that file it should help me pinpoint where things are going wrong.

You could always try the legacy manual method for creating the flash drive thus avoiding the need to use the USB Creator tool.

That shows that at the moment the pause IS scheduled for 8:30 at the cron level which explains why the pause happened at 8:30. unRaid assumes any .cron file present in plugin’s folder contains entries to be added to those for the root user. This file is regenerated if you make any change to the plugins settings so if you want a different time make a nominal change and hit Apply. If you now examine the file you should see that the times for pause and resume match your current settings. My suspicion is that the last time you changed the plugin settings was when there was a syntax error in the underlying script file that stopped this file from being regenerated to match the new settings.

If you were hacked that could explain both the problems with the flash drive and your data possibly being deleted. Others that have been hacked and had their data deleted have had some success in recovering it using UFS Explorer on Windows. The big concern though if it was a hack is to work out how anyone got access to your server in the first place.