vw-kombi
Members
-
Joined
-
Last visited
Solutions
-
vw-kombi's post in Upgrade failed from 7.2.4 to 7.3.1 - Docker service failed to start was marked as the answerSeems 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.
-
vw-kombi's post in Using wireguard on some containers to access VPN - this stops tailscale from accessing the container was marked as the answerAI (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.
-
vw-kombi's post in Upgraded 7.0.1 to 7.1.1 - Mover then reports no space left on device on my media share - New Issue with Manual Split Level was marked as the answerJust posting back that the 7.1.2 update has fixed this issue.
I just ran mover after update, after confirming a few 'new' things on the cache drive.
While monitoring logs I got the all clear, then checked the cache was clear and the array had the folders/files.
May 11 16:36:39 Tower emhttpd: shcmd (125): /usr/local/sbin/mover start &> /dev/null &
May 11 16:36:40 Tower shfs: /usr/sbin/zfs unmount 'cache/Downloads' 2>&1
May 11 16:36:40 Tower shfs: /usr/sbin/zfs destroy 'cache/Downloads' 2>&1
May 11 16:36:40 Tower shfs: /usr/sbin/zfs unmount 'cache/EmbyBackups' 2>&1
May 11 16:36:40 Tower shfs: /usr/sbin/zfs destroy 'cache/EmbyBackups' 2>&1
May 11 16:36:40 Tower shfs: /usr/sbin/zfs unmount 'cache/EmbyTranscode' 2>&1
May 11 16:36:41 Tower shfs: /usr/sbin/zfs destroy 'cache/EmbyTranscode' 2>&1
May 11 16:40:15 Tower shfs: /usr/sbin/zfs unmount 'cache/Media' 2>&1
May 11 16:40:15 Tower shfs: /usr/sbin/zfs destroy 'cache/Media' 2>&1
-
vw-kombi's post in Planning on the 7 upgrade from 6.12.13 - QQ re the zfs pools I currently have for cache and nvme was marked as the answerJust an update to this post as I have completed the process.
I had 2 hours free early yesterday morning, and no user impact, so I saved the flash drive and updated to V7.
All fine and took minutes.
I then stopped docker, change back to a docker image and restarted.
Re-installed al containers and all back up and running.
Then I started the long process (about 1.5 hours) or deleting al the legacy files there. The process got faster as they got less and less.
I now have a nice clean filesystem, and the docker size is sitting around 39% do i am in no ush to convert back to the docker directory method.
-
vw-kombi's post in Frequent system lockups/crashes in last 6 weeks was marked as the answerHardware in.
Seems quite a bit snappier.
Enabled GPU transcoding in emby which is something I have not had before.
Started up everything, nothing strange as yet - fingers crossed!!!!!!
-
vw-kombi's post in docker container cant connect to apcupsd service on its own unraid host was marked as the answerI found a solution for this online - BUT IT IS A BUG - PLEASE FIX.
The Host Access to Custom Networks does not survive a reboot often.
The solution -
stop docker, change host access to custom networks disabled, click apply, change back to enabled, click apply, start docker.
-
vw-kombi's post in Just upgraded from .6 to .6 - now logs full of this - repeated over and over : was marked as the answerThe unraid connect install has fixed the errors.
I wont uninstall it for now - just wont enable the remote access / port forward (I have tailscale and wg for that).
May be handy to have another flash backup floating around rather than the manual ones I keep.
-
vw-kombi's post in No user shares after ugrade from 6.12.4 to 6.12.6. was marked as the answerOK - I had a strange server issue (posting that next), but took the downtime as an oportunity to re-do the upgrade.
This time, it went in all fine and started up all fine with no issues to date - I then installed that realtek driver which was on my list to do.
I was a little worried as it was taking a long time on the zipping of the USB, but it seemed to get there in the end.
I had a look in my flash saves and there is a load of diags in the logs going back forever - I am going to erase those.
There is also a number of FSCK files in the root of it.
I am thinking I will re-build this USB and set it up again sometime......
-
vw-kombi's post in New disk added - abysmal performance - where to check was marked as the answerSolved somehow my moving the 2 port sata card from one PCIe to another slot......