Update removes symlink

Sometime I need to resize my Manjaro partition …
Being rightfully nervous about doing this (it’s an old installation, maybe 8 years, and well loved),
I have shifted one or two large system folders to a data drive
for example

  • pacman cache (updated it’s location in pacman.conf) - saves 9GB
  • aur build dir (updated it’s location in pamac.conf) - saves 3.5GB
  • .local/share/baloo (left a sym link in it’s place) - saves 1.5 GB
  • /usr/share/doc (left a sym link in its place)

A problem with the last one /usr/share/doc …
With each update the sym link is removed and a new doc directory is created
Is this expected behaviour? Any work-around?
/usr/share/doc approaches 1GB on my system, but I use those docs a lot …

Don’t do that. Make sure you have enough space on your system drive instead. 30GB should be plenty. Do you have a separate Home partition?

Please post the output of:

df -h

Yes as many packages have files in that directory and will overwrite the symlink. Each time a package updates, it will install the files belonging to it.

You’ll see there are many packages that have documentation files in that directory:

pacman -Qo /usr/share/doc/


pacman --query --owns /usr/share/doc/

OK, I see now, not such a good idea - nice way to see which packages have docs, thanks

Relevant items from df -h:

/dev/sdb3        39G   36G  440M  99% /
/dev/sda1       484G  444G   15G  97% /mnt/touro
/dev/sdb2        24G   22G  1.4G  95% /home
/dev/sda2       215G  198G   18G  93% /mnt/data
/dev/sdb1        39G   13G   24G  35% /run/media/steve/moredata

I have a separate /home
My / is 39GB, but mostly sits above 95% usage.
I keep it pretty clean - I guess I have a lot of software installed

Structure of my root partition as shown by duc

duc ls /
 21.5G home
 14.3G usr
990.5M var
961.0M opt
 56.8M boot
 39.6M etc
  9.0M tmp
  1.4M run
 16.0K exif-info.db
 16.0K srv
  4.0K cmdline
  4.0K .manjaro-tools
  4.0K .thumbnails

So / actually only uses 19.4GB
df shows 39GB used, but 21GB is /home … even though /home is a separate partition
So there should in fact be a lot of space on the root partition?

Yes, it is. You’re not supposed to replace system directories with symbolic links.

Well, instead of using symbolic links, you could just as easily mount another filesystem to those directories — the filesystem where you moved their contents to. And if they’re both pointing at the same filesystem, then you can use bind-mounts on the directories that contain the actual files.

Of course, you’ll need to make sure that you’ve properly moved everything over before doing that, and it is actually best done from the live USB/DVD/CD session, so that nothing under the /usr hierarchy of your installed system will be in use.

You don’t even need to chroot for that. Just make sure all of the files are properly moved over to where you want them to be, and then set up bind-mounts in /etc/fstab. See… :point_down:

man mount
man fstab

You may also want to check out these two tutorials below… :point_down:

It’s not the packages doing that. The packages themselves will be perfectly happy with the designated target being a symbolic link. However, it’s the filesystem package that does this.

filesystem makes sure that all of the required directories of the filesystem tree are created, and that they have the proper permissions. And if a directory has been replaced by a symbolic link, it will replace that symbolic link again by a proper directory. :wink:

Show us the output of df. And by the way, you’ve got stuff in your root directory that doesn’t belong there. There should be no hidden files or hidden directories in your root directory (/).


Ah, thanks for the correction. :+1:

1 Like

OK, I’ll think about the idea of mounting another fs - sounds like a good plan.
Thanks for the tutorial links - that first one exactly outlines a possible solution for me

But this discussion again raises an old question for me:
my home partition is 20G and root partition is 19G
why does df show root partition size as 36G? This 36G also includes /home

...$ df -h
Filesystem      Size  Used Avail Use% Mounted on
dev             3.9G     0  3.9G   0% /dev
run             3.9G  1.5M  3.9G   1% /run
/dev/sdb3        39G   36G  413M  99% /
tmpfs           3.9G   44M  3.9G   2% /dev/shm
tmpfs           3.9G  5.5M  3.9G   1% /tmp
/dev/sda1       484G  443G   16G  97% /mnt/touro
/dev/sdb2        24G   22G  1.4G  95% /home
/dev/sda2       215G  199G   16G  93% /mnt/data
tmpfs           795M  136K  794M   1% /run/user/1000
/dev/sdb1        39G   13G   24G  35% /run/media/steve/moredata

And by the way, you’ve got stuff in your root directory that doesn’t belong there. There should be no hidden files or hidden directories in your root directory (/)

OK, so i should delete the 2 hidden files in root?

What makes you think those would be the correct numbers?

Keep in mind that du gives you the sizes of files and directories, not of filesystems. df is the command that gives you the sizes and usage of filesystems.

Maybe move them somewhere else. .thumbnails however can be deleted altogether.

I’m using duc (not du) to show sizes of directories

$ sudo duc ls /
 15.3G usr
  1.9G root
  1.2G var
968.8M opt
 56.8M boot
 39.7M etc
112.0K tmp
 16.0K exif-info.db
 16.0K lost+found
 16.0K srv

Adds to 19.4G - and it doesn’t show the home partition

Whereas df (see post above) shows 36G for root partitiion

I guess if df is showing the size of the fie system, then maybe /home is included in that …

But in terms of physical size on disc, surely / is actually 19.4G and not 39G?
Meaning that / should only be 49.7% used (and not 99% used as shown by df)?

This has always confused me …

Nope, it isn’t, because df shows you the correct mountpoints and how much space is used on each volume in the list.

I am not familiar with duc, but perhaps it is not including certain directories in its calculation. This is possible if it only descends into subdirectories up to a certain level. When in doubt, read the manual. :wink: :point_down:

