Closed filippo-martini closed 2 months ago
Hi @filippo-martini
sadly I can't reproduce this:
My bad, the other day I managed to find the culprit and somehow completely forgot to report back. The root of the issue was adding xhost +si:localuser:$USER
in .distroboxrc, as suggested in the wiki, resulting in the line localuser:user being added to access control list
being printed after every execution of any distrobox command, so when the script tries to access the second line to retrieve the boxes names, it selects the wrong one.
I quickly fixed it by appending >dev/null
at the end of the command so it doesn't get printed on the console.
As it was caused by a badly written config file on my end, I think that the issue can be closed, but perhaps adding a quick mention of the possible problem in the relevant page of the wiki (or straight up replacing xhost +si:localuser:$USER
with xhost +si:localuser:$USER >dev/null
) could help casual users who just want to make graphical applications work to not stumble on the same problem.
Thanks added this to the wiki then :)
Describe the bug While trying to perform any operation using
--all
, distrobox tries to manage a non existing container named NAME, inevitably failing, (also appears when using tab to autocomplete), however this "phantom" container is not listed neither bypodman container list
, nordistrobox-list
. I have also tried, without success to reset podman withpodman system reset
, and actually create a container named NAME and then deleting it.To Reproduce Simply try to perform an operation with the
--all
flagExpected behavior There should not be a container named NAME
Logs
Desktop (please complete the following information): I am using podman (4.9.4), distrobox (1.7.1.0) overlayed via rpm-ostree in Fedora silverblue 39
Additional context