vw-kombi

Seems a load of tidying up on the old unused docker xml files (assisted by AI) was needed for this. Todays upgrade went in fine. AI commands to check all the cfg files and made some edits and deleted some.

Nope - I don't have any like that. I had on that pointed to a wg2 interface that no longer existed, bit that is cleaned up with all the other work I did above.

I asked AI about all this and he said there were some issues with the xml's in my config. These has some old config it said (eth0 etc), so I deleted them all. The log suggested (it said) an issue with the Firefox container, so that was deleted, plus its cfg/bak files too. I have a large cleanup of all the very old xml files and only ones that match a running container are there now. While on that topic, I also got it to verify the Mac addresses with this command - for file in /boot/config/plugins/dockerMan/templates-user/*.xml; do \ if grep -qE "<Network>br0(\.[0-9]+)?</Network>" "$file"; then \ name=$(grep -Po '(?<=<Name>)[^<]+' "$file"); \ mac=$(grep -Po '(?<=--mac-address=)[^ <"]+' "$file" || echo "⚠️ MISSING MAC ADDRESS"); \ echo -e "Container: $name\n -> MAC: $mac\n"; \ fi; \ It also suggested I should stop docker, delete the docker file, then re-create it and then re-create all my containers, as a final check - but that seems like a way overkill and you would frighten people off if that was a 'normal' instruction.

It seemed to be stuck in some sort of docker start loop. Looked like they are starting, as in they were all seen, and some say starting, then it all seems to crash, It says Docker Services could not be started, then it repeats all that. Everything else seems to be ok. Drives were good, both my bfs drives (cache and cache-nvme) looked right. I through I did everything beforehand to remove and risks - 1 - Waiting a reasonable time. 2 - Checked the reports from others 3 - I am macvlan, with hardcoded IP addresses in my br0 network, so added the mac's to each of these in the extra parameters 4 - flas backup 5 - updated all dockers and plugins also my other backup unraid system went to this with no issues. Luckily, the rollback from the gui works (have to re-save a few containers to get them to start however). so the flash backup was not needed. Diags attached if anyone can help, and what can I do ahead for a successful re attempt. tower-diagnostics-20260619-1403.zip

There seems to by a need for this in Unraid, so why can't it get added to the OS natively ? I have it based on space invader recommendations a long while back when I implanted the bfs conversion and the sand bfs auto backups from his YouTube. Maybe @SpaceInvaderOne could do a you tube on the command line things needed to get the same functionality, then we can drop an unsupported plugin ?

I have this for a while - something 'hidden' had got into these values - needed to remove then and re-save.

I went back and did an AI search on the issue, and it seems the issue for me was that i had to just put some dummy data into the exclude folders setting. Even though there was nothing in there. It’s seems to be all back now.

I am in the latest non beta. I have a blank screen. Previously turning off lazy load and auto refresh brought it back, but I have not seen anything on there for a while now. Both my cache nvms’s and ssd’s are zfs. Daily I have zfs replication backups working of appdata. I can still use command line to restore one. Instructions for that setup from @SpaceInvaderOne . Just been a while since the zfs master has showed anything.

I thought this plugin was dead? Nothing shows on my screen for it since a few updates back. Versions 7 up I thought. Should I follow this up here as an issue I have? Is it supposed to work ?

as per OP - solved in

Just wanted to post that I got it back. Now sure which - or both, of these changed it - I turned OFF the auto refresh and turned off the lazy load :

I just came here to post the same. Just a blank page. I cant say I use it often, but I have never seen a blank page before. On the latest unraid version.

AI (specifically copilot but I guess they all know) - knew about this issue. It said there is no tailscale router back. It said to add this after I gave it all my ip and naming info - ip route add 100.64.0.0/10 dev tailscale1 And it worked - so I have added that to my startup. Hope this helps someone else! Transcript - Why LAN → container works, but Tailscale → container fails ✅ LAN traffic LAN devices send packets to 192.168.1.x → Unraid → wg1 container The container replies back to 192.168.1.x via Unraid → LAN Everything works. ❌ Tailscale traffic Your iPhone sends packets from 100.x.x.x → Tailscale → Unraid → wg1 container The container replies… but: • It has no route back to the 100.x.x.x subnet • So it sends the reply out the WireGuard VPN tunnel, not back to Unraid • Your iPhone never sees the reply This is why it looks like the container is unreachable, even though Unraid and LAN can reach it fine. The fix: Add a return route on Unraid for the Tailscale subnet You want Unraid to tell the container: “If you ever need to reply to a 100.x.x.x address, send it back through the Tailscale interface.” Your Tailscale subnet is always inside: 100.64.0.0/10 Your Tailscale interface is: tailscale1 ✅ Run this on Unraid: ip route add 100.64.0.0/10 dev tailscale1 This immediately fixes the return‑path problem.

Anyone with any ideas ? I feel it is a routing issue back from the containers configured to use the vpn tunnel. But I dont have the skills to know for sure. It is a pity - as @SpaceInvaderOne showed exactly this config in his latest video, and id like to use it for sonarr/radarr - but I need remote access to those. I can live without the nzbget/qbittorrent remote access - as they are the most in need of this vpn tunnel anyway.