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


  • 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

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

/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.

  • 1
    Please add the output of lsblk and of mount to your question.
    – DopeGhoti
    Commented Jun 8, 2017 at 18:58
  • different users giving different outputs : try to replace "command" with "/path/to/command" to avoid aliases/functions ? (or you can also use the 'command' builtin to do the same: command df -gh ). And are the partitions always mounted ? or automounted just for user1 and not for user2 ? Commented Jun 9, 2017 at 12:27
  • @OlivierDulac Thx for contributing, but your hints remain obscure to me. Re your question. the file /etc/fstab is executed regardless of the user, I believe, hence I presume that the partitions are always mounted. I have quoted the relevant lines in the post. Commented Jun 9, 2017 at 20:49

2 Answers 2


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.

  • This post seems to refer to or quote resources that I cannot see, perhaps having been deleted. At any rate, I have added the full output of df -h to support the analysis Commented Oct 2, 2017 at 11:45
  • @XavierStuvw sorry, the question had several df commands, but it didn't let me stare at the exact output from them, even the ones with short output. The part about df -h not showing sda13 from user1 didn't seem suspicious in it's own right (permissions). Maybe better to show user2.
    – sourcejedi
    Commented Oct 2, 2017 at 12:00
  • Seen that the syntax of ln is command + target + name, shouldn't the instruction suggested be ln -s /home/user2/storage /storage instead of ln -s /storage /home/user2/storage? Commented Dec 25, 2017 at 14:48
  • @XavierStuvw nope :). Such edits to this answer have been attempted and correctly rejected. /storage is the target of the link. /home/user2/storage is the name of the created link file. It's not uncommon for people to get tripped up by the order of arguments to ln, even though they are consistent with cp.
    – sourcejedi
    Commented Dec 25, 2017 at 23:09
  • Fair enough :-) Indeed, I realize now that my attempt of correction is based on a hasty reading. The arrangement that I have effectively applied is ln -s /home/storage storage launched from user2's home directory: this is my application of your suggestion of having the directory outside any user's home directory, but still within home: so /home/storage is the target and storage is the name. I formulated my correction wrongly, and the rejections are fair, even though they have been caused by a misread path rather than a misunderstanding of syntax. Answer is approved. Commented Dec 26, 2017 at 9:54

I guess that your issue is the permissions on those files, could you please add your user1 and user2 group commands? If I'm not wrong, those outputs would show that they don't share common groups.

Another way to see real values would be to use all those commands with the root account, this way you'd have all privileged access to the whole file structure. Could you please add some info about that?

Hope it helps to get some more meaningful information.

  • Information added. The two users do share one group. The sudo call for group gives root as sole answer and has not been included. Commented Oct 9, 2017 at 19:19
  • as the shared group is common , I could assume those directories are owned by user1:user1 and user2:user2... could you please see if changing to the common group changes the output? something like chown user1:common -R dir Commented Oct 10, 2017 at 2:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .