Lignumaqua

Server very dead, would appreciate help. I think it’s recoverable but I don’t know how. Here's what happened. 1. All running fine. Using 2 x 4TB parity disks and 7 x 4Tb data disks. 2. Need to increase size so add new 8TB disk with intention of this becoming new parity disk. 3. Stop array and disable parity disk 2 4. Start array with one 4TB parity disk 5. Stop array and designate 8TB disk as new parity disk (replacing 4Tb drive) 6. Start array. Parity rebuild automatically restarts. Life is good. 7. A few hours in to the parity rebuild, errors show up on disk 6 and parity rebuild fails. I still have the original 2 parity disks in the system as unassigned devices and untouched. Can I reassign them as the parity and rebuild the data on the now failed disk? As it is the whole array is stalled. 😞

And he has! 😃 Thanks Squid, all your hard work is much appreciated.

Yes, see my post above. This had been working fine but broke when the single quotes were replaced with ' in mid March. Unfortunately some (all?) browsers treat this as a quote which breaks the Javascript. I had to edit the strings in tests.php to remove the apostrophes before I could get it to work. I'm sure Squid will post an update.

FYI - I was able to fix this (well, mask it really, I didn't fix the root problem) by editing the two addWarning() strings in tests.php to remove the apostrophes, and deleting ignoreList.json again. The strings now read 'The unRaid built in FTP server is currently disabled, but users are defined' and 'The unRaid built in ftp server is currently running'. The buttons now work as expected. Any other error strings with apostrophes likely still have the same problem.

Thanks, but I've tried that. In fact I deleted everything and started again. Still has this problem I'm afraid, the single quotes in these two error fields break the JavaScript 'Monitor Warning/Error' buttons. Version installed is 2021.03.24

Looks like 'unRaid's built in FTP server is running' has the same problem. The 'Monitor Warning/Error' button doesn't work because of the single quote/apostrophe breaking the JavaScript. Any suggestions on how to fix this?

Recently I've been getting the 'unRaid's built in FTP server is currently disabled, but users are defined' warning every day. I've tried adding it to the ignored list it but it doesn't help. So, I thought I'd try UNignoring it and then REignoring it. However the 'Monitor Warning/Error' button doesn't work. Looking in the browser console I can see why. There is an unescaped apostrophe which is breaking the JavaScript. This is the line: <input type="button" id="1360801943" value="Monitor Warning / Error" onclick="readdError("unRaid" s= built in ftp server is currently disabled, but users are defined&quot;,this.id);'<td> Looks like the apostrophe in the text unRaid's built in ftp server isn't being dealt with correctly which leads to an 'Uncaught SyntaxError' when the button is clicked.

@NeoSys - You aren't being clear, but just to try and clarify what I think is going on here if your 'issue' is with PIA. 1. PIA's support for OpenVPN V2.5 is very spotty and varies from server to server. 2. I also think this is changing as they upgrade servers, so a server that worked yesterday might not today, or vice-versa. 3. As far as I can tell, best advice right now, no matter what cipher you are using, is to make sure you have the 'ncp-disable' line in your ovpn file. It might work without on some servers but it's a dynamic situation. 4. Also make sure you are using your PIA login username and password which start with p--------, not the SOCKS one.

I don't think so I'm afraid - at least, not for all servers. The nextgen 2.4+ ovpn file from the config file generator for the Bahamas server is essentially the same as the zip file version, and doesn't work without adding in npc-disable.

Update: I was able to make this work by adding the 'ncp-disable' flag to the ovpn file. Not really a great solution, but it allows use of the latest version of the Docker. No other changes or additions needed to the ovpn file as downloaded from PIA, just adding this directive. It's a cheat as it stops any renegotiation of ciphers and forces use of the one defined in the (deprecated) 'cipher' directive so will likely fail again in the future. I've also seen posts elsewhere that suggest this does indeed vary by PIA server and that the Toronto server is the best behaved at the moment. 🤨

No, I've tried both with and without it with no change. The 'cipher' parameter is actually deprecated in the latest version (2.5) of OpenVPN so it should no longer be used. The previous versions of this Docker used the older (2.4) OpenVPN where that was used. The move to V2.5 also changed which default ciphers were used. I think this is the core of the problem. The PIA servers are strangely configured and not well behaved in dealing with a V2.5 client. We aren't the only ones with this problem with PIA:

Here's the file. This is Bahamas.ovpn with the edits to the cipher lines. Still get the BF-CBC failure. (Note : I've been testing with both this Docker and your companion qbittorrentvpn Docker. Could they be behaving differently? Most of my testing has been with qbittorrentvpn as I use Privoxy with that one but I've had the same issues with both. I can't swear to have tried every combination with both of them though. 🤔) client dev tun proto udp remote bahamas.privacy.network 1198 resolv-retry infinite nobind persist-key data-ciphers-fallback aes-256-gcm auth sha1 tls-client remote-cert-tls server auth-user-pass credentials.conf compress verb 1 <crl-verify> -----BEGIN X509 CRL----- MIICWDCCAUAwDQYJKoZIhvcNAQENBQAwgegxCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJDQTETMBEGA1UEBxMKTG9zQW5nZWxlczEgMB4GA1UEChMXUHJpdmF0ZSBJbnRl cm5ldCBBY2Nlc3MxIDAeBgNVBAsTF1ByaXZhdGUgSW50ZXJuZXQgQWNjZXNzMSAw HgYDVQQDExdQcml2YXRlIEludGVybmV0IEFjY2VzczEgMB4GA1UEKRMXUHJpdmF0 ZSBJbnRlcm5ldCBBY2Nlc3MxLzAtBgkqhkiG9w0BCQEWIHNlY3VyZUBwcml2YXRl aW50ZXJuZXRhY2Nlc3MuY29tFw0xNjA3MDgxOTAwNDZaFw0zNjA3MDMxOTAwNDZa MCYwEQIBARcMMTYwNzA4MTkwMDQ2MBECAQYXDDE2MDcwODE5MDA0NjANBgkqhkiG 9w0BAQ0FAAOCAQEAQZo9X97ci8EcPYu/uK2HB152OZbeZCINmYyluLDOdcSvg6B5 jI+ffKN3laDvczsG6CxmY3jNyc79XVpEYUnq4rT3FfveW1+Ralf+Vf38HdpwB8EW B4hZlQ205+21CALLvZvR8HcPxC9KEnev1mU46wkTiov0EKc+EdRxkj5yMgv0V2Re ze7AP+NQ9ykvDScH4eYCsmufNpIjBLhpLE2cuZZXBLcPhuRzVoU3l7A9lvzG9mjA 5YijHJGHNjlWFqyrn1CfYS6koa4TGEPngBoAziWRbDGdhEgJABHrpoaFYaL61zqy MR6jC0K2ps9qyZAN74LEBedEfK7tBOzWMwr58A== -----END X509 CRL----- </crl-verify> <ca> -----BEGIN CERTIFICATE----- MIIFqzCCBJOgAwIBAgIJAKZ7D5Yv87qDMA0GCSqGSIb3DQEBDQUAMIHoMQswCQYD VQQGEwJVUzELMAkGA1UECBMCQ0ExEzARBgNVBAcTCkxvc0FuZ2VsZXMxIDAeBgNV BAoTF1ByaXZhdGUgSW50ZXJuZXQgQWNjZXNzMSAwHgYDVQQLExdQcml2YXRlIElu dGVybmV0IEFjY2VzczEgMB4GA1UEAxMXUHJpdmF0ZSBJbnRlcm5ldCBBY2Nlc3Mx IDAeBgNVBCkTF1ByaXZhdGUgSW50ZXJuZXQgQWNjZXNzMS8wLQYJKoZIhvcNAQkB FiBzZWN1cmVAcHJpdmF0ZWludGVybmV0YWNjZXNzLmNvbTAeFw0xNDA0MTcxNzM1 MThaFw0zNDA0MTIxNzM1MThaMIHoMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0Ex EzARBgNVBAcTCkxvc0FuZ2VsZXMxIDAeBgNVBAoTF1ByaXZhdGUgSW50ZXJuZXQg QWNjZXNzMSAwHgYDVQQLExdQcml2YXRlIEludGVybmV0IEFjY2VzczEgMB4GA1UE AxMXUHJpdmF0ZSBJbnRlcm5ldCBBY2Nlc3MxIDAeBgNVBCkTF1ByaXZhdGUgSW50 ZXJuZXQgQWNjZXNzMS8wLQYJKoZIhvcNAQkBFiBzZWN1cmVAcHJpdmF0ZWludGVy bmV0YWNjZXNzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPXD L1L9tX6DGf36liA7UBTy5I869z0UVo3lImfOs/GSiFKPtInlesP65577nd7UNzzX lH/P/CnFPdBWlLp5ze3HRBCc/Avgr5CdMRkEsySL5GHBZsx6w2cayQ2EcRhVTwWp cdldeNO+pPr9rIgPrtXqT4SWViTQRBeGM8CDxAyTopTsobjSiYZCF9Ta1gunl0G/ 8Vfp+SXfYCC+ZzWvP+L1pFhPRqzQQ8k+wMZIovObK1s+nlwPaLyayzw9a8sUnvWB /5rGPdIYnQWPgoNlLN9HpSmsAcw2z8DXI9pIxbr74cb3/HSfuYGOLkRqrOk6h4RC OfuWoTrZup1uEOn+fw8CAwEAAaOCAVQwggFQMB0GA1UdDgQWBBQv63nQ/pJAt5tL y8VJcbHe22ZOsjCCAR8GA1UdIwSCARYwggESgBQv63nQ/pJAt5tLy8VJcbHe22ZO sqGB7qSB6zCB6DELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRMwEQYDVQQHEwpM b3NBbmdlbGVzMSAwHgYDVQQKExdQcml2YXRlIEludGVybmV0IEFjY2VzczEgMB4G A1UECxMXUHJpdmF0ZSBJbnRlcm5ldCBBY2Nlc3MxIDAeBgNVBAMTF1ByaXZhdGUg SW50ZXJuZXQgQWNjZXNzMSAwHgYDVQQpExdQcml2YXRlIEludGVybmV0IEFjY2Vz czEvMC0GCSqGSIb3DQEJARYgc2VjdXJlQHByaXZhdGVpbnRlcm5ldGFjY2Vzcy5j b22CCQCmew+WL/O6gzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBDQUAA4IBAQAn a5PgrtxfwTumD4+3/SYvwoD66cB8IcK//h1mCzAduU8KgUXocLx7QgJWo9lnZ8xU ryXvWab2usg4fqk7FPi00bED4f4qVQFVfGfPZIH9QQ7/48bPM9RyfzImZWUCenK3 7pdw4Bvgoys2rHLHbGen7f28knT2j/cbMxd78tQc20TIObGjo8+ISTRclSTRBtyC GohseKYpTS9himFERpUgNtefvYHbn70mIOzfOJFTVqfrptf9jXa9N8Mpy3ayfodz 1wiqdteqFXkTYoSDctgKMiZ6GdocK9nMroQipIQtpnwd4yBDWIyC6Bvlkrq5TQUt YDQ8z9v+DMO6iwyIDRiU -----END CERTIFICATE----- </ca> disable-occ

