strike

You need to comment out that first line in the auth file and try again. Stop the container first.

I can't see anything obvious in the logs aside form the ipv6 errors on the start of the log. But I don't think that has anything to with it. Make a backup of the privoxy folder in your appdata and delete it (or move it to a diffrent location), and restart the container. Did that make a difference?

Just because you have the same symptoms does not mean it's the same issue. There's almost a dozen reasons why this could happen. Start by doing this: https://github.com/binhex/documentation/blob/master/docker/faq/help.md

Don't think anything needs to be added. If you can forward a port in Protonvpn you just put that port in the deluge settings for incoming port, and it should work.

You posted the log for krusader. Please post the correct log.

Did you change the privoxy port or something? Please post your template settings. And enable debug log while you're at it and post a new log. Does it connect to airvpn now and you can get to the webui?

Has it been working and it just stopped working? If so try to change the DNS servers in the container template to 1.1.1.1,1.0.01 If you're new user do this: https://github.com/binhex/documentation/blob/master/docker/faq/help.md

Don't mess with ports that was already there, they are there for a reason. You only need to change the host ports in the container template IF you have conflicting ports. If you don't then you don't need to touch them. So put it back to where it was and only change the host port if you need to. And yes, the incoming port you have from AirVpn does NOT go in the template but in the deluge settings in the webui. Edit: If the port in the template you're referring to is this variable, then you have an old template like me and you can just delete it OR put the port that you're connecting to. But it won't make a difference anyway since this port get read from the ovpn file.

Nice idea, but the average user don't read the logs. Most don't even read the post right above their own when they post in the forums, let alone the last pages, and read their own log before posting it. And if they do by any chance read the log most don't know what to do with it, even if the log clearly states the issue. But yeah, it's a nice idea either way. Some few people might take the hint and take the pressure off @KluthRand @wgstarkswhich seems to be helping out most users. But this version of the plugin is new so there is bound to be some issues, it will settle down once most of the users has migrated to this version.

Where exactly did you do this? You're not supposed to put the forwarded port in the container settings. You put it in deluge settings for incoming port in the webui when the container has started.

No, it's not exactly like ZeroTier. The only thing they have in common is that it's creates a secure tunnel to your server. Other then that they are a bit different. Cloudflare tunnel is more for exposing your webserver securely to the internet and Zerotier is for creating a tunnel so you can access your LAN remotely. And ZeroTier requires a client on each device but cloudflare tunnel does not.

This is completely normal and one of the drawbacks with exposing services to the internet. All day, every day, all year, bots will try to search for known vulnerabilities in services exposed to the internet and try to get into your service/server. So it's important when you do this to secure your services the best you can. With long complex passwords, set up fail2ban and maybe a log monitoring service to alert you when something fishy is happening. Or you can set up something like a cloudflare tunnel instead, then you don't need to expose the ports on your router. But then again cloudflare sits in the middle and you have to trust them with all your data. But your server wont be hit all day with bot's trying to get into it, so there's that.

Thanks for correcting me. I kinda knew that, but forgot about it.

You could do this: ssh -t root@<ip> "cd /foo/dir && exec $SHELL"

Nothing is stopping you from doing it via CLI or just open the tarball with winrar or something in windows and extract the files for MariaDb from the backup.

That depends on what your end goal is, and your share settings . Do you want the files to just move to a different share or do you want them to move to different disks as well? If you just want to move the share to a different share and let the files stay on the same disks you can just use krusader or Midnight Commander in CLI and do the move from share to share and it will be instantaneous. IF your share settings includes the same disks of course. If you on share1 have only included disk1 and on share2 you have included only disk2 then it will move disk as well. If you're doing a big move of files between disks you can use the unbalance plugin or just do what you're already doing. Any way you do it it will copy the files to the destination and remove it form the source afterwards. So if your cache drive is to small for the move you could either disable it temporarily or do the move in smaller chunks. Either way it will take the same time to get the files to the other disks regardless if you're using cache or not. Enabled cache will only delay the move to the array until you invoke mover or it runs automatically.

