Filesystem Mount – Mounting Subdirectory of Home on Own Partition Confuses Disk Usage Report

disk-usagefilesystemsmount

1. Situation

1.1 Devices

My filesystem has the following arrangement

/dev/sda8 of 323 GiB is mounted to /home
/dev/sda13 of 90 GiB is mounted to /home/user2/storage

with the original intention to separate the fate of /home/user2/storage from that of all the rest. Both are logical partitions. lsblk is quoted below.

1.2 Mounting

The mount instructions are encoded in /etc/fstab with the lines

UUID=[that of /dev/sda8]  /home/  ext4  defaults 0 2
UUID=[that of /dev/sda13] /home/user2/storage  ext4  defaults 0 2

In frankness, I copycatted the last line from the other mount instructions.
Also, /etc is mounted to another partition.
The output of mount is quoted below.

2. Evidence

This arrangement has had some side effects on the way the system tools report on disk usage.

As a consequence, I am not quite sure which diagnostics I should trust, and how much disk space I actually can count on.

Note that in the computer in point there are a user1 and a user2.

2.1 /dev/sda13 (storage) seen from df

Using df as either user1 or user2 gives

df -h shows no output at all for /dev/sda13
df -ha just shows - for the disk usage of /dev/sda13

If user2 is logged in (and the storage directory has been mounted)

sudo df -h /dev/sda13 (storage) shows the same disk usage (say 300 GiB) as df -h /dev/sda8 (home), although they are different entities and the used size is an impossibility for storage

else

sudo df -h /dev/sda13 (storage) shows a modest disk usage of 0.5 GiB, which I can see as user1

2.2 /dev/sda13 (storage) seen from gparted

Then, when I launch gparted, the used size is different depending on whether I am logged in as user1 or user2.

The value reported looks good for user2 (who should access to the storage), not for user1 (who should not tap from the storage). However, I had expected to get fair information regardless of who I am, user-wise. For good measure, neither value reported by gparted coincides with any of df's.

Side remark: the reports on /dev/sda8 (home) are consistent in all respects.

3. Questions

I am sure there is a logic behind this seemingly inconsistent behaviour.

Would anyone explain this?
Any indications to implement this filesystem arrangement cleanly, so that the reporting is fair?

4.1 Additional info

4.2 Output of `sudo df -h` (user1,2)

This is the output for user 1

udev                          5,9G  8,0K  5,9G   1% /dev
tmpfs                         1,2G  1,3M  1,2G   1% /run
/dev/sda6                      48G  5,1G   41G  12% /
none                          4,0K     0  4,0K   0% /sys/fs/cgroup
none                          5,0M     0  5,0M   0% /run/lock
none                          5,9G  380K  5,9G   1% /run/shm
none                          100M   64K  100M   1% /run/user
/dev/sda9                      26G   23G  1,7G  94% /opt
/dev/sda11                     20G   11G  8,1G  57% /usr
/dev/sda12                    2,0G  1,2G  636M  66% /boot
/dev/sda8                     314G  298G  4,9G  99% /home
/dev/sda10                    4,8G  2,9G  1,7G  64% /var
/home/user1/.Private          314G  298G  4,9G  99% /home/user1

When user2 is logged in the last line is replaced or complemented by

/home/user2/.Private          314G  298G  4,9G  99% /home/user2

4.2 Output of `sudo lsblk`

NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda       8:0    0 698,7G  0 disk 
├─sda1    8:1    0   100M  0 part 
├─sda2    8:2    0  41,1G  0 part 
├─sda3    8:3    0     1K  0 part 
├─sda5    8:5    0   145G  0 part 
├─sda6    8:6    0  48,6G  0 part /
├─sda7    8:7    0   2,1G  0 part 
├─sda8    8:8    0 322,8G  0 part /home
├─sda9    8:9    0    22G  0 part /opt
├─sda10   8:10   0     5G  0 part /var
├─sda11   8:11   0    20G  0 part /usr
├─sda12   8:12   0     2G  0 part /boot
└─sda13   8:13   0    90G  0 part 
sr0      11:0    1  1024M  0 rom

4.3 Output of `sudo mount`

