beanmeister

So I updated to the current LTS container using my current appdata. I can login into the controller, but all my APs are showing up with their radios (2g and 5g) showing disabled. Also, I cannot see the clients connected to each AP. The APs themselves are still working fine and clients have connections. It is that the controller is not showing the client connections and is reporting that the radios are disabled. I am running firmware 3.9.3.7537 on the APs. If I need to update the AP firmware, what is a good stable firmware to use for the current LTS 5.6.42? Update ==================== Looks like I need a newer firmware. I upgraded one of the AP to 4.0.66.10.832 and now it correctly reports the radios and the client list is back. Don't know if this is the best 4.0.x.x firmware for the UAP-AC-Pro and UAP-AC-Lite. So if I am going to run the newer firmware, is there a recommended controller and device firmware that is quite stable? I have several remote APs and can only maintain them via the controller.

It has been a long time, but how do I get the new container again? Never mind, I found it in the APPs tab.

I am still on the old deprecated container running LTS 5.6.40 and really would like to update to the current container. I see in unRAID under the Docker tab that there is an apply update link next to the old docker container. Should I use that to update or should I do it manually as posted on page 1 of this thread? I would like to stick with LTS for now. My current Unifi container is configured to run on a virtual interface in its own VLAN (br0.30). I hope the update will maintain this settings since it has been so long that I forgot how to do it if I had to do it again.

So I can just prepare a new flash drive and copy everything from the current config folder to the new flash drive? Update -------------------- Oh, I forgot the license is keyed off of the flash drive. So once I redo the flash drive, I just copy everything from the config folder back?

Just upgraded to 6.8.1 from 6.7.2. After reboot, the server frozed at the login prompt and I couldn't access the GUI nor login via the command prompt using IPMI. So I hard rebooted again. I can now login at the login prompt via IPMI, but still cannot access the GUI or via telnet. I cannot access my shares through Windows either. I also noticed the IPv4 address at the login prompt is not correct. I don't know where it got that IP address. Please advice. Update __________________ Sent a Ctrl+Alt+Del via IPMI and let the server rebooted again. This time the correct IPv4 address is shown at the login prompt and I can now access the GUI. First time since v4.7 that I had trouble upgrading. Hopefully all is well.

Thanks Hoopster. Do you know if the recommended step is to update the controller first and then the APs or update the APs first then the controller?

Is there a recommended stable firmware for the AP to pair with the 5.9 controller? I am still on the LTS (5.6.40) controller with older firmware for the APs because I can't afford to have downtime for my customers. I would like to switch to the new Unifi docker app and maybe install the 5.9 controller at the same time. Then slowly upgrade the remote APs to the firmware that works best with the 5.9 controller.

Installed 6.4.1 and set VLAN interface to no IP for unRAID. Then configured docker with the appropriate network. Everything looks good. The UniFi docker container is in a separate VLAN and unRAID is not available in that VLAN. Complete segration achieved! Great job @bonienl! Now, just for curiosity, if I have another VLAN where I wanted to selectively have unRAID available, but with only certain shares and no other services, would that be feasible some time in the future? For example, if I have these shares on my unRAID server: Sales, Finance, Engineering, Executives. In the Sales VLAN, unRAID would be available with just the Sales share and so on for the other VLANs. The management web GUI would not be available nor any other services or ports. Kind of like having a Docker container that allow you to specify which SMB shares to expose and the permissions allowed. This way I can run multiple instances of the containers in their own VLAN. Why would I want to do this? Well I am just looking into the future where I become less trusting of all these "smart devices". So I can see having a VLAN where these devices are segregated from my main LAN, but I would give them access to just certain shares while unRAID is completely isolated. Kind of like a Docker container so that if for some reason the container is compromised, my unRAID server is still safe.

