Jorgen

I'm not familiar with PrivateVPN, so not sure how much help I can offer on this. Have you considered using PIA instead? Either way, I think we need to see more detailed logs at this point, can you follow this guide and post the results please? Remember to redact your user name and password from the logs before posting! https://github.com/binhex/documentation/blob/master/docker/faq/help.md

This is almost certainly the main problem. If surfshark doesn't support port forwarding your speeds will be slow, sorry. Maybe someone else is using surfshark and can confirm if they have managed to get good speeds despite this? Strict_port_forward is only used with port forwarding so you might as well leave it at "no" It has definetly helped others, so it's worth a shot. But you really are fighting an uphill battle without port forwarding. So this is worth pursuing for sure, due to the error you're seeing. The defaults include PIA name servers, which I think have been depreciated by now. There are also other considerations, i.e. don't use google, see Notes at the bottom of this page: https://github.com/binhex/arch-delugevpn Try replacing the name servers with this: 84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1 If the error persists, it's likely something wrong with your DNS settings for unraid itself. No idea about this one, sorry

If you haven't done so already, work through all the suggestions under Q6 here: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Ok, I'm really guessing here, @binhex will need to chime in with the real answer, but I think you need to: 1. Remove the ipv6 reference 2. Remove the DNS entry (maybe, it might also be ignored already. Either way it would be better to move it to the DNS settings of the docker) 3. Add the wireguardup and down scripts 3. Ensure the endpoint address is correct. "pvdata.host" does not resolve to a public IP for me and I'm pretty sure it needs to for wireguard to be able to connect to the endpoint and the tunnel to be established. 4. Try removing the /16 postfix from the Address line So apart from #3, try the below as wg0.conf. Although I'm pretty sure it will fail still because of #3. [Interface] PrivateKey = fffff Address = 10.34.0.134 PostUp = '/root/wireguardup.sh' PostDown = '/root/wireguarddown.sh' [Peer] PublicKey = fffff AllowedIPs = 0.0.0.0/0 Endpoint = pvdata.host:3389

@Nimrad this is what the wg0.conf file looks like when using PIA. I assume it needs to have the same info when using other VPN providers as well. The error in you log specifically states that the Endpoint line is missing from your .conf file, but I don't know what it needs to be set to for your provider/endpoint. [Interface] Address = 10.5.218.196 PrivateKey = <redacted> PostUp = '/root/wireguardup.sh' PostDown = '/root/wireguarddown.sh' [Peer] PublicKey = <redacted> AllowedIPs = 0.0.0.0/0 Endpoint = au-sydney.privacy.network:1337

Can you post your wg0.conf file (but redact any sensitive info)? Which VPN provider are you using? Sent from my iPhone using Tapatalk

It should be Bridge network, and you have already found the correct application setting to fix AP auto-adoption when running inside a Docker container (in Bridge mode). Set Controller Hostname/IP to the IP of your Unraid server, then tick the box next to "Override infrom host with controller hostname/IP" See https://github.com/linuxserver/docker-unifi-controller/#application-setup for more details, especially this:

Thanks for this, just confirming that method 2 pulls down the correct installer for me as well. Sent from my iPhone using Tapatalk

@SpaceInvaderOne I just pulled down your latest container and trying to install Big Sur it actually runs the Catalina installer. I've deleted everything and started over a few times (with unraid reboot in between for good measure) with the same result, is there a bug in the latest image? The installer is correctly named BigSur-install.img but when you run it from the new VM it is definetly trying to install Catalina:

Possibly, not sure how you would find out though. Can you ask the tracker? Sent from my iPhone using Tapatalk

I don’t think you can, sorry. The port is randomly given out by PIA from its pool for the particular server you are connecting to. The container uses a script that asks for a new (random) port on each reconnection to the VPN server. Sent from my iPhone using Tapatalk

