lococola

Using Binhex Gluetun docker for a VPN connection to AirVPN so I can use specific custom ports for Soulseek. I have Soulseek running through the Gluetun docker and this works fine. However, whenever the Gluetun docker has an update available, Soulseek stops working. Even if I didn't install the update yet. The mere presence of an update for the Gluetun docker makes Soulseek unable to connect to. The fix is to run the GlueTun update, after which the Soulseek docker will automatically rebuild. And then I have to login again to Soulseek and import my configuration again, restart the Soulseek docker, and now it works again. Problem is: GlueTun docker updates very often. Seems like once a week at least. So frequently I come back to Soulseek and find it's not working because there is an update ready for the GlueTun docker. Is there any kind of solution or workaround for this?

This makes complete sense, thank you! I will also use the 'files' setting :)

If I have this file structure: Share - Folder 1 -- File - Folder 2 -- File And if I choose the setting: lock-type='both', will it also lock the main "Share" folder? Because when I set it up like this, it is not possible for me to add another file or folder to the share. It works fine when I choose lock-type 'files'. But, would this not still allow ransomware to encrypt the folder itself, so that I still lose access to the files within?

Thanks, but I don't know how to incorporate it into this script specifically. But for now I have removed the custom port and set it back to 22 on the target. But now I get a different error when I run the script: created directory /mnt/user/barba-rsync-bck/boot/link_dest --link-dest arg does not exist: /mnt/user/barba-rsync-bck/boot/link_dest removed '/tmp/_tmp_user.scripts_tmpScripts_rsync incremental backup remote_script/empty.file' cd+++++++++ ./ Error: Your destination root@<external ip>:/mnt/user/barba-rsync-bck/boot does not support hardlinks! Not sure what's going wrong. You can use hardlinks over SSH, right? Or maybe it's not making an SSH connection for some reason? Here is the destination path I set up: backup_jobs=( # source # destination "/boot" "root@<external ip>:/mnt/user/barba-rsync-bck/boot" What could be the issue?

