问题
我正在使用 Ubuntu 18.04.1 并有一个加密的主文件夹。
我遇到了一个奇怪的问题，baobab 只报告了我的约 95GB 的数据，而df -h告诉我我的 Ubuntu 分区有 480GB，使用率为 100%。
我无法解释 100% 的使用情况，但它给我带来了很多困扰并产生了问题。
我的主目录大约有 78GB（由 baobab 报告），占据了上面提到的 95GB 的大部分。
我真的不知道接下来该怎么办。请帮我找出发生了什么，以及我无法解释的 75% 的磁盘使用量来自哪里。
附录
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
答案1
我无法重启，因为情况变得太糟糕了。所以我不得不进一步调查。
好吧，事实证明文件系统确实已满。我不知道为什么它没有出现在列表中。
问题在于在 docker 容器中运行的 PHP xdebug 分析器用分析文件（cachegrind.out.*）写入了整个文件系统。
我如何发现这一点：
在恢复模式下启动，打开 root shell。telinit 2，登录（也许这一步是不必要的，我不知道）。然后运行du -hs /* | sort -h并发现 under/var是真正的罪魁祸首（这次“仅”使用 306G，这似乎更有可能）。du再运行几次命令，发现/tmp我正在运行的 docker 容器文件夹中的文件正在将磁盘写满。所以解决方案是删除所有这些文件并重新启动，然后系统正常重新启动，我的磁盘使用率又回到了 22%。
答案2
@sebwas 的答案很棒，让我找到了非常相似的问题。不过，我认为使用 root shell 可以解决一个稍微简单的解决方案。
对于那些偶然发现这个问题并且没有被锁定的人来说，
使用 root 权限运行 baobab：
sudo baobab
这应该会让 baobab 找到所有隐藏在访问限制背后的实际罪魁祸首。如果您愿意的话，也可以使用 UI。