thatsthefrickenlightning

After 2+ months of my QB client only really working briefly after a restart, I fixed this issue. How, I don't truly know. I ended up reinstalling the whole container and migrating over my BT_Backup data and the categories.json file. If I copied over the qbittorrent.conf data from old to new, the problem would reappear. Not sure what it was and not gonna dig further to find out. Seems to have been a weird 1% fluke type bug that only I was having, but maybe this helps someone. Relieved that my 'pipes are unclogged' now. Happy new year, all.

@Mizerka I'll have to try that DNS thing. Edit: problem has gone away on its own for the moment. I handn't troubleshot it any further yet, and already had my suspicions the trouble was on Proton's end. After all, they were claiming no NAT-PMP in the CLI while on servers that are advertised as the opposite.

Anyone else having connectibility problems with ProtonVPN? Everything was fine for the longest time but now: Some time after the container starts, connectibility goes away ('firewalled') WebUI remains accessible Proxy remains functional (tested, e.g. Sonarr can fetch data via the proxy) CanYouSeeMe.org and Test-NetConnection (Powershell) give me a negative response on the IP and TCP port from the logs. Logs themselves seem to be in order, so I'm not sure what's up. QB log I've already created a new .conf file for QB with no luck. Curious to read anyone's thoughts. Thanks. Edit: hol' up, this is the library used right? And it says 'To free all used resources, closenatpmp() can be called', which is what is at the end of my log. Why is this container closing up that PMP port at the end? You need it indefinitely. Very curious. Edit2: restarted and had the logs open on monitor 2. This came by. QB log 2 I'm highly puzzled. The gateway does support NAT-PMP, but still says it doesn't, sometimes?

Sorry, I thought I'd found and followed all instructions. After a force update, the 'wg up' error is gone and the web UI is online. Thanks so much. I've donated before but I'll do it again now for your trouble.

Files are in your DMs as I'm too rushed to ensure I redacted correctly @binhex . Am on :latest and am having the 'wireguard up' issue. Hope that helps

Willing to help here, but how do I 'stop and delete the container (not the image)'? Is that just removing it from the container list in the Unraid Docker GUI and then adding the container back with the 'add container' button? Edit: nevermind, got it. Working on the logs now.

For reference, you can find all the tags for this specific container here: https://hub.docker.com/r/binhex/arch-qbittorrentvpn/tags

Nice, thanks for finding it. A rollback worked for me this time too. Turns out my Wireguard credentials also expired on Sunday so it was a double error. All good for now, I'll revert back to :latest in a few weeks or something and I'm sure the fix will have trickled down. Thanks to everyone who brainstormed about this.

Rolling back did not fix, nor did deleting DNS info from wg0.conf. I have the same issue of 'wg tunnel can't go up' or whatever the error is exactly. I have yet to transfer to OpenVPN temporarily.

I don't use grouping because the idea is for those containers to stay stopped after AB is done, and this is the suggested way to do that. I want this because after AB is done, Duplicacy backs up the non-appdata folders for Nextcloud and Immich. I don't want them restarted before Duplicacy does its thing because then the backed up databases will lag behind those folders if anything gets changed in the interim, which could give me headaches I'd really like to avoid. The script really stops the containers. The Docker page shows 'exited (0) xx seconds ago' after I ran it just now. I'll vibe code in a check to have it echo the stop exit code (and some more stuff maybe) and get back to you. Edit: @alan7467 troubleshooting it as we speak

Sure, I've sent in a debug log to you. ID is 0657fbea-1329-4e95-9ded-98d0d3c42229. Very grateful.

Have a weird new error. Relevant log snippet: The thing is, I stop several containers with a pre-run script before AB does anything. At this point, Nextcloud is already stopped (verified in webUI Docker tab). The log, however, says Nextcloud has 'already started', which is weird because A: AB is trying to stop it, not start it, and B: the 'docker stop' method is the same method the script has successfully used at this point to stop this container. Because AB thinks Nextcloud is running and needs stopping, it restarts the container after all is done, which I need it to not do for the sake of other backup actions that take place after AB is done. If someone can help, I would massively appreciate it. Been working to get decent Unraid cloud backups off the ground for a week now. Hell @KluthR or anyone else there's a donation in it for you if you can help. (if that's against the rules, sorry and I'll delete it)

Hope I'm not being a horrible necro here, but if .tar files are perfectly compatible with Duplicacy's deduplication feature, then there's no real need for a 'backup as plain files and folders' feature, right? All we'd need then is a post-appdatabackup script that converts the flash drive backup from its current .zip format to .tar and it too can be backed up with deduplication.

Sanity check here: my backup share (and destination for this plugin) is mapped to my Duplicacy container for obvious reasons. I need to exclude that backup share in AppdataBackup so it doesn't make backups of my backups, correct? Because the plugin goes after each and every mapping that's in containers' settings... Edit: Hm, I'm probably wrong here. As the backups folder is not listed as a location for appdata, it should be skipped by default. That's not what happened, instead I got an error that the location mapped to Duplicacy was not found (expected, I had just renamed the appdatabackup share to backups because it is going to hold more than just appdata backups, but this change has not yet made it into the Duplicacy container settings). That's likely because it checks to see if a mapped location exists at all before it determines whether it's inside or outside the appdata folder. So backups as a share is now excluded, but that's not making any difference as even when /backups/ is discovered as an actual existing location, it will be skipped because it's outside the regular appdata location. Edit2: after much more backup tweaking, I'm confident edit 1 is correct. As others have said, it would be excellent to be able to have this plugin just copy files over to the backup destination without any archiving. That way Duplicacy and other incremental backup apps can save absolute tons of space in the cloud. Right now if I want incremental backups, I need to give Duplicacy access to /appdata/ and /boot/config and cut out Appdatabackup entirely. Shame, because other than the lack of a 'do not archive' function it is packed with excellent features, like stopping and starting containers and backing up the flash drive. Home Assistant does it too with its backups - it always archives them. Luckily the HA backup by itself is not that huge, at least in my modest case. Edit3: as I learn, I realize nothing I said here is relevant. Uncompressed .tar files are compatible with Duplicacy's deduplication tech so appdatabackup is fine the way it is. Just need to convert the flash drive backup from zip to tar before Duplicacy does its thing.

Anyone seeing FCP's scan get stuck after the update to 6.12.14? I'm on the plugin page, looking at the 'Scanning. Now Scanning your system for common problems. This may take a minute' popup and it's been doing nothing for a long while now. Never took this long before. TIA EDIT: disregard, fixed with a reboot. I shall watch The IT Crowd in shame tonight.