If your storage lives on a Windows server or a NAS that’s already sharing folders over SMB, you don’t need to set up a separate protocol just for Proxmox. Proxmox can mount an SMB share directly as CIFS storage and use it for ISOs, backups, and even VM disks. It speaks SMB natively, so there’s nothing to install on the host.
This guide covers both halves: making sure the share exists and is reachable, then adding it to Proxmox under Datacenter → Storage with credentials stored safely and the right content types enabled. It ends with the mount errors that come up most, because a CIFS share that won’t go active is almost always a credentials or protocol-version issue, not a Proxmox bug. Steps target Proxmox VE 8.x.
If your storage is a Linux box rather than Windows, adding NFS storage is usually the better fit — NFS tends to perform better with a Linux host. CIFS is the right tool when the share is Windows-based or your environment already runs on SMB.
Before you start
A CIFS mount has a few more moving parts than NFS because of authentication. Line these up first.
Before you start
- An SMB/CIFS share reachable from the Proxmox node
- The share path in UNC-style form, e.g. //192.168.1.20/proxmox
- A username and password with read/write access to the share
- The SMB version the server supports (2.1 or 3.x — never SMB1)
- A decision on what the share is for: ISOs, backups, or VM disks
That last point shapes the permissions you grant and the content types you enable. A backup target needs write access and the backup content type; an ISO library can be read-mostly. Decide the job before you create the share.
Step 1: Make sure the share exists and is reachable
On a Windows Server, create a shared folder through Server Manager or by right-clicking the folder, then Properties → Sharing → Advanced Sharing, and grant the Proxmox account read/write at both the share and NTFS level. On a NAS appliance (Synology, QNAP, TrueNAS), enable SMB and create the shared folder in the appliance’s web interface.
Before touching Proxmox, confirm the node can actually see the share. From the Proxmox shell:
# list the shares the server is offering, authenticating as your user
smbclient -L //192.168.1.20 -U proxmoxuserIf the share name doesn’t appear in that list — or you get an authentication error — fix the server side first. Proxmox can’t mount a share it can’t list or log into.
Step 2: Add the CIFS storage in Proxmox
With the share confirmed, go to the web interface: Datacenter → Storage → Add → CIFS. Proxmox probes the server and can autodetect the available shares once you provide credentials.
CIFS storage fields in Proxmox
| ID | A name for the storage in Proxmox, such as nas-cifs. Lowercase, no spaces. |
|---|---|
| Server | The SMB server's IP or hostname, e.g. 192.168.1.20. |
| Username / Password | An account with access to the share. Proxmox stores this in a protected credentials file. |
| Share | Click the dropdown to autodetect after credentials are entered, or type the share name. |
| Content | What this storage holds (see Step 4). |
| Nodes | Restrict to specific nodes, or leave on All for a cluster-wide share. |
After you fill in the server and credentials, the Share dropdown populates with whatever the server exposes to that account. An empty dropdown means the credentials can’t see any shares — go back and check the username, password, and share permissions on the server.
If you prefer the command line, pvesm adds the same storage and handles the credential file for you:
# add a CIFS share as Proxmox storage 'nas-cifs', for ISOs and backups
pvesm add cifs nas-cifs \
--server 192.168.1.20 \
--share proxmox \
--username proxmoxuser \
--password \
--content iso,backupThe --password flag with no value prompts you to type it interactively, which keeps it out of your shell history.
Step 3: Understand where the password is stored
This part is worth knowing because it affects security and troubleshooting. When you add CIFS storage with credentials, Proxmox does not put the password in the main storage config at /etc/pve/storage.cfg — that file is readable across the cluster. Instead it writes the password to a protected credentials file:
/etc/pve/priv/storage/<storage-id>.pwThat priv directory has tight permissions, so the password isn’t exposed to every read of the storage config. The practical takeaways: don’t hand-edit that file, and if you ever change the share’s password on the server, update it in Proxmox through the storage edit dialog so the credentials file is rewritten correctly.
Step 4: Choose the right content types
The Content setting decides what Proxmox will store on the share. As with other file-based storage, each content type gets its own subfolder, so one share can hold several kinds of data cleanly.
CIFS content types and what they store
| ISO image | Installer ISOs you attach to VMs. Stored under template/iso. |
|---|---|
| Container template | LXC templates for spinning up containers. Stored under template/cache. |
| VZDump backup file | vzdump backup archives. Stored under dump. A common reason to add CIFS. |
| Disk image | Live VM disks as qcow2 files under images. Bounded by SMB and network speed. |
| Container | Root filesystems for LXC containers. |
For most setups, CIFS works best as an ISO and backup share — enable ISO image, Container template, and VZDump backup file, and keep VM disks on faster local storage. That gives every node one place to grab installers and drop backups, which is exactly what a NAS is good at.
Running VM disks on CIFS is possible (enable Disk image), and because the disks are qcow2, snapshots work. But SMB adds protocol overhead on top of the network, so a busy VM will feel slower than on local SSD. Test throughput before you put anything important on it.
Step 5: Confirm it’s working
Once added, the storage shows up in the left-hand tree under each assigned node. A healthy CIFS storage displays usage figures; an inactive one shows a grey/question-mark icon.
Check from the shell:
# is the CIFS share mounted? look for it in the mount list
mount | grep cifs
# Proxmox's own view of every storage and whether it's active
pvesm statusA line in pvesm status showing active with real numbers means you’re done. Upload a small ISO or run a test backup to it to confirm the full round trip works, not just the mount.
Troubleshooting a CIFS share that won’t mount
This is where CIFS storage usually gets stuck. Work through it in order — the fix is nearly always credentials or the SMB version.
Authentication fails. Re-test with smbclient -L //server -U user. If that fails too, the problem is the username, password, or share permissions on the server, not Proxmox. Confirm the account has access at both the share and filesystem level.
The share mounts on some servers but not an older NAS. This is usually an SMB dialect mismatch. Pin the version in the storage options or in /etc/pve/storage.cfg:
cifs: nas-cifs
server 192.168.1.20
share proxmox
content iso,backup
username proxmoxuser
smbver 3.0Try smbver 3.0 first; drop to 2.1 only if the server is genuinely that old. After editing the config, the change applies on the next mount.
Permission denied writing backups. The mount succeeded but the account is read-only. Grant write access on the server side at both the share and NTFS/filesystem level, then retry — no Proxmox change needed once permissions are fixed.
Wrapping up
Adding SMB/CIFS storage to Proxmox is two jobs that meet in the middle: confirm the share is reachable and the account can write to it, then add it under Datacenter → Storage with credentials Proxmox stores safely in /etc/pve/priv. For ISOs and backups it’s reliable and simple; for live VM disks, test the network and server throughput first, because SMB overhead adds up.
If your storage is Linux-based instead, compare with adding NFS storage to Proxmox, which is often the better performer for a Linux host. To build a backup routine around this share, see Proxmox backup and restore, and for the local storage layout on the host itself, LVM vs LVM-Thin vs ZFS is the companion piece. For more walkthroughs, browse the Proxmox guides.