man duc

Either way, df is showing you the correct values, unless you are using btrfs as your filesystem, in which case you need to use btrfs’s own tools for accurate numbers. See… :point_down:

man btrfs-filesystem

Even if I use du to show dir sizes in /, the conclusion is still that the total space used by system files (excluding /home) is about 19G (ext4 fs)

$ sudo du -h --exclude=mnt --exclude=home --exclude=proc --max-depth=1 /
16K     /srv
16K     /lost+found
0       /dev
1.3G    /var
24K     /tmp
13M     /boot
0       /sys
40M     /etc
969M    /opt
15G     /usr
1.9G    /root
1.6M    /run
19G     /

Even more proof - using du on individual directories in /
the only directories of any real size are /usr, /var, /opt, /root

$ du -sh /usr
15G     /usr
$ du -sh /opt
969M    /opt
$ sudo du -sh /var
1.3G    /var
$ sudo du -sh /root
1.9G    /root

Still adds to 19G
The mystery remains (at least in my mind)

Seem to have strayed a bit from the original topic.
Altho not really because if my system is only using 19G the original problem was never there in the first place {:

Part of your filesystem is also being used by the ext4 journal. I’m not sure of the percentage, but I believe the maximum size for the journal on an ext4 filesystem with 4K block size to be 2 GiB.

Another thing that’s possible — I should have thought about this earlier — could be that you have at one point dumped a whole lot of stuff into /home without that /home was mounted. As a result, all of those files would still be there and consuming space on the root filesystem, but they would be invisible for as long as your /home partition is mounted.

You have to keep in mind that in and of itself, /home is only a directory on the root filesystem, and if nothing is mounted there, then whatever gets written to /home will be taking up space on the root filesystem itself. If you then mount another filesystem on /home later without having cleaned out the directory first, then that content is simply hidden by the new mount, but that doesn’t mean it’s no longer there.

The best way of checking this is to boot up from the live USB — without chrooting! — and mount your root filesystem (/dev/sdb3) to /mnt without also mounting your /home filesystem (/dev/sdb2), and then checking whether there is anything under /mnt/home. I’m willing to bet that there’s a lot of stuff there.

1 Like

OK I did as you suggested - I booted up with a debian usb and mounted /dev/sdb3 to /mnt/manjaro and /dev/sdb2 to /mnt/manjaro-home.
When I looked into /mnt/manjaro/home there was a dir with my username, but the dir is empty - no contents.
This separate home partition was set up when I installed manjaro a few years back. It’s unlikely that /home has ever been unmounted

If there is a directory with your username under the unmounted /home, then it must have been used unmounted at some point, because if /home was always a mountpoint, then the /home on the root filesystem would be empty — no directory with your username.

And just because the directory with your username appears empty doesn’t mean that it is. There could be hidden directories and hidden files in there.

And what about swap files? Do you have any of those on your root partition?

OK, that makes sense …
I have another (fake) user registered … I noticed that there was only one user name under /home on the debian mount - the other user name was not there

What if I remount sdb3 in the debian system and delete the dir with my username under /home?

I have a separate swap partitiion

:arrow_down: This is better and much shorter. :slight_smile:

# -x skip directories on different filesystems
# -d1 max depth = 1
sudo du -hxd1 /

# I like to add in a sort
sudo du -hxd1 / | sort -h

You may want to recheck your maths: 19 + 20 != 36

To see what’s actually there: Load a live USB, mount sdb3 and run du on it.

sudo mount /dev/sdb3 /mnt
sudo du -xhd1 /mnt | sort -h
1 Like

There’s even more to check… In your df output, you have these two:point_down:

/dev/sda1       484G  443G   16G  97% /mnt/touro
/dev/sda2       215G  199G   16G  93% /mnt/data

What if there is a bunch of files and directories under /mnt because you copied/moved that stuff there without that /dev/sda1 and/or /dev/sda2 were mounted?

So, considering that nothing under /mnt is needed by the system, I would suggest that you temporarily unmount /dev/sda1 and /dev/sda2 and then take a look at what still lives under /mnt/data and /mnt/touro.


1 Like

This is better and much shorter

Very nice tip, thanks - it’s in my regular toolbox now (:

I mounted sdb3 on a live USB and ran du
It shows a total usage of 19G
As @Aragorn suspected above, the home folder did have some hidden folders dated 2018 which I deleted. Only amounted to 1.5M
But wait, there’s more …

1 Like

There were indeed a bunch of files inside /mnt/touro and /mnt/data, when I unmounted those partitions … some pacman packages (2.7G) and some old duplicity backup files (15G). I have removed those now. How they got there I can’t say - at some point when duplicity or pacman were writing to disc but those partitions were not mounted - it’s hard to see when a situation like that could have arisen seeing that those are mounted by fstab …

Anyhoo … look at the shiny new output from df

$ df -h
/dev/sdb3        39G   19G   18G  52% /
/dev/sdb1        39G   19G   18G  51% /mnt/moredata
/dev/sda1       484G  434G   25G  95% /mnt/touro
/dev/sda2       215G  199G   17G  93% /mnt/data
/dev/sdb2        24G   23G  290M  99% /home

Shows / at 52% which agrees exactly with the output from du

I can’t thank you all enough … this clears up an issue I have had for a long time, and the world makes sense again, at least for a while.

PS how to prevent future files from sneaking into /home or /mnt when the occupants are not there?

1 Like

I told ya, didn’t I? :stuck_out_tongue:

The best way is to ensure that all filesystems are mounted at boot, either by way of /etc/fstab or by way of a systemd mount, instead of relying on automounting on login. It’s really not hard to do, and it can save you a lot of trouble later.

I’ve written a tutorial about it, too. :wink:


Ah, so you found the extra files and deleted them first.