/dev/sda6 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
/dev/sda11 on /usr type ext4 (rw)
/dev/sda12 on /boot type ext4 (rw)
/dev/sda8 on /home type ext4 (rw)
/dev/sda9 on /opt type ext4 (rw)
/dev/sda10 on /var type ext4 (rw)
/dev/sda13 on /home/user2/storage type ext4 (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
nfsd on /proc/fs/nfsd type nfsd (rw)
/home/user1/.Private on /home/user1 type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=...,ecryptfs_fnek_sig=...)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=user1)

4.4 Output of `sudo findmnt`

TARGET   SOURCE FSTYPE OPTIONS
/dev/pts devpts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000

4.5 Output of `groups` (user1,2)

user1 adm cdrom sudo dip plugdev lpadmin sambashare common

user2 sudo common

5. Retrospection

@sourcejedi has provided a useful answer below.

What happened is that the content of the directory storage/ was always saved in sda8 as /home/user2/storage, whether user1 or user2 were logged in, and mounted on sda13 when user2 logged in. Say storage/ contained 100G, then 100G were always taken on /dev/sda8 and some times in /dev/sda13.

I discovered this by mounting /dev/sda13 on a brand-new /home/storage from the /etc/fstab file: I was logged in as user2 and all files were still in /home/user2/storage within /dev/sda8. So I moved the files to a directory within the partition sda13, and referenced such a directory with a symlink from inside /home/user2, as suggested.

In this way I freed those 100G in sda8 and have a reliable report of the size of storage/ from df -h /dev/sda13 whether I am user1 or user2.

Best Answer

the file /etc/fstab is executed regardless of the user, I believe, hence I presume that the partitions are always mounted.

Yes, but there is an interaction with the use of ecryptfs. fstab is processed at boot time. The ecryptfs mount is activated at login time, after you enter your decryption password. The ecryptfs mount shown in the question will mask any existing mount on /home/user1, for example. Note, this would be a bit more apparent when you use the recommended findmnt tool to show the hierarchy of mounts. (The mount output is simpler for getting the complete list of mount options though).

So, you need to mount your storage filesystem outside any user's home directory. Be aware that files outside your home directory will not be encrypted, unless you work out how to do so manually. You can create a symbolic link to it if desired (e.g. ln -s /storage /home/user2/storage). The way it's set up right now does not make any sense, and could break other things as well (I'm suspicious about the ordering of unmounts on shutdown).

Note the question was already confusing to analyze since it lacked the full output from the df commands. There's another corner case, that df /dev/sda1 will show the usage of /dev if sda1 is not mounted. If you look at strace df /dev/sda8, you will see that it does not access the device node; it looks up the directory from the mounts, and then calls statfs("/home", ...). I would prefer to run df -h /home myself...

...I don't necessarily expect the output would be any less confusing when there's an over-mounted filesystem like this though. The omission or - result for sda13 (depending on -a option) suggests that df has some code to detect the overmount case, but it's not working in all cases. EDIT: reported upstream.

lsof

The only way I can think to gain access to a mount such as this would be to mount it as you did before using Nautilus or whatever file browser, and then using a tool such as lsof to see what files/devices are opened by Nautilus.

$ lsof -p $(pgrep nautilus)

But if you're having to connect to your phone via gphoto2 then you're likely not mounting the device a a mass storage device but rather a PTP - Picture Transfer Protocol. There's a Linux FUSE implementation for PTP too.

gvfs?

I would also look in your $HOME directory for a sub-directory called .gvfs. Usually when GNOME or Nautilus are doing the mounting this directory is created as a convenience.

In newer versions of GNOME (3+) this directory has moved and is now here, /run/user/$UID/gvfs.

Example

$ ls -l /run/user/$UID/gvfs/smb-share\:server\=tank\,share\=t 
total 2
drwx------. 1 saml saml    0 Oct 31 09:16 Development
drwx------. 1 saml saml    0 Nov 18 14:52 home
drwx------. 1 saml saml    0 May 14  2013 incoming
...

NOTE: That's a environment variable $UID that is often set in Bash on most modern systems. If it isn't set you can find your user's ID like so:

$ id
uid=1000(saml) gid=1000(saml) groups=1000(saml),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

1. Situation

1.1 Devices

1.2 Mounting

2. Evidence

2.1 /dev/sda13 (storage) seen from df

2.2 /dev/sda13 (storage) seen from gparted

3. Questions

4.1 Additional info

4.2 Output of sudo df -h (user1,2)

4.2 Output of sudo lsblk

4.3 Output of sudo mount

4.4 Output of sudo findmnt

4.5 Output of groups (user1,2)