Using iCloud is the way to go in my experience. Using the same library from two different macs is not safe. Apple recommends against it and there are many report of corruptions from users doing it. An alternative would be to share the library from within Photos on the VM. Other macs can then access it in read-only mode on the same network. Sent from my iPhone using Tapatalk

For backups yes, if you have enough space on your Mac to store the full library in the first place (I don’t). There’s also a live database in the folder structure so syncing that without corruptions will need consideration. Probably easier to use TimeMachine instead of custom script as Apple have already worked it out for you. Sent from my iPhone using Tapatalk

Should cut down on the support requests in this thread... Just out of interest, how did you manage to do this? I thought this was a limitation in unraid’s VM implementation? Sent from my iPhone using Tapatalk

My MediaCover directory is in appdata on my cache disk, not inside the docker.img. As far as I know I haven't done anything special to put it there, wasn't even aware of it until I saw your post. It should be inside /config from the container perspective, which should be mapped to your appdata share.

I’m successfully doing exactly this, using a vdisk on a user share added to a Mac VM XML as a disk. Have been running for 1-2 years on two separate VMs without a single problem, one for me, one for the wife. I use iCloud Photo Library and only sync the latest photos (or whatever the OS thinks I can afford to store locally) to the local storage on my phone, laptop and iPad. I can still access all photos, and if the high res original is not on the device it will sync it down from iCloud automatically when required. The VM has a full copy of the library, you know just in case iCloud loses all my data. I only spin up the VM once a week to sync down the latest photos. I also use time machine in the VM to backup the whole photo library to another array disk. I really don’t want to lose my photos. Or my wife’s, which would be much worse. I figure cloud + 2 local copies should be enough. Edit: just realized it’s actually not exactly the same. I don’t mount the disk image from the share inside the VM, I mount it as a extra disk via the VM XML. I think I decided it was easier and more reliable to get the disk mounted this way, since I start and stop the VM automatically on a schedule.

Have a look at the WireGuard section here: https://github.com/binhex/arch-delugevpn Looks like you are missing —sysctl="net.ipv4.conf.all.src_valid_mark=1" Also, from your volume mappings it looks like you’re running this on a Windows host? I know wireguard relies on support in the Linux kernel, so not sure if that would cause problems when running on Windows. Sent from my iPhone using Tapatalk

I think you’re mixing Bytes and bits there. 80MiB/s is pretty close to the maximum practical speed of a 1Gb/s line. Sent from my iPhone using Tapatalk

Yeah me neither, but I’m out of my depth here. Hopefully someone more knowledgeable can jump in and help. Sent from my iPhone using Tapatalk

Hiding DNS lookups from your ISP would be one example of traffic that normally bypasses the proxy. But the main use case is to use the VPN tunnel for docker apps that don’t support the use of a proxy at all. NZBget would be one example, but there are many more. Sent from my iPhone using Tapatalk

Try rebooting unraid to shake out any leftover port usage. But what is this in your run command? —net=eth1 That looks non-standard to me, and might be part of the problem? Sent from my iPhone using Tapatalk

Glad it's working for you again, but you probably shouldn't be using the :test tag anymore. It was only temporary for testing new functionality when it was first introduced. Just removing ":test" from the repository field and saving the changes should get you back on the latest normal release of the container.

Lots of people are running successfully on the nextgen servers. If you post your logs (remove username and password first) we should be able to help you get it working. The logs also contain a list off all endpoints that support port forwarding. Sent from my iPhone using Tapatalk

It won’t help in this case, the VM to unRAID share networking is not affected by the NIC speed, it’s using a virtual network. You should already be able to write to the cache drive at full disk speed from the VM Sent from my iPhone using Tapatalk

Just adding to your learnings: enabling turbo-write has no effect when you also disable the parity disk. There is a good explanation in the wiki about how normal vs turbo-write parity calculation is achieved and why the latter is faster. It comes at the expense of needing all your drives spun up though. I’m on my phone so won’t even attempt to find the article and link it, but I’m sure you can find it yourself if you want to dig deeper. Sent from my iPhone using Tapatalk