ctietze

Members
  • Posts

    10
  • Joined

  • Last visited

Everything posted by ctietze

  1. I checked the history after the process finished -- you're right, I forgot the trailing `1`! Overall, there's been some stuff in lost+found that's annoying to sort back. The new cable to disk1's location in the case seems to have fixed it. So I probably just broke the SATA cable 😵‍💫
  2. xfs_repair can't find any block at the moment anyway, so my current plan is to rebuild the replacement disk from parity instead. If the former disk1 would spit out the remaining files, that'd be a bonus, but in the worst case, we can live without what was left on the disk.
  3. Actually no: Mounting the former disk1 drive via USB put it into the sdh1 slot. Should've copied the same log message from before removing the disk. Sorry for the confusion!
  4. Replaced cables (the one to disk1 was awkwardly bent I noticed) and tried to move the remaining files off of the disk with unBALANCE because accessing these used to trigger the errors. Some files have moved over night, but in the morning, xfs warned me I should run `xfs_repair`, and it turns out the file system is now unmountable. Jan 18 08:31:38 NASminion kernel: XFS (sdh1): Corruption detected. Unmount and run xfs_repair Jan 18 08:31:38 NASminion kernel: XFS (sdh1): Internal error xfs_trans_cancel at line 1097 of file fs/xfs/xfs_trans.c. Caller xfs_efi_item_recover+0x16a/0x1a8 [xfs] Jan 18 08:31:38 NASminion kernel: CPU: 3 PID: 14957 Comm: mount Tainted: P O 6.1.64-Unraid #1 Jan 18 08:31:38 NASminion kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J5040-ITX, BIOS P1.60 01/17/2020 I love the `Hardware name: To Be Filled By O.E.M.` I'm installing a replacement drive in disk1's place now and try to repair and recover what I can from the old one.
  5. Thanks for looking @JorgeB! So to summarize: the kernel-reported ATA errors are more about unresponsiveness and timeouts, not about disk errors? Found researching the codes a bit tricky. (ChatGPT helped a bit though) Did you infer that they use different controllers from the ID's/codes like 13:0... etc? I'll check the power cables and swap them and SATA cables next. I do wonder whether disk2/3/4 being good are false positives: the errors only occur when I'm trying to access parts of disk1, not all of it (90% of unbalancing worked at ~200mb/s until it slowed to a crawl), I wonder why that might be if it's a power thing. Since each change to disk1 also needs to update parity, is there a way to figure out if the access to disk1 or to parity is the real culprit, or are really both affected independently? I would imagine that moving multiple TB of data from a 'good' disk, maybe disk2, should then produce ata8/parity errors, but should not report errors for disk2 (ata7). Would that make sense to verify it's parity on ata8?
  6. Hi, I upgraded my drives to 12TB Seagate IronWolf and WD Reds, but it appears two Seagate drives don't enjoy the experience so far. At least I believe it's the drives, not the cables. I only found one similar thread, and it was probably power splitters back then: I get similar messages at the moment for ata1 and ata8. Can't complete parity checks (kilobytes/s), so something's not good. I believe I identified the culprits via lshw -class disk -short and ls -l /sys/class/ata_port/ to be * ata1: /dev/sdb ST12000VN0008-2Y disk1 * ata8: /dev/sdg ST12000VN0008-2Y parity Spoiler contains the raw output that led me to the conclusions. It's quite tricky to identify ataX numbers and also the drives I wired 😬 Parity fails a bit differently than disk1, with "found unknown device (class 0)" errors in the end of a failure cycle. I've removed disk1 from the Global Shares to not put more data onto it. I've checked the SATA cables. One did 'click' a bit deeper, actually, but that didn't change anything. SMART report produced no errors. I've used xfs_repair and it found issues on disk1, but no other data drive. Parity can't be checked that way because it has no file system. But I'd love to! Any ideas? I've used the unbalance app to move all but 100GB of data off of the 12TB drive (was very new and not very full). During the process, the log spawned problems like this again and the device audibly clicks and seems to spin up a disk again and again. Someone suggested this might also be a SATA card in the PCIe slot that fails. I wouldn't know how to test this, though, without 'blindly' buying more equipment to check replacements. Anything else I might try to diagnose? Log in the spoilers: I'd appreciate any other hints: How would you interpret these issues, for example?
  7. Klassiker: nach 3h Inspektion ohne Erfolg sind die 5min nach Posten die Lösung Habe in /mnt/user/appdata/swag/log/nginx/ in der error.log z.B. das gefunden: 2023/02/15 14:48:59 [error] 500#500: *9 no resolver defined to resolve freshrss, client: 172.19.0.2, server: freshrss.*, request: "GET / HTTP/1.1", host: "freshrss.MYDOMAIN.XYZ" In der swag resolver.conf dann den Eintrag auskommentiert; die IPv6 spawnte allerdings kritische Fehler, also reduziert auf: resolver 127.0.0.11 valid=30s; Nun geht's 👍
  8. Hi, wir sind umgezogen und haben statt Vodafone/UnityMedia via Kabel jetzt Telekom DSL und einen Speedport Smart 4 Router. Nach 2 Wochen habe ich die Unraid NAS jetzt zum ersten Mal wieder richtig in Betrieb nehmen können. cloudflared für den Argo Tunnel geht soweit durch, dass ich auf meine bei Cloudflare registrierte Domain direkt zugreifen kann -- aber keine meiner Subdomains funktioniert mehr. Nextcloud, FreshRSS, etc. produzieren alle "502 Bad Gateway" Fehler. Ich habe die Konfigurationen in Swag aktualisiert, und die nginx .conf Dateien pro Container soweit auch. Auf FreshRSS kann ich via Unraid's LAN IP auch prima Zugreifen. (Nextcloud ist eh etwas biestiger weil ich die kanonische URL dort angegeben hab un Nextcloud entsprechend einen Redirect vornimmt.) 192.168.2.100:8099 für FreshRSS geht also super, freshrss.MYDOMAIN.XYZ nicht, während auf MYDOMAIN.XYZ selbst Swag wiederum normal antwortet und die Willkommensnachricht ausgibt. Am Router sollte es damit dann wohl auch nicht liegen. Vom Swag Container aus kann ich die anderen Container via Namen auch erreichen: `docker exec swag ping freshrss` klappt einwandfrei. Das proxy-net scheint also auch nicht falsch konfiguriert zu sein. Ich finde im Swag log nichts, was die 502 Bad Gateway Meldung erklären würde. Da kommt einfach keine Meldung nach "Server ready". Ebenso in FreshRSS nicht. Ich wüsste gern, wo der 502 herkommt, wenn kein Log etwas anzeigt, bin da aber ratlos. Danke für Ideen und Tips schon mal!
  9. I have trouble making outgoing connections from inside the Docker proxy net (not using the Unraid bridge). curl -I google.com works curl -I some.dyndns.for.same.lan fails (e.g. cloudpi.dns.navy, a test device on a Raspberry Pi) curl -I -x swag:80 some.dyndns.for.same.lan works E.g. when I open the console for the SWAG container and try to access a Raspberry Pi that's connected to the web: # curl -Iv cloudpi.dns.navy * Trying 37.201.145.221:80... * Trying 2a02:908:4b60:a2e0:ba27:ebff:fe83:4fe:80... * Immediate connect fail for 2a02:908:4b60:a2e0:ba27:ebff:fe83:4fe: Address not available * Trying 2a02:908:4b60:a2e0:ba27:ebff:fe83:4fe:80... * Immediate connect fail for 2a02:908:4b60:a2e0:ba27:ebff:fe83:4fe: Address not available This is puzzling me a lot. If you copy and paste the CURL command, you'll notice that this will work fine from a regular computer. (Maybe even from your own Unraid SWAG instance? Dunno) If I define a proxy parameter in the request, this works out better: # curl -I -x swag:80 cloudpi.dns.navy HTTP/1.1 301 Moved Permanently Server: nginx/1.18.0 Date: Fri, 22 Jan 2021 11:10:48 GMT Content-Type: text/html Content-Length: 169 Connection: keep-alive Location: https://cloudpi.dns.navy/ The same -x parameter makes the CURL request reach the destination device from my SWAG container and my Nextcloud container. I can't get it to work with a https:// URL when I specify swag:443 as the proxy. I get a 400 Bad Request by SWAG. Same for -x swag:443 https://google.com, so the port 443 forwarding isn't limited to my DynDNS. I went down the CURL rabbit hole because my Nextcloud could connect to an instance I hosted on my web server, but not to the device with the dns.navy URL (it is in the same LAN). I don't know anybody with a DynDNS Nextcloud instance to try to figure out what may be going wrong. Am I holding it wrong? Is there any other debugging tool for this I could use? nslookup works, ping works, curl doesn't -- and to that extend connecting Nextcloud instances here don't work either.