binhex

duplicated my postgres directory in case of issues and ran vacuum on it (by setting the env var ) and it took around 10 minutes and finished successfully for me, here is a snipet of what i see in my log: 2025-12-27 14:28:44,192 DEBG 'start' stderr output: 2025-12-27 14:28:44.192 GMT [402] LOG: checkpoint complete: wrote 8355 buffers (51.0%); 0 WAL file(s) added, 1 removed, 32 recycled; write=5.614 s, sync=0.094 s, total=5.885 s; sync files=5, longest=0.029 s, average=0.019 s; distance=540652 kB, estimate=543696 kB; lsn=1C1/3D400280, redo lsn=1C1/1E3FED20 2025-12-27 14:28:44.192 GMT [402] LOG: checkpoints are occurring too frequently (6 seconds apart) 2025-12-27 14:28:44.192 GMT [402] HINT: Consider increasing the configuration parameter "max_wal_size". 2025-12-27 14:28:44.192 GMT [402] LOG: checkpoint starting: wal 2025-12-27 14:30:00,540 DEBG 'start' stderr output: 2025-12-27 14:30:00.540 GMT [402] LOG: checkpoint complete: wrote 3520 buffers (21.5%); 0 WAL file(s) added, 0 removed, 33 recycled; write=76.104 s, sync=0.167 s, total=76.349 s; sync files=22, longest=0.165 s, average=0.008 s; distance=544701 kB, estimate=544701 kB; lsn=1C1/58E8E438, redo lsn=1C1/3F7EE510 2025-12-27 14:30:15,915 DEBG 'start' stderr output: 2025-12-27 14:30:15.915 GMT [402] LOG: checkpoint starting: wal 2025-12-27 14:30:22,463 DEBG 'start' stderr output: 2025-12-27 14:30:22.463 GMT [402] LOG: checkpoint complete: wrote 1011 buffers (6.2%); 0 WAL file(s) added, 0 removed, 33 recycled; write=6.394 s, sync=0.077 s, total=6.549 s; sync files=6, longest=0.047 s, average=0.013 s; distance=536757 kB, estimate=543907 kB; lsn=1C1/7ECAADE8, redo lsn=1C1/6041BB30 2025-12-27 14:30:24,821 DEBG 'start' stderr output: 2025-12-27 14:30:24.821 GMT [402] LOG: checkpoints are occurring too frequently (9 seconds apart) 2025-12-27 14:30:24.821 GMT [402] HINT: Consider increasing the configuration parameter "max_wal_size". 2025-12-27 14:30:24.821 GMT [402] LOG: checkpoint starting: wal 2025-12-27 14:30:28,905 DEBG 'start' stdout output: VACUUM 2025-12-27 14:30:28,906 DEBG 'start' stdout output: [info] FULL VACUUM completed successfully It did has some effect, disk space cosumed for the postgres directory went from 23GB to 20GB after the vacuum.

I really wish there was, but sadly there is no slick way to do this, you could look at the template and then copy in the missing env vars into your existing user template on your flash drive, but that is not the most easiest operation. Really your options are manually add them in, or stop the old container, make a note of your settings and then create from CA and replace with your settings from the old template, then finally delete the old template.

I'm sorry to hear you had a rough time with this, it SHOULD work correctly, i will do some investigation into this and try running a vacuum myself, it is entirely possible the database has to be fully dumped out, re-arranged and then imported back in so it maybe that what you saw is normal behaviour and it just takes a very long time (and lots of space!). A unhealthly container will NOT restart unless you set the HEALTHCHECK_ACTION to be 'kill 1', by default that is not set and it will simply be marked as unhealthly awaiting the action from the user, so going unhealthly should not be the cause. This is the code that performs the vacuum: https://github.com/binhex/arch-bitmagnet/blob/14ecd5d440b235f40a4ca17ff86abec4aea3e011/run/nobody/start.sh#L232 As to what that a vacuum does i can point you at the official documentation: https://www.postgresql.org/docs/current/sql-vacuum.html

Yes, there is another env var to control this: Container Variable: POSTGRES_BACKUP_RETENTION_DAYS Number of days to retain database backups. Older backups will be automatically deleted. All env vars are visible in the latest template, so if you are unsure what it is available then go to CA, search for bitmagnet and 'install' (but cancel out if you don't want a new container creating), this will show you all env vars (ensure you click on 'show more settings...').

FYI i have reversed the defaults for POSTGRES_BACKUP_DB and POSTGRES_SCHEDULED_BACKUP, both are now set to 'false', so if not defined backups will be off.

I totally get that, no pressure from me on this, my only concern is that only one person has keys to the castle, perhaps promoting a trusted person just in case Cas gets run over by a bus might be wise :-) A simple function, it doesn't auto update in the background, it's only on start that it updates for now but i think it will suffce.

