Hi.

I am not sure how and why I have ended in this pickle, but perhaps something to do with some recent testing in which I moved appdata off my main_cache pool (2 x 250Gb SSDs in Raid 1), as well as domain and system shares (using mover and Unbalance plugin). As far as I recall the dockers were still operational at this point, although some troubleshooting since the problem arose suggested some of the dockers' parameters were still pointing to main_cache for the appdata. But more about that below.

In the array of 5+1 8TB disks, I had a drive #5 which had minimal data on it (~500GB) and I used unbalnce to move all that onto the other disks because then I used SpaceInvaferOne's YT tutorial on how to change a disk in the array from XFS to ZFS. This went without a hitch and I tried a few test scripts to mount ZVOLs instead on dataset for a potential server upgrade and a move to a new MB with a superfast cache drive with nvmes. TBH the ZFS seemed to work ok.

I had had no need for any docker use since I've been busy this last week on other around-the-house-projects.

So that's the background to this current ongoing issue.

When trying to connect to a docker (any docker as it turned out) I could not connect to any of them. Connection refused.

Sounded like a config / network issue and as I had not changed any settings just moving stuff around, I looked at some of my dockers, SABNABD being one, and saw the Network type was set to None. It (and a couple of others) used a custom WG VPN connection but when I tried to change the network type back to the WG0 network, it was not in the drop down. Only the usual plus a custom - br0 home which I did not recognise or recall. It may have been there previously but I don't know.

So I deleted the Wireguard tunnel WG0 in the VPN settings, rebooted the server and tried setting the Network Type to 'bridge' as an initial fall back. So after changing the docker(s) to Bridge, I could not connect to any of the dockers even though they were 'running'. At one point the docker service wouldn't start at all.

Considering I also move the docker image file with Mover/Unbalanced, I decided to recreate this and so stopped the docker, deleted the file, and let the dockers rebuild themselves. It was at this point I noticed some of the templates were referring to the now removed and not working main_cache pool so I pointed them at the right mnt/user share, and selected bridge as the network type. After all the dockers were reinstalled and 'running' I could not access the GUIs. I thought it may be a browser cache issue, but no. I could not access the dockers at all. Now I am getting concerned.

I wondered whether my testing of the ZFS disk in the array might have influenced this (I don't know why it should), so last night I did a reverse of SpaceInvaderOne's tutorial and reverted the ZFS back to XFS. Interestingly, on the XFS to ZFS conversion, the format bit was very quick, just a few minutes. But reverted back, the format process seems to have invoked a full disk rebuild and the disk is shown as emulated as the process is still running and still 7 hours to go, I thought that would have been the same time as the XFS > ZFS format, but apparently not.

I had seen elsewhere that sometimes forcing a change on the network type or custom network can reset things. So I manaully recreated the WGO network in VPN manager but that would not show up in the docker Network Type. So I tried a different 'change', I stopped the docker service (VM already stopped) and I changed the name on the network from 'Home' to NAS and saved it. I restarted the docker service and now the docker won't start at all.

I am now totally screwed with no docker service and a disk being rebuilt for which there was no data anyway after the erase before format. If the disk wasn't being rebuilt (I can see the writes to the disk in the MAIN tab) I would be rebooting the server and seeing if that would sort it. But I suspect there is something more critical at play here. To that end, my diagnostics file attached. Can any please help me get out of this situation?

Thanks,

nas-diagnostics-20250717-0841.zip

Edited July 17, 2025Jul 17 by Bob_C

[SOLVED]

I managed in the end to resolve all the issues.

TLDR: Had to fully remove the old Wireguard Tunnel by (a) deleing the tunnel in /Settings/VPN Manager, then (b) delete an empty <peers> folder sat under /boot/config/wireguard. A reboot then seemed to allow all dockers to be accessed as normal (using the bridge network).

Edited July 17, 2025Jul 17 by Bob_C