I've now tested every combination of 2048 and 4096 certificates and associated ovpn files with and without the extra data-ciphers-fallback aes-256-gcm or data-ciphers-fallback aes-128-gcm and none of them work. They all give the same errors. Rolling back to 3.1.0-1-02 (for this Docker) or 4.3.0-1-04 (for the sister qbittorrentvpn Docker) is the only way I've found to get this working again. I wonder if different PIA servers are behaving differently? Quite possible I guess. I'm using the Bahamas server to use port forwarding. Maybe the Toronto one you are using is behaving differently?

Unfortunately this and GitHub A22 didn't help. Same problems as before. The only think that works for me is reverting to the prior build. I note that you say to use the 4096 crt and pem files certificates. Where did you get those from? The only ones in nextgen.zip are the 2048 versions. What am I missing here?

Thank you. FWIW I had tried adding a data-ciphers-fallback line but still had issues. However I was using data-ciphers-fallback aes-128-cbc and still got the message about using BF-CBC I'll try again later today. Your support is much appreciated! 🙂

Change the repository to add the specific tag for the version you want. In the case of this Docker that is binhex/arch-sabnzbdvpn:3.1.0-1-02 PS - I think this is fundamentally a PIA problem, not binhex's, but this gets around it for now. Not a long term solution...

Tried everything here, every cipher listed, and nothing worked. Seems there might be some incompatibility between PIA and OpenVPN 2.5? Reverted Docker to previous release from 10 days ago and all is working again. Of note I think is that the OVPN files from PIA, even the NextGen ones, use the deprecated cipher instruction as opposed to the new data-ciphers.

Ah, thank you. I misinterpreted the 'incompatible' error message to mean that it had updated, but the new version was incompatible. Now I see that it didn’t actually update. My mistake, apologies.

For those of us stuck on 6.6.7 until the slow array performance is fixed in 6.8, is there a way to revert FCP to the prior version?

First let me say that I'm not complaining, I appreciate all the great work you do for the Unraid community, this is just an FYI. For my system, this version is much slower than the prior. V1 used to take about 3 minutes to run a nightly incremental backup whereas V2 now takes about 30 minutes to do a full, uncompressed, backup of the same data. My data doesn't change very much from day-to-day so an incremental was ideal. Having just seen the post above on how to exclude the Plex cache folder, I'll try that and see how much it helps.