BillR

I've had the docker disabled since I found out the cause of the problem. Should I re-enable it and allow the fault to occur first before I post the diag file? Also, I suspect that clearing the appdata folders and installing it again now that it supports non-privileged installation might well fix things - so as not to waste your time, should I try that first? Thanks for all your help 🙏

My appdata share is exclusively on a btfrs mirror of two enterprise-class SSDs - set up as per Unraid best practice. Mover doesn't touch my appdata share - ever. Yet I have been having the problem. So, it's not just about how our shares are set up. I've been running my Unraid server for 8 years and have run countless dockers over that time and never seen anything like this. You seem to be implying that those of us with this problem have our appdata share incorrectly set up. Not true in my case.

I'm having the exact same issue on Unraid 7.2.4 - happens every few days. I also installed UniFi OS Server docker from bmartino1's repository. This is too much of a co-incidence to be random. There must be something in that docker that's breaking Unraid. I'm going to stop the docker and see how I go. I have logs, but, unfortunately also have mover logs turned on☹️. I'll post the logs anyway - hopefully there's a clue in there somewhere. unr1-diagnostics-20260323-1837.zip

It's all looking good. I think I'm good. unr1-diagnostics-20260119-1944.zip

Wow! Well spotted. I totally didn't see that. I've followed your advice, put the array in maintenance mode and repaired the file system on disk 9. I've restarted the array successfully and will know in a few hours if things are better. Funny thing is that sometimes it took a few hours for the disk to go offline. When I first installed it, I had a few CRC errors due to a dodgy SATA cable, which I replaced. I suspect that may be why I got some file corruption. Thank you so much for taking the time to look at my log files. I'm very appreciative of the help. Will report back soon.

I recently replaced my parity drive with a brand new, larger drive. The old parity drive hadn't missed a beat in the years it spent in that role. So, I performed a pre-clear on it and added it to my array as extra storage. Since doing that, it seems to randomly become unavailable, as in I can't read or write to it, but in Unraid's main tab, it looks to be online. I can even perform a SMART test on it, and it passes. But I can do nothing with the disk until I bounce my server. I've tried replacing the SATA cable, swapping to another SATA controller, etc. But the problem persists. The disk is always readable after a bounce, but then eventually becomes inaccessible, and I have no idea why. Physically, the disk seems fine. In Krusader, the disk (disk9) just becomes a file icon. In Unraid's main window, after trying to access it, it looks like it's spun up OK: If I run a SMART test at this point, it passes OK. I've attached my log and am keen to know what to try next. Thanks all. unr1-diagnostics-20260119-1153.zip

That's just one of the depreciated options. Look for any of the options listed here: https://community.openvpn.net/openvpn/wiki/DeprecatedOptions (thanks to binhex for the link) Remove anything from your .ovpn file that is in the list of removed options.

First, a banana would know exactly how to fix this 😁 Second, what is showing in your logs?

Yes, exactly like that! 😆 Thank you - that will be most helpful to anyone else looking for the offending option in their .OVPN file. Would have been nice if the OVPN devs had coded their app to ignore depreciated options rather than throw a king-sized spanner in the works. But then, I admit to being a pleb who knows diddly squat about how these things work 😜

Thanks mate, you too. I can't help but think that if there was a list of the depreciated .ovpn entries somewhere, we all might have found our solutions a bit quicker/easier. It's very interesting to read through this thread and see the different entries that have affected different people, presumably depending on what VPN provider they're using. There must have been quite a large number of depreciated features in this particular update to have affected a number of us like it has.

Yes, I figured this out too, as per my earlier post:

I only saw the same error in the supervisord.log file without the detail I needed. However, I ended up finding it by a process of elimination, commenting out one line at a time. I use ExpressVPN and for me it was the entry: keysize 256 Commented that out with # and I'm up and running again. Seems like an unlikely culprit, but there you go.

Same issue here since the latest update. Can someone guess which option might be unrecognised in my .ovpn file? Or is there a list of depreciated options in this latest version somewhere so I can figure it out for myself? Here's the config in my .ovpn file: dev tun fast-io persist-key nobind remote (Hidden) remote-random pull comp-lzo no tls-client verify-x509-name Server name-prefix ns-cert-type server key-direction 1 route-delay 2 tun-mtu 1500 fragment 1300 mssfix 1200 verb 3 cipher AES-256-CBC keysize 256 auth SHA512 sndbuf 524288 rcvbuf 524288 auth-user-pass credentials.conf Any help would be most appreciated.

Yep, just found this out the hard way after installing it myself. Removing it for a better option...

Yep, that's the same thing I tried (see above). Unfortunately, I need btrfs because I want redundant disks and it didn't seem to help.