itimpi

Many people seem to be assuming that Limetech will not honour their statements on how they intend to proceed. I think they will, and I see no reason to assume (as many are doing) that they will not. I agree if they change things from what has been stated that may be another story, but why assume the worst from the outset? I have seen both types of subscriptions - those which are not a good deal or the terms keep changing, and those that are. The good ones deserve support, particularity for products you re likely to be using every day.

It all depends on whether you continue to get problems. If it still looks like they may be RAM based then one possibility is to run with less sticks of RAM as that puts less load load on the memory controller so that tends to rule out RAM issues if you still get the same failures. You should also make sure that there is no over-clocking going on and that the RAM is not being clocked faster than the motherboard/CPU is capable of handling. It is easy to get RAM rated at a higher speed than they can support and a lot of people just assume they can run the RAM at the rated speed without taking into consideration motherboard/CPU limitations.

You need to check your flash drive is OK - best done by plugging it into a PC/Mac and running chkdsk on it. As mentioned in the message the licence fiie should be in the config folder on the flash drive. The message implies that either the flash drive dropped offline for some reason, or that it might have corruption.

Once you get the red ‘x’ which means a write to it failed for some reason and the data disks and parity are no longer in sync then Unraid stops using the drive until the status is cleared by a rebuild as documented here in the online documentation. could not spot any issues in the SMART report in the logs but you could run an extended SMART test if you want to be sure. By far the commonest cause of this type of issue is the cabling (either power or sata) not being perfectly seated so you might want to check that out.

First time I have heard of this happening. It is almost as if the drive change did not get saved to the flash drive so it might be worth checking that it does not have problems.

Correct Correct as long as they are configured to have redundancy (which is optional).

Just a thought - are you up to date on the Connect (MyServers) plugin? That looks like a message that would be generated by that plugin.

This is nearly always an issue with the way the shares and their associated permissions are set up on the Windows side. Is there any reason that you are not doing it the other way around - connecting the Windows machine to a share on the Unraid server which would be the more common way of doing things.

That is good, but just worth mentioning that although a failure in memtest is definitive it is still possible to pass it and have RAM issues when the system is under heavy load.

At the moment the system should be emulating dis3 and able to show its contents? If you can get a replacement disk and then rebuild the contents of disk3 onto it the contents you can see on the emulated disk3 should automatically be there. A point worth mentioning is that if possible you should keep the 'failing' disk3 intact until you have successfully rebuilt emulated disk3 onto its replacement. This is to give you an additional recovery option if anything goes wrong with that because although the current disk3 needs replacing I would expect that most of its content is still available if needed. I mention this simply because for warranty you may need to return the 'failing' disk3.

It is really up to you I think. You can do both in parallel if you want, and I see no reason why this should be much riskier that doing them one at a time and avoids the need to do two rebuild cycles. If you do want to do just one initially going for fixing the second parity seems best.

The syslog in the standard 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/freeze. 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.

It has already been said that this will remain true, but that there are going to be some new subscription based options available. I have no idea why so many people seem to think that because there is going to be a subscription option in addition to the current offering that this is a huge downside.

You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

Any error messages in the logs are generated deep within the Linux kernel well below the Unraid I/O level. They can also vary significantly so without looking both at them, and various other files that are in the diagnostics it is hard to determine the true cause as there can be many things that can cause similar symptoms and the difference in the logs can be minimal. Even after looking at all the information available in the diagnostics one can often only say something went wrong and give a recommended cause of action to pin down the underlying cause. The only thing that is definitive is that a write to the drive went wrong so parity is now out-of-step with the data drives.

But it does not! All the OS knows is that the write failed. It does not understand why, only that all attempts at a retry have failed. All that could be added is an explicit statement that a write has failed. This might add some value as some users think that the red 'x' means a drive has failed at the hardware level, not that a write to it failed and could not be recovered via retries? You still need to dig into the logs to try and determine why.

That is one option. Alternatively you can move it to the array using the process documented here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

All you would get is an indication that a write failed (which is what leads to a disk being disabled), not why that write failed. Nothing more would be available without digging into logs. did you start the array after unassigning the array to commit the drive as missing, and then stop it again to reassign the drive before starting it again to rebuild parity?

They are included in the diagnostics so simply uploading a new set of those is better.

Yes they need formatting. Unraid shows which drives will be formatted when you select this option so you should always check that is just the drives you expect. In your screenshot it shows the two SSDs will be formatted.

Personally I disagree with that as I am not happy with anything that hides genuine errors when they can easily be fixed.

If you have anything configured to use /mnt/cache, then since the cache drive has not mounted this would be writing to RAM rather than persistent storage (and thus lost after a reboot).

I can see that the cache drive is not mounted, and that was the first point at which I saw an issue with the cache drive.

It looks as though your cache pool has failed to mount as diagnostics contains: Feb 15 15:34:24 TronsHome emhttpd: mounting /mnt/cache Feb 15 15:34:24 TronsHome emhttpd: shcmd (736): mkdir -p /mnt/cache Feb 15 15:34:24 TronsHome emhttpd: /sbin/btrfs filesystem show /dev/sdb1 2>&1 Feb 15 15:34:24 TronsHome emhttpd: ERROR: no btrfs on /dev/sdb1 Feb 15 15:34:24 TronsHome emhttpd: /usr/sbin/zpool import -d /dev/sdb1 2>&1 Feb 15 15:34:24 TronsHome emhttpd: no pools available to import Feb 15 15:34:24 TronsHome emhttpd: cache: no uuid Feb 15 15:34:24 TronsHome emhttpd: /mnt/cache mount error: Unsupported or no file system Feb 15 15:34:24 TronsHome emhttpd: shcmd (737): rmdir /mnt/cache

You need to make sure that the pool is completely balanced to RAID1 initially. You can then remove 1 drive and then you need to rebalance it to RAID1 gain with just 2 drives present. You can then remove the second drive. You now want to change it to use the Single profile.