Jump to content

sundown

Members
  • Posts

    34
  • Joined

  • Last visited

Posts posted by sundown

  1. 5 hours ago, binhex said:

    completely expected, this image is highly locked down to prevent ip leakage, you will not be able to connect to an ip on your lan with port 2469 from within the container, what is the problem you are trying to solve?.

    Attempting to call, via qbittorrent's "run external command" functionality, an API call from another container (cross-seed) to check if a torrent can be cross seeded at the torrent's completion.  The command is:  curl -XPOST http://ipaddress:2468/api/webhook --data-urlencode "name=%N".  I was hoping that the LAN_ADDRESS worked both inbound and outbound - but appears to only impact incoming requests to qbittorrent (for the UI).  Do I have any options?

  2. 21 hours ago, H2O_King89 said:

    Found my fix. I tried using the ip address of the server with no luck then i tried the docker ip and that worked. I tried pinging cross-seed and could not find it. I added the ip address the other dockers use for a name server 127.0.0.11. now I can use hostnames

    Could anyone provide additional information here?  @H2O_King89 when you mention "tried the docker ip" - are you referring to the docker internal addresses (in my case 172.17.x.x)?  To clarify, I'm also attempting to run a Crossseed command (identical to the one quoted here).  I have my LAN_NETWORK correctly set to 192.168.2.0/24 and have NO problems reaching the webUI from my home network (192.168.2.x) (not to be confused with the other user's issues here).  However running "nc -zv 192.168.2.222 2468" from qbittorrent's command line returns a "connection timeout."  Executing this from any of my other dockers succeeds.

    image.png.8538b838e30e9d66e6945664eb2f5825.png

  3. Within the last 24hrs, I've had 2 12TB drives either go disabled or throw so many errors to be non-functional.  Best I can figure it's just a fluke accident, as I've checked/replaced cables and there have been no other "events" that I have experience with that would have led to this type of failure.

     

    So at this point, I'm looking for the best approach to remediating the situation.  Based on the logs, I'll assume neither are salvageable/trustworthy, and will have to be replaced.  Unfortunately, replacements are still a few days out at this point.  I have had prior drives fail, and I've used unbalance to move the files off, remove the drive, rebuilt the array and then add a new drive back into the mix.  But with one failed and the other as good as, I'm unsure of the best approach.  Any input is appreciated.  Screenshot attached and diags as well:

    image.thumb.png.fb59007feda1ae1c9b83180277b72075.png

    unraid-diagnostics-20221130-1825.zip

  4. I have a need for dockers on two different docker networks to communicate with one another.  My situation is as follows:

     

    1. I run a "none" network for most media dockers that routes traffic through an "OpenVPN" container.
    2. I run an independent "qbittorrent-vpn" docker on my "bridge" network (that I'll eventually move across to my "docker-net" network when I get this situation sorted).

     

    There are apps (such as cross-seed and autobrr) that I need to have access to the qBittorrent-vpn docker.  I'm in search of a configuration/setup/command that allows routing across network, if possible.

     

    I've attempted creating a third network and connecting the containers therein, but I receive an error message that I'm unable to sort:

    Quote

    root@Unraid:~# docker network create centralnet
    5fd31e722ec31d6b9553cf97fdff5b910208b3a73fbcbf336f4955b499acf22a
    root@Unraid:~# docker network connect centralnet autobrr (works fine)
    root@Unraid:~# docker network connect centralnet OpenVPN-Client (fails due to "existing route")
    Error response from daemon: failed to add interface veth474d19f to sandbox: error setting interface "veth474d19f" IP to 172.22.0.2/16: cannot program address 172.22.0.2/16 in sandbox interface because it conflicts with existing route {Ifindex: 5 Dst: 128.0.0.0/1 Src: <nil> Gw: 10.8.0.1 Flags: [] Table: 254}

     

    Any input as to either an easier way to make this happen or troubeshooting steps for the error message above?

     

    Thanks.

  5. On 10/7/2022 at 10:16 AM, JorgeB said:

    Enable mirror to flash, just don't forget to disable it once it's not needed.

    I went a few days without a crash, and thought I was out of the woods, and this this morning - BAM.  Good news is, it looks like the flash syslog storage did indeed catch it.  Bad news is, to me as an idiot, I don't see anything else more insightful than I already posted.  I hope I'm wrong and you smart people spot something!  For good measure, I've also added the latest diagnostics.  Thanks for the follow-up, @JorgeB!

    syslog unraid-diagnostics-20221012-0812.zip

  6. 5 hours ago, JorgeB said:

    Enable the syslog server and post that after the next crash.

    Thank you for the response.

    Unfortunately I have it enabled, but without any types of results being recorded.  Yet another item I'm scratching my head over.  I went so far as to install a remote syslog server on another machine - but without it logging any events.  Had another event last night, continuing the trend.  The server remains responsive to pings and SSH, but won't shut down cleanly.  Config:

     

    syslog.jpg

  7. I had lived on 6.9.2 since release, upgraded to 6.10 and then almost immediately to 6.11 since I had a downtime window available.

     

    Unfortunately, it's resulted in some unexpected shutdowns/unavailability of my Unraid server.  The only hardware changes present were the addition of another 12gb drive to the array, and that happened while I was back on 6.10, and was less than 24hrs before I moved on to 6.11 (I was receiving an overtemp error message on my NVME that I had hoped would resolve itself - but ultimately I found another topic here that helped resolve that).

     

    Regardless, I'm now seeing a slow system degradation to the point of inaccessibility of my entire system.  It's a system that stays busy and doesn't sit around twiddling its thumbs, and until now has been rock solid.  I see at least some concerning errors in the syslog that share a resemblance to a current topic also being asked - but obviously wanting to start my own topic while keeping an eye on their resolution.

    To this end, I'm attaching my latest diagnostics (derived from the command line, while the shares were still luckily available, but during an "unavailable" event).  My obvious concern is the following statement in syslog: 

    Quote

    Oct  6 13:55:31 Unraid kernel: CPU: 8 PID: 16496 Comm: Disk Tainted: P           O      5.19.9-Unraid #1

    I'm not sure to make of this a CPU issue or an actual disk issue, as I can find no additional corollary insight based on my primitive understanding of Unraid.  Thus, could I ask the Unraid gods to take a look at my logs for areas where I may start troubleshooting?  Thank you.

    unraid-diagnostics-20221006-1552.zip

  8. I have been through the FAQs and done my fair share of searching, but I'm finding it difficult to accurately answer my question without experimenting to the point of putting my configs at risk - so I'd like to ask here:

     

    I have an OpenVPN docker which is used to route other docker's network traffic through.  I have a qbittorrent docker that has a VPN option built-in, and it uses a different VPN provider.  Obviously, my issue is having dockers connect from their "none" network across to the qbittorrent's network (currently bridge).

     

    I've attempted to "docker network connect" these into a third network (docker-bridge), but obviously this isn't possible with the dockers on "none" as I receive a "container sharing network namespace with another container or host cannot be connected to any other network".  When attempting to connect the OpenVPN docker (running on a "dockernet" network) to the "docker-bridge" network, I receive a "Failed to add interface veth05c1386 to sandbox: error setting interface "veth05c1386" IP to 172.20.0.5/16: cannot program address 172.20.0.5/16 in sandbox interface because it conflicts with existing route".  I've tried creating variations of "docker-bridge" with different 172.x.0.0 spaces (docker network create as well as via the interface in settings), but clearly I'm barking up the wrong tree with that approach.

     

    So my question is - how do I get two different dockers on two different docker networks to recognize/communicate with one another?  I'm not hung up on DNS, but by IP address or some other mechanic for communication.

     

    Thanks for any help.

  9. Good day helpful people.

     

    Situation:  Unraid serving as pihole (docker) and pfSense (VM) host for the home network.  It also serves as a Media server as well.  Over the last several days I've been dealing with an issue around pihole and think I've finally gotten things straightened out with it.  However upon creating a new docker network and trying to get things organized better over that way, I've somehow managed to dork a setting up somewhere that I can't manage to undo for the life of me.

     

    Unraid IP:  192.168.1.222

    • WebUI works fine from terminal (though interestingly "localhost" does not).
    • WebUI does NOT work from internal/same network clients (web browser to 192.168.1.222) that had worked minutes ago.
    • pfSense (VM) still accessible at the .227 address from remote machines.
    • pihole (Docker) still accessible at the .228 address from remote machines.
    • Other dockers also still accessible via defined IPs but NOT through .222.
    • Shares aren't accessible remotely.  MAC/IP address of .222 reserved via pfSense.

     

    What changed for me to encounter issue:  I flipped the OpenVPN Client Docker from one docker network to another and hit start.  Spinny browser wheel of death and at that point I lost all REMOTE connectivity to .222.  I'm fairly sure this is the point where it happened as I had some large network copies happening and they errored out at this point.

     

    What I've done to date: 

    • Obviously I flipped the network for that container back, but moreso all my dockers and VMs are stopped aside from pihole and pfSense to keep the family internet-aware.
    • Researched/googled to no avail.
    • Verified the info above was still correct.

     

    I've been scratching my head over this for a few hours now.  Could anyone take a look and point out the supremely obvious issue I'm overlooking for me, please?

    unraid-diagnostics-20220731-1029.zip.tar.gz

  10. Hi folks - first off, apologies for my first post being that of seeking help.

     

    Secondly, Unraid newb, but not to hardware/networking/software.  My ego smarts little from even having to ask for help :)

     

    Regardless, brand new hardware build to replace a failed/failing media server on the competition.  Still on trial Unraid until I can make sure everything is going to work okay.  I see this platform as a good way of rolling my media server and my development server into one.  I've initially sized (per the diagnostics attached) the machine with a 3700x/64GB RAM and a handful of mismatched HDs/SSDs.

     

    The challenge is that I'm seeing a 2-8 second lag in navigating Unraid menus (that wasn't there at install time).  I'm seeing large transfers between both USB-based drives and between SATA drives more or less maxing at 82M bytes/sec.  My docker images are equally slow.  The only really "unique" setup here is that I'm running most of my docker images through another docker image (VPN), but I'm fairly confident that's setup correctly.  I currently have parity turned off to maximize the transfer of data, and a 1TB SSD as cache.

     

    For the life of me, looking through the logs I don't see anything that stands out.  At one point I had a failed 8TB drive that has been removed.  A few hours ago when looking at the logs I realized the timezone was set incorrectly, so I adjusted that.  I'm at a loss, and would be ever so grateful if someone may have a go at these logs to see if I'm missing something obvious.

    Unraid.jpg

    unraid-diagnostics-20210220-1027.zip

×
×
  • Create New...