binhex

Yep im still here, when it's available upstream it will be auto built.

the console log does not say to set a password, it says you need to generate a valid rclone configuration file using the commands specified correct, you cannot generate a rclone config file via the ui, you need to use the command line option as specified in the console log, creating a empty config file will load the ui as you have found out, but it will get you nowhere as you still need to generate a valid rclone config file. so run the following in the 'console' of the container, and when asked if you want to set a password, say no (or set it to blank): rclone config --config /config/rclone/config/rclone.confWhen you see the following choose option 'New remote' do NOT choose the option 'Set cofiguration password' then walk through this and set the remote cloud storage configuration. sh-5.3# rclone config --config /config/rclone/config/rclone2.conf 2025/10/14 11:25:50 NOTICE: Config file "/config/rclone/config/rclone2.conf" not found - using defaults No remotes found, make a new one? n) New remote s) Set configuration password q) Quit config n/s/q>

If you have set a password on your rclone config then this will not work as there is no way to interactively enter that password when its running via script, this is probably why its telling your the password is empty, try removing the password for your config

The password its referring to is most probably this one: So try setting this to a non empty password and you should see the log spam stop hopefully.

i don't support nightly/beta/pre-release/dev builds due to the headache of additonal support, once this feature is in the next 'release' it will be automatically built and available to you.

fixed, please update at your convienience.

A quick google results in this:- https://stackoverflow.com/a/13871564 So click on the container, select 'console' and paste in the linux command from the link above.

You should set CLAIM_SERVER to 'yes' and put in a valid claim token for the value of PLEX_CLAIM only when you want to claim your server, once you have claimed your server then set CLAIM_SERVER to 'no', this will then stop the server from attempting to claim on startup.

i will fix up the template to use http out of the box, as for your query if you do want to use https then you will need to generate a valid key and cert, put them on a path the container can see and configure Variable: HTTPS_CERT_PATH: and Variable: HTTPS_KEY_PATH: respectively.

Why not use the file backup function in urbackup, i use this myself and can restore accidently deleted files from my windows machine in minutes, that way you dont have to deal with a honking massive disk image and all the decompress/mount issues. If that is true you might want to consider making a note not to do it in the future and leave it at that, if there are no other shares then the risk is zero. If you do want to be brave (this may cause issues) then the trick here is to NOT change the container path and instead change the host path ONLY, so i assume you told urbackup to store files in /media/urbackup (or similar, right?), so what you want to do is change /media for the container to point at /mnt/user/urbackup and then copy all files and folders in /mnt/user/urbackup/ (share created by urbckup) to /mnt/user/urbackup/urbackup/, yes its a bit ugly but it gets you around the issue. Good luck!, if there is important data in your backups then tread carefully here!.

I cannot replicate your scenario so i cannot test (single NAS), what i can say is that i have shifted fairly large amounts of data around using krusader without any unresponsiveness (200 GB+), however this is all locally (cache to array), i am not copying to an external device, so this is probably where the issue lies, perhaps try in smaller batches and see if the issue persists. The fact hat unraid won't shutdown might indicate that the krusader file transfer is still in progress, so maybe check the destination and see if you can detect any file writes happening, if so then leave krusader for a period of time and see if it finishes and becomes responsive again. One other thing you can look into is perhaps copying to a NFS share as opposed to SMB.

The above process pins this docker container to a specific tagged version, so it will prevent docker from updating this container, if you want to go back to running latest then you simply reverse what you did, click on 'check for updates' and apply any updates pending.

It works for me (just tested), ensure you are starting with a clean config path, also whats the error? 'fails right away'.

See Q11:- https://github.com/binhex/documentation/blob/master/docker/faq/general.md

Thats the issue in a nutshell, easiest solution would be to restore the database file from backup, its located in /config/sonarr.db

Sorry i couldnt find any reference to including geoip in the image in this support thread, are you on about these changes?:- https://forums.unraid.net/topic/44109-support-binhex-delugevpn/page/429/#findComment-1575213

Looks like a bad endpoint, try re-downloading the latest openvpn configuration file from your vpn provider, if that doesn't work then try downloading an openvpn confg file for another geolocation.

I obviously don't reclaim my Plex server very often (this might even be the first time!), but i went through it this morning and it was relatively painless, FWIW here are my notes (some of this is from memory so please let me know if im missing any info): Go to URL https://plex.tv/reset Put in your Plex registered email address Ensure to tick the option to Log out of all devices Wait for the reset link to be sent to your registered email address Click on link in email and enter in a new strong password and confirm You should now be logged into Plex Web (remote not local) Now restart the Plex container and then go to URL http://<your servers ip address>:32400/web you should see no login prompts other than a PIN (if set), if you are seeing email and password authenticaiton then you are not connecting to your local server, re-check. Once logged in click on the spanner icon top right and go to Settings then General and you should see a warning about needing to reclaim the server Click the button to reclaim the server and follow the prompts and then login using your registered email address for Plex That was it for me, i could then login to https://app.plex.tv/desktop/#!/ and see my server as per normal (no re-pinning required), no other changes required.

Important password breach on Plex, change your password:- https://forums.unraid.net/topic/193388-attention-all-plex-users/ For FWIW here are my notes on the process (some of this is from memory so please let me know if im missing any info): Go to URL https://plex.tv/reset Put in your Plex registered email address Ensure to tick the option to Log out of all devices Wait for the reset link to be sent to your registered email address Click on link in email and enter in a new strong password and confirm You should now be logged into Plex Web (remote not local) Now restart the Plex container and then go to URL http://<your servers ip address>:32400/web you should see no login prompts other than a PIN (if set), if you are seeing email and password authenticaiton then you are not connecting to your local server, re-check. Once logged in click on the spanner icon top right and go to Settings then General and you should see a warning about needing to reclaim the server Click the button to reclaim the server and follow the prompts and then login using your registered email address for Plex That was it for me, i could then login to https://app.plex.tv/desktop/#!/ and see my server as per normal (no re-pinning required), no other changes required. EDIT - If the above didn't work try this: https://www.reddit.com/r/PleX/comments/1nc6ox6/comment/nd777lj/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Important password breach on Plex, change your password:- https://forums.unraid.net/topic/193388-attention-all-plex-users/

done, please pull at your convienience.

ok i see the issue and ive fixed it, please pull down the latest image at your convienience, this will re-establish your previous configuration.

ok ive pulled the version for now, im investigating what's going on.

hmm that is highly unlikely to be related to the change i made, as i am altering internal overseerr files inside the container, this change does not alter anything on /config whatsoever, so somethig else is going on there, have you set the cache share to cache-only?. EDIT - im running overseerr too, upgraded and i see the same initial setup screen, i can only assume the bump in version is a breaking change requiring re-configuration.

ok i have put in a temporary hack that should fix it (shamelessly stolen from the issue), please pull down and let me know.