Hi ambipro, yes i believe from memory both are included in the latest image. Well i would assume you would need to remove pkg_resources from your source code or pin the version of pkg_resources in your next release (as stated in the warning), nothing i can do here and as you say it's a warning not an error so I'm not concerned, but users do see it an for whatever reason seem concerned over it (it's been mentioned multiple times).

Nope, that's down to the Deluge developers to sort that out.

I used the AUR seerr package here, which largets latest release from the seerr github repo:- https://github.com/seerr-team/seerr/releases

reserved

Overview: Support for Docker image arch-seerr in the binhex repo. Application: seerr - https://github.com/seerr-team/seerr Docker Hub: https://hub.docker.com/r/binhex/arch-seerr GitHub: https://github.com/binhex/arch-seerr Documentation: https://github.com/binhex/documentation If you appreciate my work, then please consider buying me a beer 😁 For other Docker support threads and requests, news and Docker template support for the binhex repository please use the "General" thread here

Apologies if it caused issues, i was in two minds as to whether to turn on backups by default, but as i had first hand experience of db corruption, along with other people in this thread i decided to err on the side of caution and turn it on. I am a bit surprised it knocked your pool out though, i am seeing db backup size of around 1.5GB for 2.5 Millions torrents, is your db backup significantly bigger than this?.

in a word, no, probably db corruption that's the normal issue, open the file /config/Plex Media Server/Logs/Plex Media Server.log and check for the word corruption or error .

Right now there is no gluetun support repo, or at least not one i have created as i have simply created a unraid template that points at the official image, what i might do is a create a generic templates support thread but for now you can post here.

OK so all of my images now include baked in Docker healthchecking, this performs the following: check you can connect to https over the internet check you can resolve names over the internet check the application process is running So if you set deluge 'extra parameters' to include '--restart=always' and set the 'HEALTHCHECK_ACTION' value to 'kill 1' then if any of the above fails then the contianer will be restarted, this should include loss of access to the vpn, and in fact unraid itself will restart all containers routed through another container if the container is rebuilt or restarted, the only caveart to that is that it does not handle manually spun up containers outside of unraid (docker compose). Having said all of the above, you may want to consider coming over to my solution instead :-), this involves setting up gluetun and using that to route network connectivity for all other containers, i have even included automatic port forwarding assignment for deluge which is especially useful for VPN proviers that use dynamic ports (PIA, ProtonVPN), i have also included monitorng of the port to ensure the incoming port is open, if the port is closed then gluetun vpn is bounced, if the port changes then the application is reconfigured to use the new port, all done automatically for you.

In case anybody is running Windows and would like a neat script to integrate the locking and unlocking of selected folders then let me know and i will share the code, i use this ALL the time now and it does reduce the pain of having your media immutable but wanting to change the odd file/folder, it's super quick as it only runs chattr for the selected folder, a quick demo: https://drive.google.com/file/d/1s4IJL4ofD58njFVre--vD8ZJzBYHAX1H/view?usp=sharing

If you run with lock-type='both' then you are stating you do not want to permit ANY modifications of any directories within the given share, so yes you will be unable to create new folders. So I would assume (i have not infected a machine to confirm this) if you set this to lock-type 'files' then certain (uncommon) ransomware strains would be able to encrypt the directory name but not the contents of any directory, so for example you may end up with something like: Share - GH%^&%$£"£%^" (encrypted dir name) - My.TV.Show.mkv (unencrypted filename)You should still be able to navigate to the path and the data should be accessible but it could be a bit messy trying to identify which directory contains which file, it's not a perfect solution all said and done but it does give you some protection, directory encryption is rare, most ransomware strains encrypt files only, so in this scenario no_ransom would fully protect you (assuming you lock all files). For me personally i run with lock-type='files', this gives me the flexibility to create new files/folders and rename folders without having to lock and unlock all the time.

I will create a seperate docker image, you can then shutdown overseerr container, start defining the new container config for seerr and point it at your existing overseerr config path and you should be set (assuming seerr is compatible with overseerr configs)

I have run this image using cache drive formatted as XFS and it seems stable enough, although indexing your shared media is EXTREMELY slow (can take 10-15 minutes) in comparison to something like nicotine+ (less than a minute). I can't really comment on whether ZFS and BTRFS cause problems, maybe somebody else will chip in.

The UNRAID implementation of wireguard has no support for port forwarding at all, so you are out of luck. If you do want a working port forward then you will have to use the solution i came up with which involves gluetun and using that to get a working port forward established. You should ignore uPnP, that would only work in a traditional port forward defined on your router, but as you are using a vpn this does not work, you need to get the port forward established at the vpn end, for soluton see above.

my advice would be to keep your python script out of the container (run on unraid or another container more suited like python).

You don't install an API it is either present or not depending on the application, for qbittorrent-nox it is present, so you can use it right now nothing needs to be done.

i suspect your issue is similar to this:- https://forums.unraid.net/topic/194956-support-binhex-slskd/#findComment-1590170

@Slowrider8 FYI issue raised:- https://github.com/qdm12/gluetun/issues/3031

Thanks for doing this digging, appreciated!, i can replicate the issue and yes i agree it is case related, i think this is a bug in gluetun auth, as this has only recently been possible via env var (i put in the issue), so i will raise this with the gluetun developer, for now stick with lowercase username and password. EDIT - Fixed the invalid character 'j' bug, was due to jq error, wrong format in the curl post command.