I decided to create rules on my router to intercept all DNS queries and redirect to my router's DNS resolver. This solves the problem that Docker is not using the correct DNS for its interface since the query will be intercepted and redirected. Another side benefit is that the Google devices with hardcoded Google DNS are now being intercepted too and forced to go through my DNS resolver.

Are you not running a local DNS or do you allow DNS queries to traverse across your VLANs?

@bonienl By any chance are you encountering that segregated Docker containers on VLAN interfaces are using the incorrect DNS server? Instead of the VLAN interface's (i.e. br0.30) DNS server, it is using the unRAID's primary interface (i.e. br0) DNS server. This breaks DNS for the containers on br0.30 since the br0's DNS is not reachable from the VLAN. I placed my Docker container in a VLAN as specified in the first post and Docker is trying to use the primary's interface DNS server. So here is my setup: eth0: 10.10.1.0/24 with DNS 10.10.1.1 VLAN 30 : 10.10.2.0/24 with DNS 10.10.2.1 However, Docker containers on br0.30 are configured with DNS 10.10.1.1 and not DNS 10.10.2.1. I have to use the --dns option to supply the correct DNS.

@SiNtEnElThat is exactly my problem! Docker is not setting the Google DNS because it does find a DNS in the host's /ect/resolv.conf. Unfortunately the DNS that Docker finds is in the wrong network! Besides, I would not want Docker to set Google to be my DNS and bypass my domain name blocking (DNSBL on my pfSense). It looks like both you and @ken-ji may not have used the unRAID GUI to setup your VLAN network for Docker.

OK, I ran this command docker run busybox nslookup smtp.mail.yahoo.com and it confirms that my container running on a VLAN interface is configured with unRAID's DNS server. This is fine if the container is running in Host mode, but if the container is running in a VLAN bridge mode (which is a different network from unRAID's primary interface) then the DNS server is unreachable. By supplying the --dns option, the built-in Docker DNS will use the supplied DNS when the built-in DNS is unable to resolve a FQDN. This means Docker always try the default DNS and then fallback to the DNS supplied with the --dns option. Supposedly I can set the list of DNS for the Docker daemon to use in /etc/docker/daemon.json. I will have to try and test this. Update: I tried adding a daemon.json file with the appropriate dns list, but the Docker service would not start. Removing the file allowed the Docker service to start again. Also running the command docker run busybox nslookup smtp.mail.yahoo.com creates a questionable docker container that looks like spam or something.

That is exactly the content of my docker container's /etc.resolv.conf too. Is there a command to see the IP of the DNS that the container is using? Surely I passed in the IP with the --dns option, that must be stored somewhere inside the container. I want to verify that by default, Docker is picking up the DNS in unRAID's /etc/conf and not the appropriate DNS for the subnet of the VLAN.

@ken-ji Only the cat command worked, but the resolv.conf file inside the docker container is the same regardless if I supply the --dns option or not. I suspect that when spinning up a container, Docker will by default check for a DNS server defined in /etc/resolv.conf in the host OS, and if it doesn't find one, or finds only 127.0.0.1, will opt to use Google's public DNS server 8.8.8.8. So the host OS is unRAID and the DNS server defined in unRAID's /etc/resolv.conf is the DNS server for unRAID's primary interface. I even logged into unRAID on the VLAN interface, and the /ect/resolv.conf shows the DNS of the primary interface and not of the VLAN. So this may mean the Docker container on the VLAN interface is using an unreachable DNS server defined in the unRAID host. Somehow unRAID must pass the VLAN's DNS server to Docker if the container is using the VLAN interface.

I would like to view the network configuration within the docker container. I logged into the container with docker exec -it unifi /bin/bash and tried ifconfig but it says command not found. What are the commands that I would use to see the network settings from within the docker container? I am just curious what is the default DNS without the --dns option.

