strike

Those who need to backup/update things that must run 24/7 have redundancy in place so they can run their backups/updates. So if you can't live without internet you might want to look into that. I guess you have never seen a service being down due to updates/moving servers/restoring backups or whatever. Like I said you can run the backup while the docker is running, but there is no guarantee that the files being backed up are 100% the same between the source/destination when the backup is finished. For static files that are not being written to every second there are of course no problems. You could do very frequent backups, then the chance of having a "half complete" backup would decrease.

There is no fix. You can't back up files that are in use, as they can change at any second. Sure you can ignore it, but then you might as well not do the back up at all. What is the point of having a backup where the files backed up are not complete? There is no use in having a half complete backup.. It would do more harm than good. Just schedule the backup when no one is using the internet (at night when everyone is sleeping maybe). If you can't live without internet for 30 min you have to look at other solutions. Like maybe get yourself a pi that can run 24/7 and run pihole (or whatever is taking down your internet) on that. A backup is much like an update. Like windows can't update without shutting down because the files needing updates are in use. And you can't backup files that are in use/being written to. Or you can, but the backup would not be a backup anymore. It would just be different files on the source/destination.

Do you have another container using this port? And change your password on your vpn provider, you forgot to redact it from your post.

Hmm.. No. I don't remember what the permissions should be, but since you messed with that already try deleting the file start the container to recreate it. Stop it again and edit the file and comment out that first line again before you restart it.

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.