I run my mailinabox on a small VPS with a 20G disk. The remaining space was getting tight, so I decided to go looking for some space and I discovered that /var/log/journal/ was consuming 1.8G. This was in logs only going back to March of this year which suggests lots of people may be losing a similar amount of storage.
I didn’t need to keep all the journals so I freed-up almost all the space with
journalctl --vacuum-time=10d
which preserves 10 days of journals. An alternative is to preserve by size with something like this
Oh wow I had no idea these logs existed. Great catch. We should add something to the setup to take care of this. Looks like /etc/systemd/journald.conf contains settings for this, currently:
#SystemMaxUse=
#MaxRetentionSec=
which according to the documentation are the max total disk size and the max retention length (time). I’m not sure what is preventing the logs from staying around forever because Ubuntu has these defaulted to off, but in any case, we could try setting the retention length (MaxRetentionSec) to 10 days, as you tried, during Mail-in-a-Box’s setup. I think that’s a reasonable default.
Yes, it seems reasonable. I administer two miab servers and hadn’t checked these logs. Now, that is not what you want from a security perspective. However, considering how the miab solution is positioned (simple installation, browser admin, web-mail and IMAP, etc) the typical miab admin probably only ssh’s to the server for software updates.
Hopefully, a sysadmin who needs to monitor those logs over a longer period would either do it more regularly than 10 days or would have a backup strategy that includes the journalctl logs. Or they read the support forum, see this thread and raise an objection.
Personally, as a user of MiaB not as a sysadmin I think that the logs do not need to be kept for long … maybe the 10 days proposed.
As a user of MiaB, I have referred to these logs ONLY when something has gone tilt.
We have to keep in mind the audience that MiaB is geared towards. Mainly the non-technical crowd.
The sysadmin types are going to be going through the code, so well documented code (which MiaB seemingly does well) noting to change this behaviour edit x should be sufficient as again, your typical user would not even know these logs even exists.
Look at your storage directory. Use du to determine where storage is used.
One other culprit might be the nextcloud backup dir /home/user-data/owncloud-backup. This is created when nextcloud is updated. But once nextcloud is running properly, you can delete the contents of that folder, or e.g. save the most recent one.
Of course, if you have many users and/or mails, those will obviously also take storage
