b0m541

two things: (1) the data is not containing any names, but the combination of hardware and setup choices makes each configuration unique as thus trackable (2) the latter cannot be easily circumvented by replacing strings without sacrificing possibly crucial detail privacy always comes at a cost and can be achieved: instead of providing unnecessary data one can reveal necessary pieces of data step by step or to describe the idea what to look for to user so letting them do the actual work themselves, which also helps for future situations as the user learns how t

I see what you mean. I suggest to do this using private messages on this forum.

Thanks for the explanation and the suggestion. I continue to disagree with the assessment regarding the diagnostics content. And we have been there before (you may want to go back in this thread and look it up). Its just not worth going in circles.

diagnostics: We won't discuss this again as we did some time ago. I still fail to see why someone would insist on a full overshooting dataset without being willing or able to say what the person is actually looking for. It sure feels like stubbornness. But hey, someone could call me stubborn too, but I call it privacy. Yes, I have the "Plus" plugin installed. One further observation: when writing to the mounted SSD from the shell, unmount actually works, although the button afterwards still says "unmount" and is grey, while I would expect it to be orange and say: mount.

Actually I was looking at the script log (empty), but the disk log says: unraid unassigned.devices: Unmounting '/dev/sdl1'. unraid unassigned.devices: Unmount cmd: /sbin/umount '/dev/sdl1' 2>&1 unraid unassigned.devices: Unmount of '/dev/sdl1' failed: 'umount: /mnt/disks/USB-2T-Vids: not mounted. ' Then why would the unmount button be shown, shouldn't the mount button be shown instead? Also although destructive mode is enabled, there a no buttons to format the SSD.

Let me know what file you are looking into. The full diagnostics are too much identifying information.

I have a large external USB SSD. When it is formatted wit exFAT and I connect it, it is detected by Unassigned Drives, but the mount button is greyed out. If I configure Automount and re-connect the SSD, it will be mounted. If I write something to the SSD I am not able to unmount it, the unmount button seems not to be able to unmount it. The logs are empty when clicking the logs button. There were a lot of writes going on, although I termined the Krusader container which I used to copy something onto the SSD. I have set Included folders in Folder Caching to not include /mnt/disks.

Sigh, the linuxserver.io container is even worse, the port is hardcoded in the startup scripts, changing the config file content does not help..... This architectural change is much more painful than I was expecting

some linuxserver.io containers have 8080 as container port. no problem with that in a general setup, but with the OpenVPN-Client setup you get a collision and there are no VARIABLES to change the port, so you need to delve into the config files.

There seems to be a challenge with containers connected to OpenVPN-Client if they use the same port numbers within the container. Lets assume container A uses container port 8080 and host port 8080 and container B uses container port 8080 and host port 8081 How can we tell OpenVPN-Client that 8080 is mapped to 8080 for container A and 8081 is mapped to 8080 for container B. I guess thats no possible and one would need to change the port number in the installation of the container image? Any better ideas to solve this?

You point to the -r parameter which is basically the same as the ROUTE variable. One thing also to consider is that if a container resolves using he VPN provider DNS, it will not be able to resolve internal names and one needs to work with IP addresses, or one needs to put in the own internal resolver as DNS server.

I found another case that needs a solution. I can not only be that a local machine needs to connect to container on the VPN network, it can also be that a container on the VPN network needs to connect to the Internet through the VPN, AND also needs to connect to a local machine or to a container on the same host. How would this be done? Is that what the ROUTE parameter is good for?

I have FIREWALL = true, wouldn't that do effectively the same?

Thank you so much, sounds logically if you know the reason. I have another question and 2 remarks: Question: if a connected container e.g. Picard has a container port number 5800 and an associated host port number 1234, how would I implement this with then OpenVPN-Client container? Would I also put in container port number 5800 and host port number 1234? (You may want to document this in the template) Remark 1: DNS started to work when I added the port. Magically the /etc/resolv.conf in the Picard container now has the VPN Provider's DNS server IP. Rema

Hi @ich777 I can't get OpenVPN-Client to work with other containers. I does connect to the VPN provider properly, the tunnel works. Also it uses the VPN provider DNS. I did set the following variables: DNS=true FIREWALL=true ROUTE=192.168.0.0/16 ROUTE6= (empty) VPNPORT=5800 Then I took the Musicbrainz Picard container, changed Network to None and added "--net=container:OpenVPN-Client" to Extra Parameters. The VNC UI of this container is on port 5800. If I open the console of the Picard container I cnnot do much troubleshooting as it does