SudoPacman

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

Yeah, am setting the WEBUI_PORT, I'll double check the -p switch though. Cheers

Nope, no dice. Tried changing the port back to the default 8080 and still no luck. I realised that 8080 is available on br0 after all, but not some others. I'm out of ideas.

Yeah, I thought it looked clean too. No errors or anything. Strange. Tried different browsers, machines, OSes. Rebooted. Everything i can think of. No, nothing has changed wrt to network or vlans. It's all been setup for months and months now! It's on br0 and always has been. I've tried changing to bridge but see the same thing. I wonder whether forcing a reinstall of the docker image is worth trying? Is that just a case of removing it and adding it again?

Been using this for months without issue, and then the last few days I cannot access the UI after starting the docker. I've tried renaming the appdata folder for it (copying the openvpn config into the new one it creates), and renaming the torrent and complete/incomplete folders in case that's a factor. Something weird is going on. I've also tried with debug on but that doesn't yield any clues. The last entry in the log is: 2021-10-15 11:45:33,020 DEBG 'watchdog-script' stdout output: [info] qBittorrent process started [info] Waiting for qBittorrent process to start listening on port 8117... 2021-10-15 11:45:33,131 DEBG 'watchdog-script' stdout output: [info] qBittorrent process listening on port 8117 2021-10-15 11:45:33,155 DEBG 'watchdog-script' stdout output: [debug] VPN incoming port is 54846 [debug] qBittorrent incoming port is 54846 [debug] VPN IP is 10.3.112.113 [debug] qBittorrent IP is 10.3.112.113 2021-10-15 11:45:33,628 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '54846' 2021-10-15 11:46:03,163 DEBG 'watchdog-script' stdout output: [debug] Checking we can resolve name 'www.google.com' to address... 2021-10-15 11:46:03,190 DEBG 'watchdog-script' stdout output: [debug] DNS operational, we can resolve name 'www.google.com' to address '142.250.187.228' 2021-10-15 11:46:03,191 DEBG 'watchdog-script' stdout output: [debug] Waiting for iptables chain policies to be in place... 2021-10-15 11:46:03,200 DEBG 'watchdog-script' stdout output: [debug] iptables chain policies are in place Does anyone have any ideas? Has there been a recent update that may have affected anything? I am trying direct access, so no reverse proxy or anything like that to consider. Cheers, Pacman PS: Oh, and if I access the console for the docker I cannot see anything going nuts in "top".

Hi, Could use a little help getting homebridge to work on a custom network type please. When I first installed homebridge I used the default Host network, got the UI up, logged in, and tried adding the homebridge to my Home app. It didn't work - it appeared to timeout. I'm guessing this might be because my Apple TV, and many other devices are on an IoT VLAN (including the Sonos Play:3 that I want to use homebridge for). I have a network setup that some dockers can use to be on the same vlan. This is br0.3. It works fine with the dockers I have tried it on, but when I try and switch the homebridge to this network it appears to do nothing. I get no IP in the docker list, no logs. If I delete the homebridge folder in appdata it gets recreated but no config.json created. Any ideas what's going on? Has anyone got it running on a different network type other than host? Cheers, Pacman Edit: If pick br0 and fix the ip to something in the main LAN network I can access the UI. Still no dice on br0.3 though, even when fixing IP.

I'm seeing the same thing, so will watch this thread with interest. I'll try and look into it more tomorrow perhaps. Late now!

Oh, changing the host from 'bitwardenrs' to the internal ip of my unraid box has sorted it, which is odd, since sure I have tried that...

I would be interested in seeing your proxy config from Nginx Proxy Manager, since I'm in exactly the same boat. I've searched and searched, looked at all kinds of examples, tried adding environment vars to change the web socket port, and it just will not work through the proxy. Works fine using internal IP. I have loads of reverse proxies working in SWAG, but cannot get this one to work. I tried migrating to NPM a few months back but it kept on corrupting configs for some bizarre reason so gave up on it. Cheers

Worked a treat for me! Thank you very much!

Thanks, much appreciated! I'm guessing that similar might be happening with Sonarr soon too then?

Okay, glad it's not just me then. I'm guessing you're on the case! Thanks!