Smith007

For the moment just change Unraid GUI ports and use them for your Pi Hole as before. And wait for the update that @bonienl scheduled, which will restore the previous behavior of binding to the primary br0 IP only.

For me it was broken in any version 7. I upgraded from 6 and as I had no time to debug, I rolled back. Only now I finally had some time to sit and debug. But I'm pretty sure it was in 7.0 as well.

Thanks a lot, much appreciated. Side comment: that is why I love open projects or small companies. Try to get such a response from the big guys.

Clearly it was not tested. It was changed compared to 6.x though - intentionally or not. My solution is quite simple and so far allowed to keep standard ports for both GUI and swag frontend. Yes, the other solution is to change the GUI ports, but I see it less elegant and also possibly confusing in emergency scenarios (you need to know and remember non-standard ports). Thus would love to see the old behaviour back - meaning Unraid GUI binding only to the primary IP defined for br0 in Settings/Network.

Swag is running on Custom:proxynet for its backend services with plenty of free IPs and all ports available. But it has defined 192.168.1.11:80 and :443 for its frontend. Since version 7.x this is not working, as ports 80/443 are taken by Unraid GUI, which now binds to all IPs assigned to br0. It was not like this before, why was it changed?

Hi, I have my Unraid main IP of 192.168.1.10 and its GUI running in standard 80/443 ports of that IP. Since few years I had my swag proxy docker 80/443 ports bound to dedicated IP, running as a secondary IP 192.168.1.11 on the same interface as Unraid GUI, so on the same br0 (eth0). I was achieving assigning secondary IP to br0 by using User Scripts plugin, to add additional IP to br0 interface after array start. The script looks like this: IP=191.168.1.11/24 DEV=br0 echo "Adding $IP to $DEV" ip address add $IP dev $DEV After executing the above script I have had such a config: root@unraid:~# ip addr | grep 192.168.1 inet 192.168.1.10/24 metric 1 scope global br0 inet 192.168.1.11/24 scope global secondary br0 but Unraid GUI was bound to .10 only, and swag docker on .11 only - using the same standard 80/443 ports. It was working fine until 7.x Unraid was released. Seems that on 6.x Unraid GUI was binding to the primary IP only (possibly the one defined in Settings/Network), not to all IPs assigned to the br0. That way ports 80/443 were free on the secondary IP and available for swag docker. Seems the above behaviour was changed after upgrading to version 7, and now Unraid GUI is binding on all IPs assigned to br0 interface. That causes a problem with swag running on secondary IP, as now there is no free ports available for this docker. I solved this problem by assigning different, non-standard http/https port numbers for Unraid GUI, but is there any way to force Unraid GUI 7.x to bind only to its primary IP address and leave ports on the secondary IP untouched? as it was before...

Small update, now it is called "Allow install of second instance", still in Apps / Settings menu.

Hi - I'm facing the same issue. Where can I find those different (per ovpn config) credentials?

I want a docker to put it in the same network, among other dockers using the same gateway. Thought this is he way

Hi All, I need to have a very simple docker, where I can execute various curl commands at a specific times. Basically bare Linux with some common tools and cron. Any suggestions?

Hi, I have installed webtrees docker, using MariaDB. All seems to work fine (I can access webtrees login page), except I cannot figure out default admin username and password. Also wt_user table is empty. Do I need to apply any special procedure to create admin account?

For SWAG it was enough to change upstream_port to 8080. Path to conf.yml must be changed manually, or I guess we can wait for official update in Unraid App repository...

Mine has stopped working after update. I have in on port 4000, but behind SWAG proxy. After update SWAG reports "502 Bad Gateway" and in error log "connection refused". Seems like this update broke something?

So it actually works like a charm. All you have to do is to list files you want the mover to skip in a text file, and tell the Mover Tuning plugin to use it. In my case seems it was enough to list: /mnt/cache/NEXTCLOUD/nextcloud.log (not sure, but I reckon it is important to use /mnt/cache/* and NOT /mnt/user/*) Seems it solved the problem with triggering secondary storage, but need some more days to confirm.

I will check hopefully tomorrow and report here.