itimpi

You might want to consider installing the Parity Check Tuning plugin. Even if you do not make use of its other features the Parity History entries will start being enhanced to give more information about the check such as whether it was correcting or not.

Yes

What type of splitter? SATA->SATA seem to be unreliable if they split more than 2 way because the SATA connection can become current limited causing voltage sag. Molex->SATA seem to be able to handle a 4-way split reliably.

No idea - you will need to ask a Limetech representative about that.

The advantage of a ‘Custom’ path was that it could be something you mounted in the ‘go’ file and unmounted in the ‘stop’ file so it is not dependent on the array being started.

The one thing that surprised me was that the one year extension cost was the same regardless of whether you had the Starter or Unleashed licences since they are very different first year prices. I would have thought something more like $29 and $39 might have been considered. Probably a good reason why not but I wondered what it was?

You do not have to do anything to the Historical Drives section. That is where UD puts entries it previously knew about but currently thinks are not present on the server. The fact the drives are not appearing means they are not showing up at the Linux level. Whatever the 4 ‘missing’ drives are attached to is therefore probably not working.

Yes - in the path I gave.

you could try editing the config/shares/unraiddata,cfg file on the flash drive to adjust the list of included drives. i must admit i thought that making any change to the list and using Apply would rewrite the values to reflect the new selection

According to the diagnostics the ‘unraidddata’ share DOES have a list of included drives in its settings. If you think that is not the case then perhaps a screenshot of the settings page for that share might clarify things? appdata shareUseCache="prefer" # Share exists on containers_cache, disk1, disk3, vm_cache This appears to be an outstanding issue as well as the files on the ‘vm_cache’ pool will remain there as it is not associated with that share. Mar 21 13:53:01 Goathead root: Fix Common Problems: Error: Same share (guacamole) exists in a different case Mar 21 13:53:01 Goathead root: Fix Common Problems: Error: Same share (Guacamole) exists in a different case It appears this may also be outstanding. It can cause an issue as SMB will ignore one of them as it is not case significant despite the fact the underlying Linux system is. M---a shareUseCache="no" # Share exists on disk3, disk4, downloads_cache Mover will leave the files that are on the ‘downloads_cache’ pool as that share is set so that mover will ignore it.

Have you done anything to start correcting those reported problems which all look like they are probably genuine.

Have you managed to get all of the ‘system’ share onto the cache pool? Have you corrected any of the other wrong share settings? Do you have Turbo Write mode enabled? I would suggest posting new diagnostics taken with the array started in Normal mode so we can see current settings.

This seems wrong - I would expect a 1TB drive to only take something of the order of 2 hours or less to rebuild a 1TB drive.

I thought you said the system was 'frozen' If not there is a Cancel button on the Main tab. If it is frozen then it has probably crashed and you will need to hold down the power button to force a powerdown and then reboot . The system should then reload with all data intact. If that is the case then you should consider enabling the syslog server (probably with the mirror to flash option set) so we can get a syslog that survives a reboot.

in this screenshot the server is enabled to ‘listen’ but you have not set at least one of the last two fields which are required to actually make it start writing anything.

The messages will be valid if you explicitly gave a list of included disks in the definition of the share rather than leaving it at the default of ‘all’ and did not go into the settings for the share to adjust the list after removing the disks. However no reason that would have caused the system to lock up like you describe sp I suspect you have some other problem.

It looks like the Minimum Free Space setting for your share is less than the available space which is why you get told there is no space available.

You normally want this to be non-correcting. The rational being that you do not want a drive that is playing up corrupting parity before you realise it has happened. You should only be running a correcting check if you think you have no outstanding hardware issues or problem drives.

The diagnostics are a single zip file and that is what we normally want posted. Looks like you have something configured too automatically open a downloaded zip file. Please post the single zip file instead as it is much easier to work with.

The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field. However the syslog in the diagnostics you did post suggests you may have had macvlan crashes - these will eventually bring down the server. The recommendation is to switch docker networking to use ipvlan which is more stable. If you want to continue to use macvlan then make sure that bridging is disabled on eth0. You also are loading a LOT of extras so any of them may be causing an issue - does the problem still occur if you boot in Safe Mode to stop plugins and extras from being loaded?

You have not actually set the syslog server to be enabled !

Since it was mentioned that the webGUI could not be accessed from the other machines I thought this needed resolving first.

No - sorry it is a File Manager issue - I was obviously fast asleep at the time.

the fact that you have even one machine able to get up the GUI shows the server must be functioning as expected at that point. Do you know if the other machines can ping the IP address of the server? This would at least allow you to determine if you have a networking level issue. You definitely want at this stage to be trying via IP address to avoid any name resolution issues. The only other thing I can think of is whether you have ad-blockers installed on the problem machines as the Unraid server typically needs to be white-lusted in them.

I have the problem that File Manager does not seem to work correctly with Exclusive Shares as the source for copy/move operations. To reproduce: Go to the Shares tab and start to browse a share that is an Exclusive Share Select a folder within that share Select the Copy or Move option You are now only offered a list of disk shares for the destination of the copy. I think that you should instead be offered a list of User Shares instead as you would if the source was not an Exclusive share. The above process works seems to fine if the SOURCE is a none-exclusive share and the TARGET is an Exclusive share.