Skip to content

Fix uninstall failing on subuid-owned data - #1495

Open
JoeJoeflyn wants to merge 4 commits into
lerd-env:mainfrom
JoeJoeflyn:fix/1489-uninstall-subuid-data
Open

Fix uninstall failing on subuid-owned data#1495
JoeJoeflyn wants to merge 4 commits into
lerd-env:mainfrom
JoeJoeflyn:fix/1489-uninstall-subuid-data

Conversation

@JoeJoeflyn

@JoeJoeflyn JoeJoeflyn commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Containers write files as a subuid inside the rootless user namespace, so os.RemoveAll fails on mysql, redis and others. Fall back to podman unshare rm -rf, which enters the user namespace where the files are removable.

The installer's own uninstall had the same plain removal in both cmd_uninstall_linux and cmd_uninstall_macos, and there it ran under set -e, so the first service tree it could not delete aborted the script before any success line. By that point the binary and the units were already gone, leaving a directory the user could not remove and nothing left to help them do it. Both paths now go through remove_lerd_dir.

Neither path claims a removal that did not happen any more. When even the user namespace cannot clear the directory, the uninstall names the one that survived and prints the command to run by hand.

Closes #1489
Closes #1280

@JoeJoeflyn
JoeJoeflyn requested a review from a team as a code owner August 13, 2026 13:59
Containers write files as a subuid inside the rootless user
namespace, so os.RemoveAll fails on mysql, redis and others.
Fall back to podman unshare rm -rf, which enters the user
namespace where the files are removable.
@JoeJoeflyn
JoeJoeflyn force-pushed the fix/1489-uninstall-subuid-data branch from b74e393 to 1ff288f Compare August 13, 2026 14:03
geodro added 3 commits August 13, 2026 23:05
The Go uninstall was routed through the user namespace but the installer was not, and the installer is where this was reported. Both cmd_uninstall_linux and cmd_uninstall_macos removed the data directory with a plain rm, so the first service tree written as a subuid failed and, under set -e, took the whole script down with it. By that point the binary and the units were already gone, so the user was left holding a directory they could not delete and nothing to help them do it.

Both paths now go through remove_lerd_dir, which retries the removal under podman unshare and keeps the uninstall running to its success line either way. When even the user namespace cannot clear the directory, the uninstall says which one survived and prints the command to remove it by hand, rather than reporting a removal that did not happen. The Go path reports the same way instead of printing a tick over a directory that is still on disk.
install.sh derives the config and data directories from XDG_CONFIG_HOME and XDG_DATA_HOME and only falls back to HOME when those are unset, so overriding HOME on its own left the suite pointing at the real directories on any machine where they are set. Nothing executed a removal against them, but the isolation held by luck rather than by construction.

The setup now clears the XDG variables alongside HOME, and the first test asserts both directories land inside the throwaway one, so a change that reintroduces the leak fails here instead of on someone's disk.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug(uninstall): removing lerd data fails on service files owned by a subuid uninstall leaves service data behind on rootless podman

2 participants