• Content Count

  • Joined

  • Last visited

Community Reputation

10 Good

About weirdcrap

  • Rank


  • Gender

Recent Profile Visitors

1367 profile views
  1. Yeah I'm going trying to take a step by step approach to identify the issue. I changed SATA ports today, if it is still acting up we'll swap power connections. I had my tech confirm this is the one drive on a MOLEX to SATA adapter due to the last SATA plug not being long enough. So that may be the culprit and I'll try replacing it next.
  2. 5.0.2 fixed my inability to add any servers to the app with the Object Object error.
  3. Didn't last long, back at with just some read errors now. it was only a few days after and the disk dropped last time so I imagine its going out again soon. Jul 17 18:13:53 Node kernel: sd 1:0:0:0: [sdb] tag#26 ASC=0x11 ASCQ=0x4 Jul 17 18:13:53 Node kernel: sd 1:0:0:0: [sdb] tag#26 CDB: opcode=0x88 88 00 00 00 00 02 47 d0 00 d0 00 00 00 08 00 00 Jul 17 18:13:53 Node kernel: blk_update_request: I/O error, dev sdb, sector 9794748624 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Jul 17 18:13:53 Node kernel: md: disk5 read error, sector=9794748560 Jul 17 18:13:53 Node kernel: ata1: EH
  4. Cables replaced, power cable seating checked, rebuilding to the same disk now. So far so good, fingers crossed that was it. EDIT: Rebuild completed successfully. I will monitor and report back if this becomes a problem again.
  5. It passed SMART. I believe this disk runs directly off the PSU power so no splitters or anything. I can try having someone replace the SATA cable but I am honestly terrified that if this is a cabling/power issue swapping cables with another drive is going to drop a different disk from the array, breaking parity all together. If I try to rebuild to the same disk and it drops off again will UnRAID just re-disable the disk? Or will it break parity? This is a remote server so infuriatingly I cannot troubleshoot this problem myself without a 6 hour round trip tha
  6. I had disk5 in my array throw a random smattering of read errors earlier this week and wrote it off as nothing significant after the disk passed a long and short smart test. Well it just magically dropped off out of the blue and it almost looks like the controller took the link down rather than the drive died? Jul 15 13:18:47 Node kernel: Jul 15 13:19:21 Node kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jul 15 13:19:21 Node kernel: ata1.00: configured for UDMA/133 Jul 15 14:13:09 Node kernel: ata1: COMRESET failed (errno=-32) Jul 15 14:13:09 Node kerne
  7. So because I'm an idiot I started a run of the unbalance plugin to move files off a drive so i can drop it from the array, then had to stop it because I included a disk I didn't mean to. rsync created empty directories on the destination disks first so I now have a bunch of empty folders on the /mnt/disk* shares that don't correspond to the actual location of the data. I would like to delete the empties but am looking for a sanity check to make sure my methodology is sound and I'm not going to break things.
  8. This is still very much broken for me. Right now no matter how many times I restart the transfer or the servers I can't even top 100KB/s. My current file is running at 1.5KB/s, it's disgusting how badly this runs. If I find time this weekend I'm going to go bother the wireguard devs on IRC and see if they have any ideas. I really really want this to work but in its current state it is unusable.
  9. Well since you're not having the overwrite issue that tells me there must be something wrong with my container. I'll probably scrub the container and it's appdata directory and try again from scratch. EDIT: Well even after starting over with the container from scratch it is still overwriting my wg0.conf file... I don't get how the exact same container can perform so differently on two different servers. EDIT2: The only remaining difference I have yet to test is the iptables mangle support. NODE has it enabled as rtorrent is externally accessible while VOID d
  10. Did you have any luck editing your AllowedIPs in the wg0.conf file like Binhex suggested? I'm curious if there is something wrong with my container that's causing that line to be overwritten every time I restart the container.
  11. I stopped the container and edited the AllowedIPs as indicated. It looks like your wireguard startup script is overwriting the allowed line I set as I go back into the file after starting the container and it has been changed back to Seems quite odd to me that this affects only NODE and not VOID despite them both using WireGuard....Could it be my "non-standard" LAN IP? Not that I can do anything to change the .20. network as it isn't mine, it just seems odd that the issue isn't consistent across multiple servers...
  12. So I'm having an odd issue with only one of my two rtorrentvpn containers. When using WireGuard as the connection type on my server NODE, I cannot access the rutorrent web interface using the local unraid server IP (it just spins and times out). I can however access it externally through my reverse proxy via HTTP / RPC without any issues. What's even stranger is if I switch back to using OpenVPN as my connection method I can access the web interface locally again. I don't see anything error wise in the logs that would suggest what is wrong... My
  13. I think you can just copy your \\tower\cache\appdata\CONTAINER_NAME\rtorrent\session folder contents into the session folder of the new container. There may be differences in your config and file structure so you may have to resolve those manually or make sure your paths and config are identical between the new and old containers before you copy the session data.
  14. What I was trying to point out earlier is that rutorrent is part of the rtorrent docker I mentioned. rtorrent on its own is a command line torrent client, binhex's container includes both the main command line rtorrent client AND the rutorrent web frontend. From binhex's github: "...this Docker image includes the popular ruTorrent web frontend to rTorrent for ease of use." Crazymax's stuff is on docker hub, which can be searched through CA. However he/she does not appear to publish an rtorrent container of any kind, I only see qbittorrent:
  15. are you running an up to date version of UnRAID? It shows up for me on both of my servers: