itimpi

I think this is a problem that only some people encounter? As far as I know everyone who tried the betas eventually got it working (unless they quietly rolled back to Stable without mentioning it) so it was not obvious that many users might encounter an issue? Have you tried the suggested solution of disabling VT-D to see if it works for you?

I have not seen mention of that UPS before, but other CyberPower UPS units (I have a couple myself) work fine with the APC UPS software that comes as part of standard Unraid. Have you tried that to see if it works with that particular UPS or did you go straight to trying NUT?

Prefer means try to move from array to cache, and is the exact opposite of Yes

Can you give an example of some files that you think should be moved and are not being moved? Alternatively turn on move logging, tart mover and then post new Diagnostics. I note that quite a few shares are set to Use Cache=No. If you ever get any files on the cache that logically belong to such a share then mover will not move them (turning on the help in the GUI should make this clear). Only shares which are set to Use Cache=Yes will have files moved from cache to array.

what problem are you referring to? What is 'them' in this context?

Ignoring the fact that having a UPS is an excellent idea on an Unraid server (and I have one myself), I have found that more often than not after an unclean shutdown the automatic parity check corrects a few sectors near the beginning of the disk (I presume because some bits to do with unmounting the disks are not correctly set) and then often runs to the end with no further sectors corrected. In such a case pausing/resuming the parity check has little effect on the overall result. As was mentioned file system corruption would be a much more serious issue and would not be corrected by a parity check anyway. You also relatedly frequently get the case where a disk is reported as unmountable after an unclean shutdown if you try and start the array and running xfs_repair against it resolves this without any data loss. I personally have a simple script that runs a file system check against all my array drives and if any report corruption (optionally) attempts a repair. I tend to always run this before starting the array if I have had an unexpected shutdown as it does not take very long. This has a side benefit that it frequently stops drives being reported as 'unmountable' after restarting from an unclean shutdown. I wonder if automatically running file system checks after an unclean shutdown is something that it might be worth raising as a feature request?

