/srv/jail on fresh HestiaCP install — can it be safely removed?

Community Support
1

Hi everyone,

I’ve recently set up a brand new server running HestiaCP v1.9.3 on Debian 12. After a few days of basic configuration, I noticed that the /srv/jail directory is taking up around 27 GB of disk space.

Here’s the situation:

  • No Hestia users have a jail shell or SSH access enabled.
  • All users are set to /sbin/nologin.
  • The server is used solely for website hosting through the panel (no SSH or SFTP access for users).
  • The /srv/jail folder contains a directory for each user with subfolders like conf/mail, conf/web, conf/dns, etc.
  • I tried removing the folder with sudo rm -rf, but got Operation not permitted errors on some subfolders.

My questions:

  1. Is it normal for /srv/jail to be populated automatically, even if no jailed users exist?
  2. What exactly is the purpose of this jail directory in this context?
  3. Can I safely delete /srv/jail without breaking anything in Hestia?
  4. Is there a recommended procedure to fully remove it (handling immutable files, permissions, etc.)?

Thanks in advance for your help and clarification!

Best regards

2

It is a symbolic link so it should not cost any extra store store

SSH jail for “additional ftp user”

3

Thanks for the quick reply!

That’s helpful — however, I’m seeing that the /srv/jail folder is actually using ~27 GB of real disk space (confirmed via du -sh), so it doesn’t seem to be just symbolic links.

I understand it might be related to SSH jail for additional FTP users, but in my case:

  • No users have shell access enabled (all set to /sbin/nologin)
  • No users were manually set to use a jail shell
  • The server is brand new (just a few days old)
  • I haven’t created any additional FTP users so far

So I’m wondering if the content inside /srv/jail is really needed, or if it was pre-generated by Hestia automatically.

Do you confirm it’s safe to delete /srv/jail if no jailed or FTP chrooted users are currently in use?

Thanks again for your insight!

4

No, it isn’t. It’s the real content of your user, DON’T DELETE it.

Take a look to this post:

2 Likes
6

thanks for the information. I was just going to comment it wasnt a symbolic link. EDIT - but it is just as you say a bind mount

mount| grep srv
/dev/vda1 on /srv/jail/admin/home/admin type ext4 (rw,relatime,errors=remount-ro)

1 Like
7

Thanks. Now i have brocken all my setup.

I’m facing an issue restoring a backup created through the HestiaCP web interface.

Context:

  • HestiaCP version: 1.9.3
  • OS: Debian 12 (fresh install)
  • A user backup was created using the web interface (Users > Backups > Create Backup)
  • The backup .tar file was downloaded, renamed to follow the standard format:
    backup-username-YYYY-MM-DD_HH-MM-SS.tar
  • File was placed in /backup, with correct ownership (root:root) and permissions (640)

Problem:

When running the following command:
bash
/usr/local/hestia/bin/v-restore-user username /backup/backup-username-YYYY-MM-DD_HH-MM-SS.tar

I get this error:

Error: invalid backup format :: /backup/backup-username-YYYY-MM-DD_HH-MM-SS.tar

8

You must use only the file name, not the full path:

Note: the backup file name format is username.YYYY-mm-dd_HH-MM-SS.tar

/usr/local/hestia/bin/v-restore-user username username.YYYY-mm-dd_HH-MM-SS.tar
2 Likes
9

Thanks Sahsanu ! It WorkS!

1 Like
10

Shouldn’t more /srv/jail be created after switching to bubblewrap?

11

It is still used for additional (s)ftp users and users that are set to no login