itimpi

What disk controller is it attached to? Some older controllers were limited to 2.2GB

Ironically I found this when making some changes that negated my current need for the stop file. I was wanting to edit it to remove its current contents.

I can confirm that if the stop file is present Unraid runs it as part of the shutdown processing. As was mentioned it is a complement to the go file. I have some drives I always want mounted regardless of whether the array is started or not so I mount them in the 'go' file. I then use the 'stop' file to tidily unmount them as part of the shutdown processing. This particular task could now be handled by the UD plugin, but as far as I know the stop file is not deprecated.

Thought it was worth mentioning that if you have a '/boot/config/stop' file then it is not showing up as a file to be edited.

Have you actually tried 6.7 stable? Once a release goes stable users are expected to stop running rc releases.

It DOES do this! The old files are put into the "previous" folder. The download is checked against it's checksum. It then writes the new files to the flash drive and waits for Linux to report success. It is this last step that appears to be going wrong in that Linux is reporting success but that a read of these files on the subsequent reboot is failing. Why this is happening I have no idea. My guess is that it is something in the Linux kernel has reduced the reliability of writing to the USB. Whether this is affected by a setting that Unraid can control I have no idea. It could also simply be that the upgrade process is the only time at which a significant amount of data at one time to the USB stick so it is the time that such an issue is most likely to show up.

The diagnostics are a ZIP file containing many other files. The expectation is that you will post the entire ZIP file to the forum.

Have you checked that you have not set an over-ride for that particular disk (click 0n the drive in the Main tab to check).

If your problem is caused by a Marvell based controller there is a solution involving adding extra options to the boot parameters that seems to have worked for most people. You might want to try it as there is no guarantee that any future UnRaid release will have any other way of handling this,

Never seen Unraid just delete a file. It might be worth posting your system diagnostics zip file (obtained via Tools->Diagnostics) to see if anyone can spot a reason this might have happened.

I have exactly the same timezone set on my system and the logging IS reflecting the setting. Not sure why yours should be any different. If you supply the diagnostics zip file (obtained via Tools >> Diagnostics) then someone might be able to suggest a reason.

You can always downgrade (or upgrade) manually any release by downloading the zip file for the release from the Limetech site and extracting all the bz* type files overwriting those in the root of the flash drive

Most Linux systems are installed to a hard disk with files all over the place.which complicates roll-back. On Unraid which really only installs itself at boot time into RAM it I s trivial for thebUser to do it themselves as it just involves copying the contents of the ‘previous’ folder on the USB stick back to the root.

The updater DOES provide a mechanism for rollback, but it is not of much use if you cannot boot in the first place. I think the updater assumes that if the checksum on the download was good; it got no error unpacking the release and then writing it to the USB stick that everything is OK. This has not been an issue in the past but a failed updte does seem to have been more frequent in the last few releases. Something must have changed to cause this but quite what it might be I have no idea. I wonder if there is any benefit of adding an option to the Boot Menu that allows for booting the previous release?

I was not saying that the upgrade process did not appear to complete correctly. I am suggesting that the files did not in fact all get written successfully to the USB stick since the error you mention suggests an error reading from the USB stick.

Shares need to be set to cache Yes to get mover to move files from cache to array (this is described in the GUI built-in Help).

I suspect the upgraded files were not written successfully to the USB stick. I would recommend downloading the ZIP version of the release from the Limetech site and extracting all the bz* type files over-writing the versions on the flash drive. You can also roll back the update by copying all the files from the ‘previous’ folder on the USB stick back to the root of the USB stick.

This normally means that the upgrade did not get written correctly to the USB stick. Easiest solution is to download the ZIP file version from the Unraid site and extract all the bz* type files overwriting the ones on the USB stick.

Why are you trying to do this? Unraid does not install in the traditional sense - instead it unpacks itself from the archives on the USB stick (which also holds the licence file) into RAM and then runs from there. Since you need the USB stick to be present all the time that Unraid is running why do you think there is any advantage to trying to get it onto a SSD instead of simply booting it from the USB stick?

The GUI only lets you go back one step so in that sense you are right. However you can always do this manually by downloading the ZIP file of the release you want from the Unraid site and then extract all the bz* type files overwriting the ones on the flash drive.

I do not think that Unassigned Devices supports drives that are in ReFS format.

I have the exclude working fine, and in this case that is probably what I wanted anyway as the files have already had their integrity checked at the original location and I do not intend to delete the original files. I thought it was worth mentioning, though, as it is quite possible that you do not want the plugin to check a hard link (assuming it can detect them in the first place). Having said that I am surprised that an error is actually reported. I would have expected the extended attribute information to either be present on the hard link entry as well (in which case why the mismatch) or the plugin would generate a new set of extended attribute information. I will have to look at this information on my system to see if I can sport what is generating the mismatch information.

With OpenVPN you are NOT exposing your server to the internet - just the OpenVPN port and that is considered safe. If OpenVPN gets cracked then there will be probably be millions of servers that suddenly become insecure.

There is no way that error should be directly a factor of the 6.7 release. There will be some other factor at work. That error suggests that the USB stick is not being properly picked up during the boot process.

Note that It is already to create a second cache pool managed by Unassigned Devices as long as you do not want it to also participate in the User Share System. You do have to use CLI level commands to initially create the pool as there is no GUI support for setting up such a pool.