Why not use the Parity Check Tuning plugin to only run the check out of prime hours. The plugin now handles pausing/resuming non-scheduled checks as well (assuming you enable this in the plugin's settings). The after a power blip if you get a parity check auto-starting because of an unclean shutdown you can immediately pause it and let the plugin handle running it only at the scheduled hours. That way you avoid having the server running slowly during prime time because of the parity check. I have been looking at whether the plugin could do an automatic pause/resume according to system load but I have not yet found a satisfactory way of detecting when a pause is appropriate and (even harder) when a resume is relevant so at the moment it only handles running increments at scheduled times. If I ever crack detecting the load appropriately I will add an 'auto' option to the plugin.

If the folder does not have a corresponding .plg file then it is probably part of core Unraid and thus not removable. All add-on plugins will have a .plg file as that is what is used to install them and to activate them after a reboot.

Neither! Unraid uses a FUSe file system to give you its share view. If a file exists on more than one disk then the one on the lowest number disk is the one shown and any others ignored. This can sometimes be confusing as if you attempt to delete such a duplicated file it appears to not have worked as the next instance of the file becomes visible as the one that is displayed. This is especially confusing if the two copies are not identical as the file can appear to have changed.

You are getting resets every 20-30 seconds on disk WDC WD100EFAX-68LHPN0, JEGLKGSN (ata8). This will be why your speed is so low. This is likely to be an issues with the SATA cabling to that disk.

The current pause/resume capability is a new feature of the 6.7 release but it does have the restriction that current position is lost on a reboot. I believe that pause/resume surviving a reboot is a roadmap item for a future Unraid release, but no idea on the ETA. I would assume that once implemented it may well also apply to disk rebuilds and disk clears as well since they can also be paused/resumed in the 6.7 release but we will have to wait and see what (if anything) materializes.

No idea I am afraid. Going to have to see if anyone else chimes in with an idea.

That is strange, it should be the other way around. Are you sure that you are using the correct IP address. Since when you try to access by name all that does is look up the name and then uses the IP address returned for that name it is difficult to imagine a scenario where name works and IP address fails.

Are you trying to connect using the server name or via it’s IP address. IP address is always more reliable. Recent changes made to Windows often cause problems with finding the server by name.

With version 6.6.7 did you repeat the ‘df’ command test? I would think that downgrading is counter-productive as the problem is more fundamental than that. one other thing to check isthat the USB stick is being given the label UNRAID (in capitals). The USB Creator tool should do this automatically but it is definitely worth checking as it is required. were there any messages on the console during the boot process suggesting that the system was having trouble reading the usb stick? If you have a choice have the USB stick plugged into a USB2 port rather than a USB3 one as they tend to be more reliable while booting and Unraid runs from RAM so gains no advantage from USB3.

That in itself should not cause an issue. However it is possible that somehow the USB stick did not get updated correctly (which is why I asked about the output of the ‘df’ command. The easiest way to correct this would would be to take the USB stick to a Windows (or Mac) system and plug it in there. Make a backup of the config folder as that contains the license key and all your configuration information. The easiest thing to do is to use the USB Creator tool from the Limetech site to rewrite the USB stick and when that completes copy the saved config folder overwriting the contents of the version put on the Flash drive by the USB Creator tool. If you do not know whether you were using UEFI style boot I would suggest you answer yes to that question as it does not stop legacy boot mode from working as well. Plug the USB stick back into the Unraid server and with any luck you are good to go. if for any reason the USB stick cannot be rewritten (or its current contents read) then we can give you the steps for transferring the license (and your configuration) to a replacement USB stick.

If you try the ‘df’ command from the console does it show that there is a device mounted at /boot (I.e. the flash drive). If not that could explain your symptoms as it means that the later stages of the booting process where the USB stick gets mounted is not completing correctly as that is required to complete starting the system.

I am confused. You say that when you enter the URL for the server in the browser then you are (correctly) prompted for the username/password. What happens when you provide the correct username/password for the GUI? The rest of your comments seem to imply that the array has not yet been started. You could confirm this by using the ‘df’ command at the console and posting the output from that. BTW: You are correct that there is no 24x7 support from Limetech. Not surprising as Limetech is a tiny company and there only a few employees in total (about 4 I think).

It is very likely the problem! In which case it is not a change in behaviour, but merely that you have not encountered the exact circumstance before. In the case of any conflict about which disk to use then the Split Level setting takes precedence. What do you have set for the Split Level for the share, and what is the actual path name for the file? It is possible that the Split Level setting is forcing a particular drive regardless of the Minimum Free Space setting.

Those errors suggest a problem reading the USB stick.

All top level folders on a drive are automatically created as user shares so this is expected behaviour.

It depends on the power failure. Typically it will only be a few and they are likely to refer to any write in progress at the time of failure.

The name needs to be 'UNRAID' (i.e. in capitals) for it to be recognised. However the USB creation tool should have set that. The messages about not mounting the drive during the boot would be a typical symptom of Unraid not finding the USB stick to mount. What OS were you running when creating the USB stick? It might be worth trying to create the USB stick again using the manual method to see if that helps.

OK that screenshot shows that the USB stick is not being mounted in the later stages of the booting process. This may explain why you have no network connection as network drivers are located on the USB stick. On the basis it looks like there is a problem with the USB stick: - What make/model of USB stick are you using? - How was it created? It needs to be a drive of 32GB or less formatted to FAT32, and labelled as 'UNRAID'. - Is it USB2 or USB3? USB2 drives tend to be more reliable - Is it plugged into a USB2 or a USB3 port? Again USB2 ports seem to be more reliable during the boot process.

This looks like an error in the creation of the user share rather than an error in the reported free space. I managed to reproduce the fact that a new user share set to be cache-only gets a folder (incorrectly) created on an array drive. The free space will (by design) include any free space on both the cache drive and any array disks that have the folder corresponding to the user share. The incorrect free space is therefore a by-product of the incorrect creation of the folder corresponding to the user share on an array drive