strike

That looks good. Are you using open or private trackers? If private, maybe the deluge version you're running is blacklisted? Also search for windscribe in this thread, maybe someone has had the same issue. I certainly remember someone mentioning windscribe in this thread.

Yes, you should be able to use it from any browser. Don't know why it's not working. Maybe post your docker run command or a screenshot of your container settings.

What ip are you trying to connect to?

Post your docker run command and a screenshot of the downloads settings in deluge.

How are you trying to reach the webui? If you're using the ip adress to try to reach the webui you're doing it wrong. Like it says in the faq you have to use localhost. As in http://localhost:9696 to reach prowlarr.

Post your docker run command and a screenshot of the downloads settings in deluge.

What do you mean by this? Nothing will download? Post your docker run command and a screenshot of the download settings in deluge. See Q21: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Sorry for the late reply. This is your issue. Switch to normal bridge network and it will work. Or continue to use the thin client.

Do this: https://github.com/binhex/documentation/blob/master/docker/faq/help.md

Set strict port forwarding to "no". That setting is only for PIA users. I can't remember if it does anything when provider is not set to PIA, but worth a shot. Also can you confirm that your router is at 192.168.10.1 ? Since you had a power outage it's not impossible that your router has "reset" and maybe now has a different IP range.

Working on 6.10.3, but glad you got it fixed

Before you loose any more files, ssh into your server or open a terminal in the webui and run this command on all your disks: find /mnt/disk1/ -type f -exec chattr +i "{}" \; Now all your files can not be deleted, renamed or edited. When you figure out what is causing the issue and figured out how to solve it you can run this command on all your disks to "unlock" your files again. find /mnt/disk1/ -type f -exec chattr -i "{}" \; Too figure out what is causing it start one container at the time and watch the logs. Maybe your radarr/sonarr etc has been hacked. You're probably reverse proxying them with swag right? Look at the nginx access and error logs. Check every container that has access to your files. And change your password for all containers you're accessing through swag asap.

You should be able to ssh into your server an enter this command. use_ssl no Then you can access the server webui with the IP address. Go to settings->management access and create a new cert. Edit: And of course set the static IP again, forgot about that.

With VPN off there are no iptables rules in place, but with VPN enabled there are very strict iptables rules in place to prevent leaking.

You got it wrong this time too, it should be 192.168.178.0

I use Cathy for this. I found it here on the forum, can't remember who mentioned it tho. Just scroll down a bit on that site and you'll find it. Awesome tool!

If you are referring to the corrupt db issue your safest bet is to back up your appdata and just update. If you run into the issue restore from backup. The truth is, the longer you wait to update the more likely you're gonna run into issues. This is because in major updates there are gonna be database changes and the db needs to be migrated to the latest version. Sometimes this can cause issues especially when you have not been keeping up with updates. There has been many updates to radarr since this issue and the more you wait the risk is higher that they updates includes more upgrades to the db. And because you're now so far behind the migration of the db has a higher risk of failing. So just get it over with already IMHO. This goes for all software updates btw, keep backups and update regularly to avoid issues in the future. Yes, sometimes updates has issues, but you're gonna have even more issues later on if you don't keep up to date.

Glad it worked out!

And now I remembered WHY it matters just to put that out there as well. It's because unraid does not know how big the file you're going to copy is, it only knows how much space is left on the disk. So if the file is bigger than the space left on the disk it will fail if the minimum free space is not set. If unraid sees that there is less than the minimum free space left it will choose another disk IF the split level permits it. If not it will continue to fill the disk until it runs out of space or files are manually moved to another disk to free up space. Edit: Paraphraseing, unraid do know how big your files are. But when creating a file unraid does not know how big it's going to be before it created. And when copying/moving a file you're essentially making a new file just with the same data.

It might be because of the way rsync is copying directories/files. As I said in my previous post rsync will create the entire directory structure before copying any files. And thus will most likely try to copy all the files into the already created directories. If you do a normal copy I think you will find the cache setting is working as intended. I haven't tested it tho, as I never use the cache feature. I have cache no set on all my shares except the appdata and VM share which is set to only.

Just run the mover and it will move data already copied from cache to the array, then set cache to no and do the rest of the copy. When finished set cache to yes if you want. Also be sure to set your split level to split any dir. you can change it after the initial copy if you want. Split level is important because rsync will create all the directories first before it copies any files, so if the split level is set to anything other than to split any directory on the initial copy you will run into the same issue with the disk filling up.

I know, but the other containers where running through the binhex vpn container, thus making it a binhex vpn config issue. But glad the faq helped you out

Have you read the faq for the binhex vpn containers, specifically Q24? https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md If that doesn't solve your issue you should post in the appropriate support thread for the container. It has nothing to do with the unraid OS. To find the correct support thread right click the container and choose support.

Are you using rclone to mount your gdrive by any chance? If so, then rclone is most likeliy running as root and screwing up your permissions. Add this to your rclone mount script: --uid 99 --gid 99 Btw, you should have mentioned rclone and gdrive (if I'm right and your'e using that) in your posts as this is vital information and that's why nobody was able to help you. I'm only guessing here because your host path in your screenshot says mergerfs/gdrive...

You had it almost right in your last post. The port is wrong, should be 8118. So change the port and change the IP back to the 198.... IP