Creating accounts on second disk partition


I want to purchase a second volume of disk to my cloud server and I want to ask you if it’s possible or if there is a solution to create user accounts on a second disk partition?

Currently user accounts are created by default under my first partition /home.

Do you know how I can accomplish that?

Thank you in advance.

Best regards.

No currently no support for it.

You could consider moving the home partition to it or somehow expand the current one…

1 Like

@eris, @arktex54

Thank you for your quick response.

But can be possible to change only the apache2 document root configuration for a user domain to point in the second disk / drive? Will this work?

No, access to (s)ftp / files / file mangers won’t be possible any more when moving the document root. Or you need to setup again all the correct privileges… And you will need to modify different scripts and then I still don’t know if it will work

For so far I know you have 2 options

  1. Expand the current /home dir
  2. Move the current /home dir to different partion…
1 Like

Hello @paulstoica18, as others already recommended the cleanest solution is to mount the new partition as /home

mount /dev/part_new to /mnt/largepart
rsync /home/ to /mnt/largepart                        # bulk: could take a long time
stop services (nginx apache2 exim4)
rsync /home/ to /mnt/largepart                        # diff: should take only a couple of secs
optional: remove data from old part /home/* to free up space
update /etc/fstab with a mountpoint to /home /dev/part_new

A second option to move a single user would be to use bind mount for user homefolder or for a subdir

mount /dev/part_new to /mnt/largepart
mkdir /mnt/largepart/home/user1
rsync /home/user1/ to /mnt/largepart/home/user1
stop services (nginx apache2 exim4)
rsync /home/user1/ to /mnt/largepart/home/user1
optional: remove /home/user1/* to free up space
mount --bind /home/user1 /mnt/largepart/home/user1
update /etc/fstab with the mountpoint
reboot or restart services

The second option could raise some problems when removing relocated users, you will have to test that.

Before doing this on the production server you should try/practice it on a test vm.