You can issue the command via ssh without rebooting use_ssl no

Try rsync -auv "/mnt/disks/WD_easystore_264D/AlexNAS_Backup/test/" "/mnt/user/test" Test it with a dry run first to see what it does without actually changing anything: rsync -auvn "/mnt/disks/WD_easystore_264D/AlexNAS_Backup/test/" "/mnt/user/test"

You can use Emby or probably Plex (not a plex user) for that. Just create different libraries or "channels" as you call them for your collections. If you want descriptions on your videos you have to create that yourself preferably in an .nfo file and store it with your video file so that Emby/Plex can read it. Or In Emby you have the metadata manager where you can edit the metadata. Plex probably have something similar. But I would go for an .nfo file, that way if you have to nuke your emby/plex install and start over you don't need to create the metadata again as you have that stored with your video files. For your family to watch remote you either have to open up ports on your router to expose Emby/Plex to the internet. Or (the best way), create a reverse proxy with your own (or even a free) domain. You can use SWAG or Nginx Proxy Manager for that. That way you can just go to subdomain.mydomain.com and bam you get straight into your Emby/Plex.

It doesn't necessarily mean it's duplicate in that file. It means that somewhere there is a duplicate, probably you have it in the resolver.conf file. So just delete line 7 in bitwarden.subdomain.conf and you're good to go.

Hi, and sorry for the late reply. I can't really remember if I was able to solve this. And it's been a long time since I've ran a parity check with any VM's running. So don't know really.

What you're seeing is called transcoding. This happens when your client does not support what you're trying to play. Either the video format, audio format or maybe the subtitle. Here is when transcoding comes in. What it does is change whatever format the client isn't supporting into some format is does support, so it can play the file. This is done by the emby server on the fly and on a default setup is using the cpu of the server. And as you're seeing it takes quite a lot power from the cpu to do this on the fiy. Emby is also setup default to "dynamically" transcode your file which means it will only transcode the first part of a file to reduce cpu utilization (10 min maybe) to begin with so the file can start playing. And when emby sees you're catching up to that point it will start the transcoding again, this way emby always stays ahead a few % not causing the video to buffer. This dynamic setting in emby is also why you can't skips chapters without causing buffering. Because remember emby only transcodes the first part of the file and keeps ahead a few % at a time. So when you skip chapters the video will start to buffer because that part is not transcoded yet. You can turn off this dynamically setting in the emby server settings under transcoding. Disable this: When disabled emby will transcode the whole file from start to finish in one go. So instead of the cpu taking 3-4 min at 80% every now and then it can now maybe take 15-20 min to transcode the whole file. But the nice thing is that you can skip forward as long as the transcoding has caught up to that point. Transcoding can also happen if you're streaming remote (or local) and the file has to high bitrate for you're connection so it has to transcode it to a lower quality in order to be able to play it. Usually only happens when playing from a remote location or on a crappy wifi locally. To avoid transcoding all together you will have to buy a client that supports most formats so it can direct play the file instead. You can see in the emby server dashboard why the file is transcoding if you want to troubleshoot. Or you if you have a discrete GPU or integrated GPU on your cpu you can use that to set up hardware transcoding in emby and avoid using the cpu. GPU's are much faster then the cpu. So instead of the cpu using 15 min to transcode a file the gpu does this in maybe 1 min.

The last couple days privoxy is timing out, any reason why that might happen? The tunnel is up and everything is working except medusa and radarr is not finding anything because of privoxy timing out. This is the error I get in Medusa as an example. HTTPConnectionPool(host='192.168.2.218', port=8118): Read timed out. (read timeout=30) If I disable proxy in medusa and radarr they are able to reach the indexer and grab torrents and send them to deluge just fine. There is no error in the supervisord log either that I can see.

I meant the ducker run command for delugevpn

I wouldn't know since I don't use wireguard.