Trying to get this to work for backup to a remote Unraid machine. I have passwordless SSH working to the remote machine on a custom port using ssh rsa id. How do I specify this custom port in the script? Right now, when I run the script I get the error: Could not obtain last backup! (/boot) Description: Error: ()! Not sure how to proceed from here. I have path set up as follows: backup_jobs=( # source # destination "/boot" "root@<external ip>:/mnt/user/barba-rsync-bck/boot"

Well, looks like I got a little further with this. I found some info on a Github thread discussing issues with rsync when using quotes in the remote path. I do use quotes in my script but not to cordon offremote paths specifically. Anyway, it was suggested to add --old-args to the command, so I thought why not try. And guess what, this solved my issue. The backup jobs are running again. I'm not totally certain this doesn't come with some caveats. I read something about file permissions being lost, but I have done a little testing and I did not see these issues. I'm going to do more extensive restore tests this weekend. So it does appear newer versions of rsync work somewhat differently than older versions, including how it handles quotes in rsync commands. And I'm frankly surprised no information at all is to be found on this forum. Surely I'm not the only one using rsync to backup to remote servers that may use old versions of rsync. Very strange.

I'm not using ipmitool specifically but I did have Nerdtools installed on 6.9.2. I was using it for borgbackup, which I have since abandoned. Just to try I did install SimonF's Ipmitools, but as expected it did not solve the issue for me. Thanks for replying though, perhaps the removal of Nerdtools is in some other way responsible for the issues that I'm having now. Something to investigate. Though, looking at my scripts, I can't imagine any such dependency for my scripts. If anyone has any experience with version conflicts regarding rsync I'd love to hear them.

I have an Unraid server that until recently ran on Unraid 6.9.2. I have several userscripts that use rsync to backup files to a remote Synology over ssh. On Unraid 6.9.2. this worked perfectly. But a few days ago I upgraded to Unraid 7.0.1, and now my scripts are failing with these errors: rsync: [sender] write error: Broken pipe (32) rsync error: error in socket IO (code 10) at io.c(849) [sender=3.4.1] Here is an example of a typical backup script: rsync -avu --numeric-ids --progress --delete --log-file=/mnt/user/apps/Unraid/rsync-logs/<share>.$(date '+%Y-%m-%d_%H-%M-%S').log -e "ssh -T -p 2853 -o Compression=no -x" --relative /mnt/user/./<share> <user>@<remote ip>:/volume1/UnraidBCK\; There isn't much concrete info to find regarding the error code, but the posts that I did find say it's happening because the rsync version on the Unraid server and the target server is not the same. I checked this, and indeed, this appears to be the case. Unraid is currenly using rsync version 3.4.1 protocol version 32. The Synology is using rsync version 3.1.2 protocol version 31. I can still manually SSH to the remote server just fine from Unraid though. Unfortunately I never bothered to check the rsync version of Unraid 6.9.2, but I guess it has to be version 3.1.2 protocol version 31? I guess I must have been very lucky when I set up the rsync jobs in the first place that both Unraid 6.9.2 and the Synology were using the same version of rsync. Because it never occured to me this could be a thing. It seems to be impossible to change the rsync version of the Synology, I couldn't find any information on how to do it. Is it then possible to somehow downgrade Unraid's rsync version back to version 3.1.2 protocol version 31? Or do I have to roll-back to Unraid 6.9.2?

I'm not able to get Backrest working properly. I want to create a repo at the location /mnt/user/resticbackup and I want to backup shares in the /mnt/user folder, like for example /mnt/user/apps. When I create the repo in Backrest I enter the path /mnt/user/resticbackup. When I click on Test Configuration it says "Connected successfully to /mnt/user/resticbackup and found an existing repo." However, there is nothing there yet. No repo is created when I click submit, and when I run a check on the repo it fails because the repo does not exist. Why is this happening? Also, I'm not sure how to get the other shares to show when I create a plan. For some reason the "path" field does not autofill any further than "/mnt", which suggests it can't find anything beyond this. Config attached. What am I doing wrong?

Well, when I try to login to the vault via its IP address and custom port from my local Unraid machine, I get the login prompt. But after logging in with username and password I get the following message: This browser requires HTTPS to use the web vault Check the Vaultwarden wiki for details on how to enable it And from then on all information I've found points to setting up a reverse proxy or using self-signed certificates. So you really can't use Vaultwarden without HTTPS it seems.

It looks like I ruffled some feathers, and I sincerely apologize for that. I guess I am dense, but I'm honestly trying to understand. Let me be clear in when I say I say "no internet connection at all" I mean purely for the communication between the local Vaultwarden docker and for example a local computer running a browser. Of course I want to use the Bitwarden browser plugin to login to online websites etc. I am just having a hard time understanding why I can't just enter the local IP and port of the Vaultwarden vault and connect that way. Yes it wouldn't be as secure but if it's LAN-only then why not. When I began setting up the reverse proxy I had to forward ports on my router in order for it to work. Which bothered me a lot, especially since I didn't see the need for it. Now I have it working through DNS challenge. No open ports, no firewall exceptions, and I think it's as safe as can be now. Even though I have no desire to ever access Vaultwarden outside of my LAN. It just works, and hopefully will continue to work even if my ISP decides to crap out for 3 weeks. But anyway, I'm going to do for Vaultwarden what you so eloquently suggested I do for Tailscale, and stop worrying about it. I have the reverse proxy, it's secure, it works, and Tailscale is not something that I need for this particular thing. Done. As for Tailscale, you won't believe it but I am actually using it as intended for other purposes, like securely accessing photos stored on my server when I am abroad etc. And now also for rsync backups to a remote location. It's great. So no I won't be staying away from it, but I just want to learn. And although I'm ignorant, I actually did pick up some things from your extensive reply, so thank you for that.

So, you do need an internet connection, and not even for only the initial connection, but every time the cert needs to be renewed. This is what I meant when I said internet is required for SSL certification. Your point was of course that it's not required to be online 100% of the time, but that is not the same as not needing an internet connection at all. As you say here: And as far as I know you cannot use Vaultwarden without SSL. Which means you always need some solution for that, like a reverse proxy. In any case, the original point of my post was the question whether Tailscale could be an (fully and completely) offline alternative to the reverse proxy way. I would say no. Because the devices need to be connected to the tailnet all the time. But on the flip-side Tailscale is definitely a lot easier to set up than the custom domain/reverse proxy/wildcard ssl over dns route that I am using now. Thanks for the help everyone!

The issue is that I cannot connect to my vault without the connection going over HTTPS. Because if I access the vault simply by its local IP and port, it won't allow me to login for lack of SSL. Hence the whole domain/reverse proxy setup. Which means there has to be an internet connection for the SSL validation. At least, every tutorial/forum thread/youtube video I have seen on the subject says to set it up this way. I would love to hear how I can manage all this without having any internet connection at all.

Thanks for the detailed explanation. I've learned more about Tailscale which is always useful. Too bad it's not the perfect solution for my Vaultwarden woes, but I am using Tailscale on Unraid for other applications and it's fantastic!

That's not what I've read. Unless you mean once devices have been connected on a tailnet (using an active internet connection) they can then still find eachother if the internet connection goes down after this? That is something that I will need to test.