Why does proxmox-ve have a dependency on samba-common?

greenfreq

New Member
Oct 21, 2025
2
1
1
During a package audit, I noticed that several Samba-related packages — including samba-common, samba-common-bin, smbclient, and supporting libraries — are installed by default.

When I ran a dry-run purge to see what would happen, APT reported that removing `samba-common` would also remove critical core packages such as:

pve-manager
pve-container
pve-ha-manager
qemu-server

This implies Proxmox’s core stack depends directly (or indirectly) on Samba being present, even when CIFS/SMB storage is not configured or used.

My Concern:

From a security and hardening standpoint, it’s generally desirable to reduce the installed footprint and eliminate unnecessary network-exposed components. While Samba itself is not running as a daemon in this configuration, having these packages installed by default:
  • Expands the potential attack surface,
  • Increases patching overhead,
  • And may introduce latent vulnerabilities in environments where SMB is never used.
My Questions:

  1. Is there a technical reason that `pve-storage` and other components must depend on smbclient/samba-common instead of treating CIFS support as optional?
  2. Does the Proxmox team have plans to split CIFS support into a separate, optional package (e.g., pve-storage-cifs) so minimal or hardened deployments don’t have to carry the dependency?
  3. Is there any supported method to safely remove or mask these packages when SMB/CIFS is not used?

Additional Context

It is worth noting that this installation was performed by a cloud provider and that there may have been an option to install without samba-core; however, it is no longer as simple as apt purge...

  • Proxmox VE 9, default install (ZFS root)
  • No CIFS storage defined
  • Environment runs isolated VMs only
  • Goal: minimal attack surface / compliance with internal hardening standards
Thanks in advance — I’d really appreciate any clarification or best-practice guidance from the Proxmox team or community members who’ve looked into package minimalism and dependency trimming.
 
Thank you for reaching out with this.

This implies Proxmox’s core stack depends directly (or indirectly) on Samba being present, even when CIFS/SMB storage is not configured or used.
Because PVE supports mounting it as you already pointed out. This could be improved however.


Therefore also other package requirements are there like iscsi, NFS and ceph, however, nfs-common and ceph-common are also a hard requirement and cannot be removed according to apt, open-iscsi is not. So those two need to be included in your analysis aswell and package feature request (e.g. pve-storage-ceph, pve-storage-nfs) need to be mentioned accordingly. As always, there is a but coming ... The QEMU binary depends on some of them, namely libiscsi and libceph, so both cannot be omitted because the QEMU binary is linked against it. However, there is no hard requirement for nfs or cifs in the binary so those two can be analysed further. Maybe someone from Proxmox can chime in here, or we can create a feature request.

Just to mention it, local filesystem userland drivers can be removed without any hard requirement. This is true for zfs, xfs and btrfs.
 
Thank you for reaching out with this.


Because PVE supports mounting it as you already pointed out. This could be improved however.


Therefore also other package requirements are there like iscsi, NFS and ceph, however, nfs-common and ceph-common are also a hard requirement and cannot be removed according to apt, open-iscsi is not. So those two need to be included in your analysis aswell and package feature request (e.g. pve-storage-ceph, pve-storage-nfs) need to be mentioned accordingly. As always, there is a but coming ... The QEMU binary depends on some of them, namely libiscsi and libceph, so both cannot be omitted because the QEMU binary is linked against it. However, there is no hard requirement for nfs or cifs in the binary so those two can be analysed further. Maybe someone from Proxmox can chime in here, or we can create a feature request.

Just to mention it, local filesystem userland drivers can be removed without any hard requirement. This is true for zfs, xfs and btrfs.
I think any feature request in this area would need to be fairly broad, since it’s easy to overlook a package or two that may not be strictly required for Proxmox to operate. If the goal is to support environments with FIPS, CIS, or NIST-related requirements, it may be worth considering a more minimal dependency footprint — something closer to just the essential components. That kind of shift would likely require placing more trust in users to install and configure additional tools based on their specific needs.

I imagine making that process more accessible through the UI would take a significant development effort. Also, I’m not entirely sure whether the current dependency set is part of Proxmox by default or introduced by my cloud provider — so there could be some variability in play here.
 
  • Like
Reactions: Johannes S