-
-
[Support] binhex - qBittorrentVPN
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?
-
[Support] binhex - qBittorrentVPN
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.
-
Multiple failed/failing drives - suggestions on approach?
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: unraid-diagnostics-20221130-1825.zip
-
Docker networking between containers
I have a need for dockers on two different docker networks to communicate with one another. My situation is as follows: I run a "none" network for most media dockers that routes traffic through an "OpenVPN" container. 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: Any input as to either an easier way to make this happen or troubeshooting steps for the error message above? Thanks.
-
sundown started following Crashes since updating to v6.11.x for qBittorrent and Deluge users
-
Daily Crashes after upgrade to 6.11
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
-
After upgrating to unraid v.6.11 my unraid server stop respoing everyday at same time
Linking this topic together, as I searching for a similar issue. I'm using qbittorrent, however:
-
Daily Crashes after upgrade to 6.11
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:
-
-
Daily Crashes after upgrade to 6.11
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: 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
-
Docker Network Routing with "Docker Network Connect..."
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.
-
Nextcloud - Internal Server Error -
Hi all - any updates to this particular topic?
-
Existing install - sudden network connectivity issues
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
sundown
Members
-
Joined
-
Last visited