SudoPacman

Anyone else having trouble with the MEGAsync container failing to login today? Nothing much in the logs, but thought I'd ask before digging further. Cheers Edit: Turns out the container was having DNS issues.

Heard back from support. I suspect it might be due to differing versions of MEGA between the originator and the importer. I guess I'll see how it goes over the next few days... if it persists I'll try grabbing the debug logs. Response here:

Cool, thanks. I'll take a look at that changelog and perhaps raise an issue there if cannot find it already being reported.

Sorry, the MEGAsync one.

Hi ich! I've been getting lots of issues in the last few days with errors indicating "File fingerprint missing". If I resolve them I seem to get three copies of each file in the download queue. Quite strange. I have a feeling it's working fine for files that are in sub-directories though, but that could be coincidental. Any ideas? Cheers

Got an update on this in case anyone else experiences the same thing. In a nutshell, it kept happening. I'd get through a preclear, then add parity and boom, at some point during the rebuild. This is on a practically new supposedly enterprise class 16TB drive, so I was suspicious. A mate at work suggested it could be PCIe lanes, since I'm using an older Intel i7 970 and X58 platform, and during a rebuild there is a lot of strain on the system, and I have a lot of drives (10 data plus 2 parity and 2 SSDs). I've been thinking about an upgrade for a while, and have now pulled the trigger on an AM5 based build on an X670. Expensive, but it's crucial to me that I can trust my server. Just finished a parity rebuild, and all seems good. Hope this helps someone else. Cheers, Pacman

When future me finds this, again, perhaps I should note the answer rather than have to rediscover it. If set the IP of the network interfaces to automatic, and fix them in your DHCP server, the docker networks get their gateway set correctly. I changed motherboard, so the MAC address changed, so that's what caused it. Feels like a bug, but the workaround is fine.

So, no additional failures yet, so that's good. Last time it happened when the parity check kicked off at the start of the month, so will report back with how that goes, and with the syslog capturing enabled. Cheers

Ah, just found the mirror syslog setting. Will try that!

Okay, so changed cables, and the drive has been through a complete pre-clear, with pre-read and post-read and all looking good. This is what happened last time though... I'm going to add it as a second parity drive and let it build. I suspect it'll all go fine, and then next month during the scheduled check it'll fail, but let's see! You said the syslog did not contain any information on why the drive got marked as having read errors. Is this because it did not go back far enough? Anyway to increase how far back is recorded perhaps? Cheers

Thanks. Just ordered some new cables, so should have them in tomorrow. Cheers

Hi guys, After a little support here please, since this is the newest drive in my machine, and "has read errors" so has been disabled. I have replaced one set of SAS cables the other month, but there is another set that could be replaced if warranted. I'm confused in that you don't seem to get much information about what unraid thinks the issue is, other than has errors so has been disabled, unless I am just missing it from the logs or diagnostics. It looks okay from a SMART point of view, which worries me from an RMA point of view. It also went through the complete pre-clear process without issue. Any help appreciated. Cheers, Pacman monty-diagnostics-20230501-1020.zip

I've just started getting this error since upgrading to 6.11.1, and it's filling my logs up. I'm getting it within a sparsebundle folder created on a Time Machine share. I've tried moving the directory so the backup creates a new one, but it's still occurring...

I'm doing the same once the preclear finishes on my two new 14Tb drives. What did you go for in the end, swapping one or both? If one which parity went first (I assume the second one)? Cheers

Okay, thought I'd try your rtorrentvpn docker and same thing (just times out), which has led me to my opnsense firewall live view. Looks like an update there may have done something since I can see it getting blocked by the "default deny rule". Thanks for your help binhex, I really appreciate it (and love your dockers). I'll report back, but sure it's something this end now. Cheers