Disk apparently full despite only ~25% being reported in baobab
The problem
I am using Ubuntu 18.04.1 and have an encrypted home folder.
I am having this weird problem where baobab only reports on ~95GB of my data, whereas df -h tells me my Ubuntu partition has 480GB with a usage of 100%.
The usage of 100% is something I cannot explain, but bothers me a lot and creates problems.
My home directory, with ~78GB (reported by baobab), makes up for most of the 95GB mentioned above.
I don't really know how to proceed from here. Please help me find out what is going on and where 75% of disk usage come from that I cannot account for.
Appendix
df -x squashfs -x tmpfs -h -T
Filesystem Type Size Used Avail Use% Mounted on
udev devtmpfs 16G 0 16G 0% /dev
/dev/nvme0n1p7 ext4 480G 447G 8.7G 99% /
/dev/nvme0n1p1 vfat 646M 77M 570M 12% /boot/efi
/home/sebastian/.Private ecryptfs 480G 447G 8.7G 99% /home/sebastian
sudo du -hs /* | sort -h
0 /initrd.img
0 /initrd.img.old
0 /proc
0 /sys
0 /vmlinuz
0 /vmlinuz.old
4.0K /cdrom
4.0K /lib64
4.0K /srv
16K /lost+found
40K /media
48K /dev
176K /root
3.0M /tmp
3.2M /run
5.8M /lib32
6.5M /libx32
13M /sbin
14M /bin
21M /etc
234M /boot
516M /mnt
848M /lib
1.2G /opt
6.5G /usr
12G /snap
146G /home
712G /var
18.04 disk disk-usage
asked Jan 18 at 17:27
sebwassebwas
14
add a comment |
The problem
I am using Ubuntu 18.04.1 and have an encrypted home folder.
I am having this weird problem where baobab only reports on ~95GB of my data, whereas df -h tells me my Ubuntu partition has 480GB with a usage of 100%.
The usage of 100% is something I cannot explain, but bothers me a lot and creates problems.
My home directory, with ~78GB (reported by baobab), makes up for most of the 95GB mentioned above.
I don't really know how to proceed from here. Please help me find out what is going on and where 75% of disk usage come from that I cannot account for.
Appendix
df -x squashfs -x tmpfs -h -T
Filesystem Type Size Used Avail Use% Mounted on
udev devtmpfs 16G 0 16G 0% /dev
/dev/nvme0n1p7 ext4 480G 447G 8.7G 99% /
/dev/nvme0n1p1 vfat 646M 77M 570M 12% /boot/efi
/home/sebastian/.Private ecryptfs 480G 447G 8.7G 99% /home/sebastian
sudo du -hs /* | sort -h
0 /initrd.img
0 /initrd.img.old
0 /proc
0 /sys
0 /vmlinuz
0 /vmlinuz.old
4.0K /cdrom
4.0K /lib64
4.0K /srv
16K /lost+found
40K /media
48K /dev
176K /root
3.0M /tmp
3.2M /run
5.8M /lib32
6.5M /libx32
13M /sbin
14M /bin
21M /etc
234M /boot
516M /mnt
848M /lib
1.2G /opt
6.5G /usr
12G /snap
146G /home
712G /var
18.04 disk disk-usage
asked Jan 18 at 17:27
sebwassebwas
14
Could you edit your post and add the output ofsudo du -hs /* | sort -h? It might complain about inaccessible/procand/rundirectories which you can simply ignore.
– PerlDuck
Jan 18 at 17:31
2
@PerlDuck Edited and posted output. Where do the 712GB come from in/var, do you have any clue? And why is the reported/homehere almost double in size?
– sebwas
Jan 18 at 17:36
1
Weird. Can you please also replace the output of yourdf -hwith the output ofdf -x squashfs -x tmpfs -h -T? That omits the "uninteresting" file systems.
– PerlDuck
Jan 18 at 17:39
1
@PerlDuck also done. I don't exactly know where these "new" 7GB come from. The only thing I did in the meantime was starting docker.
– sebwas
Jan 18 at 17:42
1
Hmm. I wonder how your/varcan use 712 GB when the/filesystem has a size of "only" 480 GB. Actually I currently have no idea.
– PerlDuck
Jan 18 at 17:52
add a comment |
The problem
I am using Ubuntu 18.04.1 and have an encrypted home folder.
I am having this weird problem where baobab only reports on ~95GB of my data, whereas df -h tells me my Ubuntu partition has 480GB with a usage of 100%.
The usage of 100% is something I cannot explain, but bothers me a lot and creates problems.
My home directory, with ~78GB (reported by baobab), makes up for most of the 95GB mentioned above.
I don't really know how to proceed from here. Please help me find out what is going on and where 75% of disk usage come from that I cannot account for.
Appendix
df -x squashfs -x tmpfs -h -T
Filesystem Type Size Used Avail Use% Mounted on
udev devtmpfs 16G 0 16G 0% /dev
/dev/nvme0n1p7 ext4 480G 447G 8.7G 99% /
/dev/nvme0n1p1 vfat 646M 77M 570M 12% /boot/efi
/home/sebastian/.Private ecryptfs 480G 447G 8.7G 99% /home/sebastian
sudo du -hs /* | sort -h
0 /initrd.img
0 /initrd.img.old
0 /proc
0 /sys
0 /vmlinuz
0 /vmlinuz.old
4.0K /cdrom
4.0K /lib64
4.0K /srv
16K /lost+found
40K /media
48K /dev
176K /root
3.0M /tmp
3.2M /run
5.8M /lib32
6.5M /libx32
13M /sbin
14M /bin
21M /etc
234M /boot
516M /mnt
848M /lib
1.2G /opt
6.5G /usr
12G /snap
146G /home
712G /var
18.04 disk disk-usage
asked Jan 18 at 17:27
sebwassebwas
14
The problem
I am using Ubuntu 18.04.1 and have an encrypted home folder.
I am having this weird problem where baobab only reports on ~95GB of my data, whereas df -h tells me my Ubuntu partition has 480GB with a usage of 100%.
The usage of 100% is something I cannot explain, but bothers me a lot and creates problems.
My home directory, with ~78GB (reported by baobab), makes up for most of the 95GB mentioned above.
I don't really know how to proceed from here. Please help me find out what is going on and where 75% of disk usage come from that I cannot account for.
Appendix
df -x squashfs -x tmpfs -h -T
Filesystem Type Size Used Avail Use% Mounted on
udev devtmpfs 16G 0 16G 0% /dev
/dev/nvme0n1p7 ext4 480G 447G 8.7G 99% /
/dev/nvme0n1p1 vfat 646M 77M 570M 12% /boot/efi
/home/sebastian/.Private ecryptfs 480G 447G 8.7G 99% /home/sebastian
sudo du -hs /* | sort -h
0 /initrd.img
0 /initrd.img.old
0 /proc
0 /sys
0 /vmlinuz
0 /vmlinuz.old
4.0K /cdrom
4.0K /lib64
4.0K /srv
16K /lost+found
40K /media
48K /dev
176K /root
3.0M /tmp
3.2M /run
5.8M /lib32
6.5M /libx32
13M /sbin
14M /bin
21M /etc
234M /boot
516M /mnt
848M /lib
1.2G /opt
6.5G /usr
12G /snap
146G /home
712G /var
18.04 disk disk-usage
18.04 disk disk-usage
asked Jan 18 at 17:27
sebwassebwas
14
asked Jan 18 at 17:27
sebwassebwas
14
edited Jan 18 at 17:41
sebwas
asked Jan 18 at 17:27
sebwassebwas
14
asked Jan 18 at 17:27
sebwassebwas
14
asked Jan 18 at 17:27
sebwassebwas
14
14
Could you edit your post and add the output ofsudo du -hs /* | sort -h? It might complain about inaccessible/procand/rundirectories which you can simply ignore.
– PerlDuck
Jan 18 at 17:31
2
@PerlDuck Edited and posted output. Where do the 712GB come from in/var, do you have any clue? And why is the reported/homehere almost double in size?
– sebwas
Jan 18 at 17:36
1
Weird. Can you please also replace the output of yourdf -hwith the output ofdf -x squashfs -x tmpfs -h -T? That omits the "uninteresting" file systems.
– PerlDuck
Jan 18 at 17:39
1
@PerlDuck also done. I don't exactly know where these "new" 7GB come from. The only thing I did in the meantime was starting docker.
– sebwas
Jan 18 at 17:42
1
Hmm. I wonder how your/varcan use 712 GB when the/filesystem has a size of "only" 480 GB. Actually I currently have no idea.
– PerlDuck
Jan 18 at 17:52
add a comment |
Could you edit your post and add the output ofsudo du -hs /* | sort -h? It might complain about inaccessible/procand/rundirectories which you can simply ignore.
– PerlDuck
Jan 18 at 17:31
2
@PerlDuck Edited and posted output. Where do the 712GB come from in/var, do you have any clue? And why is the reported/homehere almost double in size?
– sebwas
Jan 18 at 17:36
1
Weird. Can you please also replace the output of yourdf -hwith the output ofdf -x squashfs -x tmpfs -h -T? That omits the "uninteresting" file systems.
– PerlDuck
Jan 18 at 17:39
1
@PerlDuck also done. I don't exactly know where these "new" 7GB come from. The only thing I did in the meantime was starting docker.
– sebwas
Jan 18 at 17:42
1
Hmm. I wonder how your/varcan use 712 GB when the/filesystem has a size of "only" 480 GB. Actually I currently have no idea.
– PerlDuck
Jan 18 at 17:52
Could you edit your post and add the output of
sudo du -hs /* | sort -h? It might complain about inaccessible /proc and /run directories which you can simply ignore.– PerlDuck
Jan 18 at 17:31
Could you edit your post and add the output of
sudo du -hs /* | sort -h? It might complain about inaccessible /proc and /run directories which you can simply ignore.– PerlDuck
Jan 18 at 17:31
2
2
@PerlDuck Edited and posted output. Where do the 712GB come from in
/var, do you have any clue? And why is the reported /home here almost double in size?– sebwas
Jan 18 at 17:36
@PerlDuck Edited and posted output. Where do the 712GB come from in
/var, do you have any clue? And why is the reported /home here almost double in size?– sebwas
Jan 18 at 17:36
1
1
Weird. Can you please also replace the output of your
df -h with the output of df -x squashfs -x tmpfs -h -T? That omits the "uninteresting" file systems.– PerlDuck
Jan 18 at 17:39
Weird. Can you please also replace the output of your
df -h with the output of df -x squashfs -x tmpfs -h -T? That omits the "uninteresting" file systems.– PerlDuck
Jan 18 at 17:39
1
1
@PerlDuck also done. I don't exactly know where these "new" 7GB come from. The only thing I did in the meantime was starting docker.
– sebwas
Jan 18 at 17:42
@PerlDuck also done. I don't exactly know where these "new" 7GB come from. The only thing I did in the meantime was starting docker.
– sebwas
Jan 18 at 17:42
1
1
Hmm. I wonder how your
/var can use 712 GB when the / filesystem has a size of "only" 480 GB. Actually I currently have no idea.– PerlDuck
Jan 18 at 17:52
Hmm. I wonder how your
/var can use 712 GB when the / filesystem has a size of "only" 480 GB. Actually I currently have no idea.– PerlDuck
Jan 18 at 17:52
add a comment |
1 Answer
1
active
oldest
votes
I couldn't reboot, because it got so bad. So I had to investigate further.
Okay, so as it turns out the file system was actually full. Why it didn't appear in the lists, I have no idea.
The problem was the PHP xdebug profiler running in a docker container writing the whole filesystem full with the profiling files (cachegrind.out.*).
How I found this out:
booting up in recovery mode, opening the root shell. telinit 2, login (maybe this step is not necessary, I don't know). Then run du -hs /* | sort -h and finding out that under /var is the actual culprit (this time with "only" 306G usage, which seemed more likely). Running the du command a couple of more times to find out that the files in a /tmp folder of a docker container that I was running were writing the disk full. So the solution was to delete all these files and reboot and voila the system rebooted as normal and I'm back to 22% disk usage.
answered Jan 25 at 16:31
sebwassebwas
14
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1110937%2fdisk-apparently-full-despite-only-25-being-reported-in-baobab%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I couldn't reboot, because it got so bad. So I had to investigate further.
Okay, so as it turns out the file system was actually full. Why it didn't appear in the lists, I have no idea.
The problem was the PHP xdebug profiler running in a docker container writing the whole filesystem full with the profiling files (cachegrind.out.*).
How I found this out:
booting up in recovery mode, opening the root shell. telinit 2, login (maybe this step is not necessary, I don't know). Then run du -hs /* | sort -h and finding out that under /var is the actual culprit (this time with "only" 306G usage, which seemed more likely). Running the du command a couple of more times to find out that the files in a /tmp folder of a docker container that I was running were writing the disk full. So the solution was to delete all these files and reboot and voila the system rebooted as normal and I'm back to 22% disk usage.
answered Jan 25 at 16:31
sebwassebwas
14
add a comment |
I couldn't reboot, because it got so bad. So I had to investigate further.
Okay, so as it turns out the file system was actually full. Why it didn't appear in the lists, I have no idea.
The problem was the PHP xdebug profiler running in a docker container writing the whole filesystem full with the profiling files (cachegrind.out.*).
How I found this out:
booting up in recovery mode, opening the root shell. telinit 2, login (maybe this step is not necessary, I don't know). Then run du -hs /* | sort -h and finding out that under /var is the actual culprit (this time with "only" 306G usage, which seemed more likely). Running the du command a couple of more times to find out that the files in a /tmp folder of a docker container that I was running were writing the disk full. So the solution was to delete all these files and reboot and voila the system rebooted as normal and I'm back to 22% disk usage.
answered Jan 25 at 16:31
sebwassebwas
14
add a comment |
I couldn't reboot, because it got so bad. So I had to investigate further.
Okay, so as it turns out the file system was actually full. Why it didn't appear in the lists, I have no idea.
The problem was the PHP xdebug profiler running in a docker container writing the whole filesystem full with the profiling files (cachegrind.out.*).
How I found this out:
booting up in recovery mode, opening the root shell. telinit 2, login (maybe this step is not necessary, I don't know). Then run du -hs /* | sort -h and finding out that under /var is the actual culprit (this time with "only" 306G usage, which seemed more likely). Running the du command a couple of more times to find out that the files in a /tmp folder of a docker container that I was running were writing the disk full. So the solution was to delete all these files and reboot and voila the system rebooted as normal and I'm back to 22% disk usage.
answered Jan 25 at 16:31
sebwassebwas
14
I couldn't reboot, because it got so bad. So I had to investigate further.
Okay, so as it turns out the file system was actually full. Why it didn't appear in the lists, I have no idea.
The problem was the PHP xdebug profiler running in a docker container writing the whole filesystem full with the profiling files (cachegrind.out.*).
How I found this out:
booting up in recovery mode, opening the root shell. telinit 2, login (maybe this step is not necessary, I don't know). Then run du -hs /* | sort -h and finding out that under /var is the actual culprit (this time with "only" 306G usage, which seemed more likely). Running the du command a couple of more times to find out that the files in a /tmp folder of a docker container that I was running were writing the disk full. So the solution was to delete all these files and reboot and voila the system rebooted as normal and I'm back to 22% disk usage.
answered Jan 25 at 16:31
sebwassebwas
14
answered Jan 25 at 16:31
sebwassebwas
14
answered Jan 25 at 16:31
sebwassebwas
14
answered Jan 25 at 16:31
sebwassebwas
14
14
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1110937%2fdisk-apparently-full-despite-only-25-being-reported-in-baobab%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Could you edit your post and add the output of
sudo du -hs /* | sort -h? It might complain about inaccessible/procand/rundirectories which you can simply ignore.– PerlDuck
Jan 18 at 17:31
2
@PerlDuck Edited and posted output. Where do the 712GB come from in
/var, do you have any clue? And why is the reported/homehere almost double in size?– sebwas
Jan 18 at 17:36
1
Weird. Can you please also replace the output of your
df -hwith the output ofdf -x squashfs -x tmpfs -h -T? That omits the "uninteresting" file systems.– PerlDuck
Jan 18 at 17:39
1
@PerlDuck also done. I don't exactly know where these "new" 7GB come from. The only thing I did in the meantime was starting docker.
– sebwas
Jan 18 at 17:42
1
Hmm. I wonder how your
/varcan use 712 GB when the/filesystem has a size of "only" 480 GB. Actually I currently have no idea.– PerlDuck
Jan 18 at 17:52