There is no need to move the VM nor a need to create many VMs-qcow2 storage images so I guess I can stick with 4.

The need is to easily redeploy the VM if needed (its / is a different drive than the storage one) and access the files inside the storage drive without hassle. So if I stay with 4 I can redeploy the VM, attach the qcow2 image and restore the fileserver to its pre-redeployment state.

The problem aren't the steps involved but the manual vs automatic side of the resizing. E.g. the partition inside the vm is full and a user tries to send a big file, is it easy to automate the resize of the partition so that the file can fit? If it requires manual intervention I can't use this solution.

I think that the qcow2 image doesn't have to be resized manually; only the partition inside it. When you create the image the size you specify is the max size it is allowed to reach. When I first tried this, I created a max-2TB image, the actual size of the image was 200KB.

You could set it up to expand if it hits some low disk space threshold

That's a good idea, I can be proactive about some things, e.g. it won't get suddenly more than 30GB of data, so I could maybe resize it once the free space is ~50GB. I'll look into it, thanks!

Yes, the VM will resize it. The problem is the partition inside the image, when I tried this method the image's actual size was ~200KB so when I tried to make a partition table inside it I was able to create a 200KB partition. I think that when this partition fills or something the VM will reserve more space inside the image that will appear as unallocated space in the guest, it won't grow the partition automatically. I might have overlooked something though, so I will try this method again.