Sort of running out of disk space [solved but not elegantly]

I have a 1TB and a 500G drive in the server, so I know I am not really running out of space. As admitted before, I am very much a Mac user that is trying his best to understand Ubuntu (and sometimes not doing a very good job of it). This is one of those times.
Where is the rest of my space? Do I have something set up wrong with MiaB given my hard drives? The idea was that 500g should be enough and the 1TB was to save multiple archives over time (in case someone wanted to ask me about an email from 2 months ago).

Hopefully this accurately shows what is needed to give me some advice…

Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-105-generic x86_64)

System information as of Sun Apr 28 03:58:12 AM PDT 2024

System load: 1.9033203125
Usage of /: 74.4% of 97.87GB
Memory usage: 2%
Swap usage: 0%

krettig@mail:~$ sudo fdisk -l [here are just the relevant parts, hopefully]

Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: ********

Device Start End Sectors Size Type
/dev/sda1 2048 1953523711 1953521664 931.5G Linux filesystem

Disk /dev/nvme0n1: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 970 EVO Plus 500GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: ********

Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 2203647 2201600 1G EFI System
/dev/nvme0n1p2 2203648 6397951 4194304 2G Linux filesystem
/dev/nvme0n1p3 6397952 976771071 970373120 462.7G Linux filesystem

krettig@mail:~$ sudo df -h

Filesystem Size Used Avail Use% Mounted on
tmpfs 3.2G 1.8M 3.2G 1% /run
/dev/mapper/ubuntu–vg-ubuntu–lv 98G 73G 20G 79% /
tmpfs 16G 0 16G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/nvme0n1p2 2.0G 377M 1.5G 21% /boot
/dev/nvme0n1p1 1.1G 6.1M 1.1G 1% /boot/efi
tmpfs 3.2G 4.0K 3.2G 1% /run/user/1000

Hi, your drive partitioning is probably not what you really wanted :wink:

From the output, it looks like you’ve only got 98G of the big disk allocated to / and the rest of that disk doesn’t seem to be used. It is possible to resize … the first answer on https://askubuntu.com/questions/1374495/resize-ubuntu-lv makes sense to me.

Personally, I would have used a different partition scheme … maybe put all of ubuntu and MIAB on the SSD (being all of /, /boot, /boot/efi and also a swap partition) because that will benefit from the speed. Then use the big disk for backups only. Or if you have lots of user data, you could mount the big disk on /home/user-data (which contains the mailboxes and backups).

I actually don’t remember doing any partition scheme but I must have. I was likely thinking OS on the 100 and then MiaB on the rest.

you could mount the big disk on /home/user-data (which contains the mailboxes and backups).

This makes the most sense to me. I have a few users that apparently do not know about the concept of deleting email.

Fist mount the big partitian. And read this on how to change the path. It seems to work after installation if you copy /home/user-data of course while copying, preserve the permissions.

Change Default Location - #5 by alento If you need to use root as user

sudo su root

Or resize the 100GB disk but this might give you a headache.

I tried to resize the partitions on a test server but it didn’t work, so I just reinstalled Ubuntu Server starting over from the beginning. Failed on first start up because the install process had set the user of the disk to LVM Group and it didn’t work. So I reinstalled again and turned that default option off and it worked.
Now I am testing moving all of the user-data from one machine to another.

Moving all of the user-data directory appears to have worked perfectly.
Takes a long time to compress 40 gigs, even longer to download to my home (where I was working on the test server), and then a bit to decompress. Kept writing the ‘sudo mv source destination’ command wrong…put the directory in the wrong place like four times due to over specifying the destination and/or low level skills of when to use the trailing slash or not.

Going to do it for real in the next day or so.

1 Like

Use copy

sudo cp -rp
to preserve ownership

Or you might find rsync does the job easily. It handles file attributes, compression, updates, etc nicely. Something like rsync -azv host:src/ dest but check the man page.

1 Like