itimpi

The ‘Wed’ field is not a valid value. It needs to be a numeric value (I think it is ‘3’ for Wednesday).

Make sure it is not directly connected to the Internet but connect via a router and does not have ports forwarded to the server. This would include making sure it is not in the Router’s DMZ as well.

First steps will be to post the system diagnostics zip file (obtained via Tools -> Diagnostics) so we can see what the state of your system actually is and whether it looks like you have a disk problem or something else.

It does not sound as if you understand how parity works? If so it might be worth reading up on that as it can make things clearer on how Unraid operates. If you have no parity at the moment, then when you re-assign the parity disk Unraid will build new parity from the current data drives completely over-writing the existing contents of the parity drive. If you do have parity then Unraid will have been updating it in real-rime as you copied files onto the array. doyou run periodic parity checks? If so at what frequency (monthly appears to be a common choice)? Do such checks complete with 0 errors (which they should)? Are such checks run as non-correcting (recommended)?

Remember that when adding a delay it needs to be added to the previous container as the delay is the length of time to wait after starting a container before attempting to start the next one.

This is a known ‘bug’ in the way BTRFS reports free space on the case of mismatched drive sizes. You are correct in that the usable space with 2 mismatched drives is the size of the smaller drive.

1Gb connection requires 4 twisted pairs while 100Mb requires only 2 so a damaged cable and/or port can silently downgrade to 100Mb and it is not always obvious why.

Not unless you can persuade someone to put together a build that incorporates both sets of drivers. Yes if your hardware supports hardware pass-through (IOMMU).

Writing to the parity protected array is slow due to the amount of I/O involved. The above link explains this in more detail plus ways to potentially improve this, in particular the Turbo Write mode. Using a cache disk can improve this from an end-users perspective as writing to the cache is determined by the drives used there and if they are SSDs this can be very fast. Moving the files from cache to array is still slow but this is normally scheduled to run in quiet periods so is not visible to the end-user. However if does mean that you can fill the cache up much faster than it gets emptied so during initial load it is recommended that if possible you DO run without parity to maximise performance (at the expense of the data initially being unprotected against drive failure). Having said that if you do not have a backup of your data you may prefer to take the performance hit of slow writes to the array so that your data is protected on the array from the outset.

There is no 'free' version of Unraid anymore so you will not be able to upgrade unless you are prepared to buy a key. Are you prepared for that? You should always have backup of any critical data, preferably with at least one off-site copy. Your comments imply you have no backups which is very risky as you can potentially lose data for all sorts of reasons.

Sounds like it might be time to consider getting a UPS for your Unraid server

You can downgrade (or upgrade) to any release by downloading the zip file for the release from the Limetech site and extract all the bz* type files over-writing those on the flash drive.

It is also the only way you can re-order drives! In the special case of only having parity1 (not parity2) you can re-order drives without breaking parity. You can therefore use the New Config tool, re-arrange the drives into the order you want, and then tick the ‘Parity is Valid’ box before starting the array to commit the new order of drives and the array will start without needing to rebuild parity.

That is fine. The config folder does not get changed when you upgrade.

Normally this works without any problem and is the recommended way to move all your settings to a new USB stick (or back to the same stick if you did a fresh install onto it). The only caveat would be if you had corruption on the USB stick at the time you made the backup as that could mean one or more configuration files being corrupt. It is also important that you have not changed any disk assignments since making the backup as that can cause problems.

If you did not keep the config folder off the old flash drive you will have wiped your templates as they are stored there. If you have a backup from before you wiped the flash drive you should be able to retrieve the templates from there. If you do not have that then you are going to have to recreate the templates.

That is possible as vdisk files are by default created as 'sparse' files that means they only occupy enough physical space to hold the parts of the file that have been written to. However over time as the VM runs the physical space tends to grow towards the assigned size. If the physical media then runs out of space the VM will start mis-behaving. One needs to be careful, therefore, about overcommitting the vdisk space.

No it does not! This statement implies that you do not understand how parity works so it may well be worth reading up on this.

You need to format the new data drive before you can start putting files on it. when you do that is up to you. It is possible to format the drive while the parity sync is running and the system will handle it correctly although the format and sync will run slower than normal if both are active at the same time so waiting until the sync finishes is not a bad idea.

I would carefully check your network cabling. That sounds suspiciously like what you should expect if you are only getting 100 Mbps. I have seen it happen unexpectedly if you have a bad connection in a LAN cable which then silently degrades to only supporting 100 Mbps instead of the expected 1 GBPs.

Yes. However I was not sure if you actually wanted two parity drives at this point or only one and had accidentally ended up with two.

If you have 2 parity drives then they both need to be at least as large as the largest data drive (although they do not need to be the same size). With a 4TB and a 8TB parity drives the largest data drive allowed will be 4TB. You would have to have both oparity drives at 8TB before you could start using 8TB data drives. the above assumes that you MEANT to to have 2 parity drives!

Until you add the parity disk your data is unprotected. when you add the parity disk UnRaid will start building parity when you start the array, and when that completes (which can take some time) your data is protected.

It is mentioned in the 6.8 release notes that the security of the flash drive has been tightened and files located there can no longer have execute permission. Option now available are: Add the command before the script name. E.g. bash scriptname copy the script elsewhere and then give them execute permissions use the User Scripts plugin to run the script.

If that is what you used for the username it will not work! It needs to be ‘root’ (all lower case) as Linux is case sensitive.