Disk space disappears when you delete virtual machines

I noticed that when you delete a virtual machine with its virtual disk, the disk space does not come back.

What should you do to recover disk space when you delete a virtual machine?

I thought of using bleachbit as root to delete temporary files, but this one refuses to launch. This seems to be related to the fact that the root account has a particular function on the Purism. Sudo -i works, but su - no. I understand that for security reasons access to full root is disabled, but is there a way to re-enable it to clean with bleachbit root? Or another way is better ?


I know this is a silly question, but did you delete it or do you need to empty the trash?

1 Like

By default, Gnome Boxes stores disk images in the folder ~/.local/share/gnome-boxes/images/ I thought that the images were deleted when you remove the VM but check if there is something left.

1 Like

Hello Uzanto and Gavaudan,

  • Yes, my trash is empty, and I see with show hidden files option.

  • I don’t use Gnome box, but I think it’s the same engine, I prefer use Virtual Machine Manager because you have a better control of emulate hardware and your VM as better anonymous protection. When you use Virtual Machine Manager, his unlock a hidden directory /var/lib/libvirt/images and you can acces you VM with the interface, and you can delete here, but when I look my freespace, it’s doesn’t work and the VM his steel somewhere. And su - doesn’t work so I can acces on directory in manual.

Any idea ? I must use root full acces or they something else to do to delete ?

hi @neoart,
you can access the folder via the details option of the connection.
Under storage you should have access to the folder and can delete the images.
at least that’s how it works for me.
Otherwise if you want to access the folder directly why don’t you just open the filemanager nautilus with sudo nautilus and then navigate to the folder.

Hi @Manuel,

Yes that it, I use option in connection of the VM manager, and I delete here but the freespace no come back.

So I try to use your way with sudo nautilus but it doesn’t work, Nautilus doesn’t lauch with sudo, and I have this :

** (nautilus:4377): WARNING **: 10:36:18.082: Error on getting connection: Failed to load SPARQL backend: Error spawning command line ?dbus-launch --autolaunch=66f7d68bdcc842a69ab2e5f9850263c3 --binary-syntax --close-stderr?: Child process exited with code 1

(nautilus:4377): GLib-GIO-CRITICAL **: 10:36:18.085: g_dbus_connection_signal_unsubscribe: assertion ‘G_IS_DBUS_CONNECTION (connection)’ failed

(nautilus:4377): GLib-GObject-CRITICAL **: 10:36:18.085: g_object_unref: assertion ‘G_IS_OBJECT (object)’ failed

(nautilus:4377): GLib-GObject-CRITICAL **: 10:36:18.085: g_object_unref: assertion ‘G_IS_OBJECT (object)’ failed
No protocol specified
Unable to init server: Impossible de se connecter : Connexion refusée

(nautilus:4377): Gtk-WARNING **: 10:36:18.092: cannot open display: :0

that’s really strange can your start nautilus from the terminal without sudo?
As an alternative you could do a sudo ls /var/lib/libvirt/images to see if the deleted images are still there.
how are you determining your free space and what’s your partition layout, maybe you are looking for the free space wrong partition.

Are you using X or Wayland?

I’m using Ctrl+L (instead executing Nautilus from terminal). Open Nautilus as usual, Ctrl+L, type admin:// in front of /home/ or any other particular folder (as here already recommended). Please close Nautilus when done.


Cute. I didn’t know you could do that.

As an alternative to closing nautilus, if you use a separate tab then it may be OK just to close the tab provided that the computer is physically secure.

1 Like

Not yet, thank’s I will look that

Thanks Manuel.
Sorry I couldn’t answer right away. Everything seems to have returned to normal since the last updates. I can recover disk space normally.

Thanks Quarino too, but I think I have a security issue here ; My password doesn’t work again. I have the sudo password, but not the - su, and this point is became a problem,

1 Like

root is not supposed to have a password, typically.

sudo grep root /etc/shadow

It may now be impossible to know what your original situation was but if it was like the above (! in the password field for root) then that is how you should leave it.

sudo wants your password, not that of root - therefore success of doing sudo is not dependent on whether root has a password and, if so, whether you know what the password is.