Rita M.

Slightly separate, but if the plugin exposed a network share or a port directly, the container will not automatically inherit that. Note down every port and share the plugin published before you tear it down, or you will spend an evening wondering why a client on the network stopped connecting to something you thought you had migrated cleanly.

It is asking for a default route, and you almost certainly do not have one. The phrase "default interface" means "the interface the default route points out of", and if there is no default route there is no answer to give.

On a console, print the routing table. If there is no line for the default destination, that is the whole problem and everything else follows from it.

Why creating a bridge does this, specifically. This is the single most common way to end up here and it catches everyone once.

Before: your physical interface holds the address, the netmask and the gateway, and the gateway installs a default route.

When you build a bridge for virtual machines, the physical interface must become a plain member of the bridge with no address of its own, and the bridge takes over the address, the netmask and the gateway. What tends to happen instead is that the bridge gets created and given an address, the physical interface keeps its old address too, and the gateway ends up attached to neither properly - or to an interface that is now enslaved and cannot route.

Result: two interfaces with addresses, no default route, and a system that cannot answer the question "which interface do I send outbound traffic through".

Fixing it from the console. Most of these systems have a console menu with a network configuration option, and this is what it is for. Reconfigure so that:

• the physical interface is a bridge member with no address
• the bridge holds the static address and netmask
• the default gateway is set once, at the system level, and points at your router

Apply, then print the routing table again and confirm a default route exists pointing out of the bridge.

Why the web UI is gone and why that is a symptom rather than a second problem. If the address moved to an interface that is not correctly up, or nothing has a route back to your subnet, the UI is listening but unreachable. It will come back with the route. Do not go debugging the web service.

The one trap to avoid. These systems usually apply network changes with a test-and-revert timer - the new config is applied, and if you do not confirm it within a couple of minutes it rolls back, precisely so that a bad change over the network does not lock you out. On a console that safety net feels like the machine undoing your fix for no reason. Confirm the change when prompted, and prefer doing all of this from the physical console rather than over the network you are currently reconfiguring.

Worth checking which of your plugins actually needs migrating at all.

In my case two of the four were things I had installed years ago, used twice, and forgotten about. The migration project shrank by half the moment I looked at what was genuinely in use rather than what was merely running.

Check the access logs or the last-modified time on each one's data directory before you plan any work for it.

Worth knowing the shortcut for the future: some distributions ship a small tool on the live image that automates the chroot-and-reinstall dance for exactly this situation.

It is not magic and it can pick the wrong disk on a complicated machine, so understanding the manual steps first is genuinely worth it. But once you know what it is doing, it turns this into two clicks.

Practical shortcut for finding clones: ask the storage layer to list every dataset along with its origin property. Anything whose origin is a snapshot of the dataset you are trying to delete is a clone of it, and now you have the name.

That one query answers "what depends on this" definitively, without guessing from the UI. Worth knowing before you need it.