@SiNtEnEl If I understand you correctly, your UniFi docker container is configured as something like br0.VLANID for network mode and you configured a VLAN interface on your unRAID server in Network settings. Did you assign a separate static IP or configured the Docker DHCP for your container? I am trying to see if I configured something incorrectly where my Docker container has no DNS or is using the primary DNS on the man unRAID interface, which is not reachable from the VLAN (i.e using 192.168.1.1 which the main unRAID is using, but the VLAN is configured for 192.168.30.0/24). BTW, your APs and UniFi Controller do not need to be in the same network. You just need to ssh into the AP and perform a set-inform to point it to the controller just as long as there is a valid network route. I have APs coming in from the Internet to my UniFi controller.

It would be great to be able to specify if the unRAID server should be accessible for each VLAN interface. I don't really know what this entails, but I have faith.

This issue is not with the AP's being in VLANs, but running the UniFi Docker container on unRAID in its own VLAN interface. It appears that I get no DNS configuration for the docker container that uses the unRAID VLAN interface. If I run the UniFi docker in Host mode, then it gets the DNS from the primary unRAID host. The DNS is handed out by my DHCP server and so when unRAID gets an IP form the DHCP server for the VLAN interface, it would also get the DNS configuration. However, there is no DNS field in the Network Settings for VLAN like there is for Default Gateway. This leads me to suspect that unRAID is not passing on the correct DNS to the Docker Engine?

Adding the --dns to my run config solved the problem. Without the --dns option, I get host unknown host errors. So I still believe that either unRAID is not setting the DNS for VLANS, or it is setting the DNS of the primary interface. Which for VLANS that are not using the same network, the primary DNS is not reachable since it is in a different subnet.

But I don't think it is prevented from the network. If someone hacks into the docker container (i.e. docker exec -it unifi bash) as if it is a host on the network, they can try and hack into unRAID through the VLAN interface. Because when I run: docker exec -it unifi bash I get into the docker container as if it is a host on the network. Wouldn't unRAID be accessbile via the network?

I am not too concerned with the docker containers themselves, but who is coming into the open ports required by the containers. Since my UniFi docker container requires ports to be opened on my firewall, I do not want my unRAID server to be in the same network where I have opened ports, even if the ports are mapped to the docker container. I just don't want my unRAID to be accessible on the VLAN interface too because I would like to put any services that requires ports to be opened on my firewall into their own network with no access to my private network including my unRAID server. Update: Let's assume somehow a docker container with its own IP is compromised. Since the unRAID server on the VLAN interface is in the same network as the docker container, how can I protect it with firewall rules? Since the two are in the same network, traffic between the two does not hit the firewall router.

I went ahead and created a VLAN (30) for my UniFi docker. The VLAN is on a separate network from my main LAN. The only issue I have with this setup is that the unRAID server gets an address is accessible from the VLAN too! I was hoping by putting the docker apps in a VLAN on a separate network, the docker apps would be segregated from my unRAID server. Is there anyway to prevent unRAID from being in the VLAN network too?

I setup a VLAN (30) to be used for my UniFi docker container. The UniFi (by linuxserver.io) docker appears to be running with the exception that the docker app is not able to resolve hosts using fqdn. For example, inside the UniFi app, you can configure it to send an SMTP alert (like with unRAID). However, if I used the fqdn for the SMTP server (i.e. smtp.mail.yahoo.com), I get an unknown smtp host error. If I use the IP address of the SMTP server (98.138.105.21) then the test smtp alert email gets sent with no problem. Looking on the Network settings, I see a DNS for the main eth0 interface, but none for VLAN portion. I have setup my VLAN to be a separate network, and a PC hooked into the VLAN works fine. However, it appears the docker container is not using my local DNS or any DNS? Update: I did not know if this belongs in the Docker Engine or the General Support thread. I think since it is a general unRAID Network setting issue, I chose the general support thread.

Thanks bonienl. You kind of indirectly answered my question. I was hoping to use my main DHCP service and not have to run a separate DHCP service for Docker. I guess I will just statically assign the IP.