Linux Samba server or LXC Container?

[baron164]

I have unutilized storage on my Proxmox hosts and I want to utilize some of it for a samba share. I would normally just create a new Linux server with a virtual disk and make it a samba server. But I see that Proxmox has the ability to do containers, so I am wondering if I should instead of building a vm for samba access, build a container instead?

I am not familiar with how containers in Proxmox work but I am interested and willing to learn.

 

[Dunuin]

In case you want to back it up to a PBS I would stick with VMs.

 

[Nollimox]

I would normally just create a new Linux server with a virtual disk and make it a samba server.

Bear in mind that using a container won't create any separation...what I have done is to use OpenMediaVault which is based on Debian...it's lightweight VM on Proxmox

 

[baron164]

Bear in mind that using a container won't create any separation...what I have done is to use OpenMediaVault which is based on Debian...it's lightweight VM on Proxmox

Thanks, how does OpenMediaVault compare to something like TrueNAS Core (FreeNAS)?

 

[Dunuin]

Thanks, how does OpenMediaVault compare to something like TrueNAS Core (FreeNAS)?

TrueNAS only supports ZFS. So you have to keep ZFS recommendations in mind like NO hardware raid, lots of (preferably ECC) RAM, no consumer SSDs and especially not QLC NAND nor HDDs using shingled magnetic recording.
So TrueNAS is probably the worst option if you just want something lightweight and simple.

 

[gfngfn256]

In case you want to back it up to a PBS I would stick with VMs.

Why is this? Can't you just backup the complete container to PBS?

 

[Dunuin]

Why is this? Can't you just backup the complete container to PBS?

You can, but each time you will have to read the full size of that LXC as only VMs could make use of dirty-bitmapping. So backing up a VMs would be way faster. Lets say you want to share 1TB of data and your data only changes 1GB between backups. An LXC would always need to read the full 1TB. A VM only needs to read the 1GB that changed and could ignore the other 999GB.

 

[tonycav]

Hi, my current situation is this

- My Samba server should be lightweight because the disk containing the files would be mounted externally
- I backup my files with rsync (no PBS)

I don't know whether to install samba on an Ubuntu or LXC virtual machine
I would like to understand
Thank you for your time

 

[LnxBil]

I don't know whether to install samba on an Ubuntu or LXC virtual machine

What is your question exactly? Ubuntu is an OS and LXC is a container technology. You can use both, one of them of none of them.

 

[tonycav]

Forgive my poor English
I need to install samba on an Ubuntu VM or an Ubuntu LXC
considering what was written previously

 

[LnxBil]

I need to install samba on an Ubuntu VM or an Ubuntu LXC

This is not a Proxmox VE related question, but an Ubuntu related question. Please see their official documentation.

 

[BobhWasatch]

Use a VM instead of a container.

 

[frankco]

Use a VM instead of a container.

Any reason in particular for choosing a VM in this scenario?

 

[Ramalama]

Any reason in particular for choosing a VM in this scenario?

Read what @Dunuin said.

My preferred way tbh is to use LXC-Containers and Passthrough a ZFS Folder (dataset) from the Host to the Container.
Those datasets which i passthrough, have all Hourly ZFS-Snapshots and are only exclusively for the Samba Shares.
And Samba has VSS enabled or defined, so i can restore Files simply on Windows natively.
The PBS just backups this way the OS Only and the Shares itself are "snapshotted".

Its very lightweight but too Complicated for a Beginner to Setup i think.

Just my 3 Cents, Cheers

 

[gfngfn256]

Any reason in particular for choosing a VM in this scenario?

Apart from above mentioned point/s, using an external disk/device to passthrough to an unprivileged LXC, usually means you have to mount it to the host & then passthrough the mountpoints to the LXC etc. This comes with its own hurdles & issues. See here for example.