How do I list the directories/file on my local drive?

[SpiceGuy]

I am running an instance of NetAlertX within my Portainer-Docker LXC and it is the only container (aside from the Portainer/Docker LXC) that I am running in the node. By default Portainer-Docker creates its files in the 'local' drive. This drive is formatted as a "directory" drive.


Logs from NetAlertX (within Portainer/Docker) are, by default, written by Docker to

journald

.

The volumes set up by the NetAlertX are:


The problem is that my "local" drive is filling up with data and I'm not sure exactly where it is coming from. My investigation points to docker-portainer LXC. All of my other containers have been configured to use other much larger drives and none of those drives are filling up rapidly. This is what my "local" drive looks like now:



There are no files showing in the Backups, ISO Images or CT Templates windows. (Ex. below) So my guess is this growth of data is from log files.



Question: Can I use the node Shell to list the directories and files to see what files are getting large? Can someone tell me how to display the directories/files and their sizes in the 'local' drive? I need to know if this is a Proxmox issue, or a Portainer-Docker LXC issue or a NetAlertX docker-compose.file issue and viewing the files will help be determine where they are coming from.

Alternatively, I can use

du -bsh *

once I'm in the 'local' directory to list the directories/files and sizes but only if I know where in the drive to look.

Thanks!!!

 

[ubu]

cat /etc/pve/storage.cfg gives you the location of your pve storages.

(apt install gdu)
gdu -x /path/to/storage shows you the usage of the storage

(gdu is like ncdu, but much faster)

 

[SpiceGuy]

Hi Ubu,

Thanks for the fast reply. What gdu is returning doesn't make sense. This is what it says for the 'local' drive:


Copying storage.cfg and opening the copy had this information for the local drive:

dir: local path /var/lib/vz content vztmpl,backup,iso

But, the UI for the local drive in the node is this (below). Something is wrong. They don't match.

 

[Impact]

Try without the -x. Failed network shares can often cause issues like this.
Read this: https://forum.proxmox.com/threads/high-boot-disk-usage-on-proxmox-9-2-node-ext4.183879/
I don't really see the relation to docker here. Two unrelated things can use the same names for different things.

 

[SpiceGuy]

I see no difference when using gdu /var/lib/vz than if I use gdu -x /var/lib/vz . The outputs are identical.



I do see differences using gdu with -x and without -x for some of my other drives but it is the local drive I need to explore. Any other ideas how I can see what that 40Gb of data on my local drive is?

 

[fba]

It is a local directory on /. The output is related to fillrate of the entire mount / not just the /var/lib/vz.

 

[SpiceGuy]

I was advised to look a storage.cfg to determine where the local drive is located. That file had the following output for local:
dir: local path /var/lib/vz so that's where I looked. OK, so now I know that root in the shell is the local drive. I just queried root on the shell using gdu / I got this output:



The only drive that has at least 40Gb is /mnt but this directory contains all of the other drives I mounted to proxmox and not the local drive. So, I added up the sizes of the remaining Gb sized directories and it adds to 46.4 Gb. I'm thinking here is where all of that excess data is. I then looked at the /usr directory since it's the next biggest and this was the output:



The /lib directory was almost the same size as /usr directory. Looking at the /lib directory I found:



The /modules directory is is only slightly smaller than /lib directory so I looked at that (see below). It looks like there is a collection of old PVE kernels. Is that correct? If yes, do I really need all of these older kernels? How many is it safe to remove and still have a reasonable number to keep as a fallback? Thanks!!

 

[Impact]

As explained in the linked thread, unmount/disable the shares and check /mnt. It should be empty. For the old kernels and such apt autopurge or apt apt autopurge '~g|~o|~c' could help. I can't tell you much more without knowing more about your storage.