I am attempting to move some folders (such as /var and /home) to a separate partition after reading this guide:

3.2.1 Choose an intelligent partition scheme

I was able to move one folder successfully following thisguide.

However, it doesn't seem to work for multiple folders, and all my folders are dumped into the partition without proper folders.

I would like to mount /var, /home, and /tmp onto the separate partition; can someone guide me on this?

  • Did you make an extra partition for each of the directories or just one?
    – mreithub
    Commented May 21, 2014 at 12:44
  • @mreithub i would like it to be ideally all stored within the same partition and only varies with folder. in that way it is much simpler for me, not having to worry about the space. Commented May 21, 2014 at 13:16
  • 1
    I don't recommend putting /var on a separate partition. There's no benefit to it. Keep the whole OS on a single partition (/). Use separate partitions only for things that are not the OS — user data in /home, mail spool (if you have a big one) in /var/mail, databases in e.g. /var/lib/mysql or /srv, … Commented May 21, 2014 at 23:32
  • 13
    @Gilles "There's no benefit to it"?????? (Maybe I need more question marks). Of course there's a benefit to it. / is mostly static. /var is almost entirely dynamic. If you mount /var on a separate partition, you can mount the root partition read-only. There are a ton of situations where that is a Good Thing™.
    – Auspex
    Commented Jan 30, 2016 at 20:52

6 Answers 6


1. First you need some unallocated space to create the partitions for each mountpoint (/var, /home, /tmp). Use Gparted for this.

2. Then you need to create the filesystems for those partitions (can be done with Gparted too) or use:

mkfs.ext4 /dev/sdaX

for example to create a new ext4 filesystem on the /dev/sdaX device (replace /dev/sdaX with your own device)

3. Mount the new filesystem under /mnt

mkdir /mnt/var        
mount /dev/sdaX /mnt/var

4. Go to single-user mode so that there is no rw activity on the directory during the process

init 1

5. Enter your root password.

6. Backup data in var only (not the /var directory itself)

cd /var
cp -ax * /mnt/var

7. Rename the /var directory after your data has been transferred successfully.

cd /
mv var var.old

8. Make the new var directory

mkdir var

9. Unmount the new partition.

umount /dev/sdaX

10. Remount it as /var

mount /dev/sdaX /var

11. Edit /etc/fstab file to include the new partition, with /var being the mount point, so that it will be automatically mounted at boot.

/dev/sdaX       /var     ext4    defaults    0 0

12. Repeat steps 1-11 for /home and /tmp.

13. Finally return to multitasking mode.

init 5
  • yeah i was thinking of using gparted. thanks for the answer. i am planning to set aside 30gb space for these few folders actually /home, /tmp, /var/, /opt, /usr/, do you have a rough gauge of how much i should give accordingly (for a simple hosting server)? Commented May 21, 2014 at 13:03
  • 1
    i was looking up on using lvm, would that be better as compared to gparted? Commented May 21, 2014 at 13:03
  • LVM is a completely different topic. LVM is used as a layer to create logical volumes on top of physical harddisks. Gparted is only the tool to create the LVM physical volumes.
    – cioby23
    Commented May 21, 2014 at 14:11
  • 2
    Actually, cp -ax * /mnt/var is a bad idea, because it'll ignore hidden files/dirs. Prefer cp -ax . /mnt/var. (@cioby23, I think you should update your answer)
    – berbt
    Commented May 26, 2016 at 22:55
  • 7
    Please add a final init 5 to the answer. Commented Aug 19, 2016 at 8:38

If you want to use them all on the same partition you can either use LVM or three simple bind mounts.

To create a bind based solution you

  1. create a partition with a filesystem
  2. go to rescue mode (single user still needs some of the folders)
  3. mount it as /mnt/data
  4. Move all folders you want to move. Using cp and mv dir dir.old might be safer, but since I did this after install it did not matter to me.

    mv /home /mnt/data/
    mv /var  /mnt/data/
  5. create appropriate bind mount entries in fstab, for example I have

    UUID=01234567-89abc-def0-1234-567890abcde /mnt/data         ext4          noatime,nodiratime,relatime                           0       0
    # Binds
    /mnt/data/opt                             /opt              none          bind                                                  0       0
    /mnt/data/home                            /home             none          bind                                                  0       0
    /mnt/data/usr                             /usr              none          bind                                                  0       0
  6. reboot

  • In the mount(8) man page under nodiratime it says: If noatime option is set, this option is not needed. Is there a redundancy advantage in including it anyway? Commented Feb 27, 2017 at 12:09
  • @brannerchinese there’s no advantage whatsoever: lwn.net/Articles/244941
    – Gaston
    Commented Jun 19, 2020 at 14:01
  • I'm having a boot failure: Failed to start Remount Root and Kernel File Systems. Not entirely unexpected. What am I supposed to do about it? Commented Oct 27, 2021 at 10:01
  • As it turned out, I had to create empty directories /var, /opt, etc. on the root partition in place of the ones moved out to another partition. Commented Oct 27, 2021 at 11:58

