b0m541

I executed the procedure as described under the link in my previous post. It went a little bit different as in the description: unraid did not present an option to say "Partity is valid". It just wanted confirmation that I really want to start the array. The array is running now with 2 data drives being unassigned (and showing up in "Unassigned Devices" (just according to my plan). However, in "Array Operation" it says "Started, Array unprotected" In contrast to this it says in the "Main" view: Parity is valid. Reminder: 2 data drives unassigned, and there are 2 parity drives. Observing the Reads and Writes under "Main>Array Devices" it seems like it is doing a parity check or rebuild: it is reading from all drives and writing to the parity drives. But - nowhere on the UI it is saying that a parity rebuild is running. This behavior is - at least to me - confusing (mixed signals: Array unprotected vs Parity is valid; not saying that a parity rebuild is in process). Is it in fact rebuilding the parity now? How can I confirm this? Or do I need to trigger a parity rebuild? How? (6.9.2)

My array uses 2 parity drives. I want to use the data drive removal procedure supported by limetech, not the one involving zeroing the drives. Using the following supported procedure (https://wiki.unraid.net/Manual/Storage_Management#Removing_data_disk.28s.29) to remove data drives, is it mandatory to run the procedure for each single data drive to be removed separately, or is it possible to empty several data drives and then remove them all together in one step to only need to rebuild parity once?

I have been successfully using unbalance in the past, but that is a few years ago. When i tried to activate it today, nothing happened. The server did not start. In the logs I see the command used for starting unbalance and no subsequent errors. Any ideas what could cause this and how to fix it?

The folders with the problem all had a trailing space character in the name. Remove it and it shows normal again via SMB. I guess this is a bug in the SMB server.

I have a number of folders, all belonging to a series of music CDs, which show the correct folder name on the server, but on the SMB clients they show with the DOS 8 character folder names. I guess there must some mapping that works locally but not across SMB. It can be probably fixed by renaming? Any explanations whats happening?

Recently LSIO have released their Readarr container. It would be awesome if we have a Readarr template for Unraid soon, so that not everyone need to make their own template.

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 to do it but that's just my opinion.

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. However, if I click unmount after writing to the SSD usingg the Krusader container, there will still be some write operations, and then the disk is mounted again. Pressing unmount after this will actually unmount the SSD and the button will be orange and say "mount" as expected. Kind of confusing...

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. If I format the SSD using NTFS and have not enable Automount then I am able to mount it clicking the "mount" button. However, the problem with not being able to unmount it is also there with NTFS. lsof +D /mnt/disks/myssd returns empty. Any ideas?

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. Remark 2: The ROUTE variable does not seem to be necessary to be able to reach the ports of the connected containers, if we put those ports into the OpenVPN-Client container.

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 not have ping and curl. The routing table is empy. Resolv conf points to my local network's DNS server (it shouldn't?). Needless to say, port 5800 is not answering. BTW the explanation in the template say one should "add the port" of the connected containers, but it does not say how to do that. I looked at the container's github project and I guessed it would be the VPNPORT(_x) variables, but I am not sure. What am I missing in my config? How do I make it work?

Thanks, it works.

Same crap here, just updated.. sad.

I tried to reproduce this, but the nslookup of the vpn server ip does not return the root dns server IP address any more. I assume I have no control over that as it is the behavior of one of the DNS servers in $NAME_SERVERS responding. you should be able to reproduce it if you find a name server and the right options so that it would return also the root name server addresses in addition to the vpn server ip address. You will then see that the way you parse that answer, that it will not only grab the vpn server remote ip address but also the ip addresses of the root name servers and put them all into $VPN_REMOTE_SERVER. Each of the IPs in $VPN_REMOTE_SERVER will then be prepended with "-remote" and appended to the openvpn command. Sorry I can't do more for you at this point.

There is a bug in the parsing of the nslookup for the vpn server remote IP. If the DNS response contains IP addresses of the root dns servers in addition to the A records for the vpn server, then the root server IPs will also be added as remote vpn server IPs and tried to connect to using openvpn. This is clearly not desirable.