I'd personally either go with @Fabian's bind-mount solution or use symlinks:

  1. create /etc/fstab entry for the new partition (use blkid to get the right UUID for your new partition and don't forget to mkdir /mnt/data):

    UUID=01234567-89abc-def0-1234-567890abcde  /mnt/data  ext4  defaults  0 0
  2. Use mount -a or something similar to mount the new partition

  3. move the original folders to your new partition:

    mv /var /mnt/data/
    mv /home /mnt/data/
    # ... (you get the point)
  4. Create symlinks

    ln -s /mnt/data/var /var
    ln -s /mnt/data/home /home
    # ...

Although the bind-mount method is probably the best practice solution I kind of prefer this one because you don't end up with unnecessarily long df and mount partition lists.

  • 1
    What happens with the respective methods if something wants /var before it's mounted? I rather suspect that the bind method will be cleaner, but I really don't know.
    – Auspex
    Commented Jan 30, 2016 at 22:05
  • @Auspex There shouldn't be a difference between the two methods in that regard (as afaik all local partitions in /etc/fstab are mounted at the same time during boot). Before /mnt/data gets mounted all your symlinks would be 'dead', so any read/write attempt on them (and on non-existent subdirs) would fail (with ENOENT if I remember correctly). With bind-mounts you get pretty much the same result but programs might actually write onto the root partition (if they try to be smart about non-existing directories)
    – mreithub
    Commented Jan 31, 2016 at 0:15
  • 1
    Well, that's not strictly true. Root gets mounted first, and I specifically asked because Debian's "Read-only root" advice mentions the possibility of processes wanting to access /var before it's mounted. But in my case, where I have a Raspberry Pi and have set up a read-only filesystem on / (because the SD card keeps getting corrupted when the power goes out to the machine), you're encouraging me that either method will work. Nothing's going to write onto the root filesystem, because it's RO, so either case will result in an error.
    – Auspex
    Commented Jan 31, 2016 at 19:55

In addition to the procedure given cioby23, I also had to do:

  restorecon -R /var

in order for sshd to start.

  • This should be a comment...
    – Jack_Hu
    Commented Jun 6, 2020 at 18:44

mounting your /var directory on a different partition. Let’s get started by attaching a new LVM, partitioning, and creating a desired file system.

Create a LVM Using New Disk: /dev/sdb

# pvcreate /dev/sdb
# vgcreate  vg_var /dev/sdb
# vgdisplay
# df -Th
# lvcreate -n lv_var -l +<PE Free Size>
# mkfs.xfs /dev/mapper/vg_var-lv_var
# lsblk

Create a new mount point and mount your new partition:

 # mkdir /mnt/var
 # mount /dev/mapper/vg_var-lv_var  /mnt/var/

Start Sync /var to the new temporary mounted partition

# rsync -aqxP /var/* /mnt/var  

Unmount the temporary Partition after a successful sync

# umount  /dev/mapper/vg_var-lv_var /mnt/var/
# lsblk

Edit your /etc/fstab to include a new partition and choose a relevant file system:

/dev/mapper/vg_var-lv_var  /var                 xfs     defaults        0 0

Reboot your system and you are done. Confirm that everything is working correctly and optionally remove the old var directory by booting to some Live Linux system etc.


Is there a way to skip the unmounting of var ( running processes)? Under new Debian versions even root in init 1 mode is denied access to renaming var into var.old when process is running (in log/journaling for example).

You could create a varnew partition following all of Stephen's steps, then

following the edits mentioned in Stephen Rauch's solution in etc/fstab:

add stephen's line (before!) the previous line where var was mentioned

/dev/sdaX /var ext4 defaults 0 0

then change the old name in the old line in fstab from var to varnew, for example:

yourPhysicalVolumeGroup-VG-var /var

would becomes

yourPhysicalVolumeGroup-VG-var /varnew

and this would be implemented upon your system restart without affecting on-going processes in /var at the time of the editing.

then in normal or init 5 mode, sudo rm -R var would be possible.

  • Stephen Rauch did not post an answer to this question although he did edit another answer. Your answer supposes a move from physical partitions to LVM, something that is probably impossible and would require a reinstall.
    – doneal24
    Commented Feb 2, 2023 at 20:37

You must log in to answer this question.

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