Proxmox CIFS “Permission denied”: fix credentials, SMB dialect, and mount options

December 24, 2025 • February 3, 2026 • Read: 9 min • Views: 9

Was this helpful?

You’ve got the right username. You’ve got the right password. You’ve tried vers=3.0, vers=2.1, maybe even the nuclear option. And Proxmox still says: Permission denied.

This is the part where CIFS/SMB teaches humility. “Permission denied” might mean “bad password”… or it might mean “your NAS hates your SMB dialect,” “your UID mapping is nonsense,” “the share allows read-only,” or “you authenticated fine but failed authorization.” Same error. Different crime scene.

Fast diagnosis playbook

If you want the shortest path from “Permission denied” to a working mount, do this in order. Don’t improvise. CIFS punishes creativity.

1) Confirm the error is auth, not network or name resolution

Can you resolve the server name from the Proxmox node?
Can you reach TCP/445?
Can you negotiate SMB dialect at all?

If DNS or routing is wrong, you’ll usually see timeouts or “No route” errors, not “Permission denied.” Usually.

2) Validate credentials with `smbclient` (not with your memory)

If smbclient can’t list the share, the mount won’t either. If it can, you’ve proven auth and basic share access, and you can focus on mount options, UID/GID mapping, and Proxmox’s usage.

3) Force an explicit SMB dialect and security mode

Set vers=3.0 (or 3.1.1 if supported), and explicitly set sec=ntlmssp or sec=krb5 depending on your environment. Dialect mismatches often show up as auth failures because the handshake never gets to the part where your password matters.

4) Separate “mount works” from “Proxmox can use it”

You can mount a share and still fail when Proxmox tries to create directories, lock files, or set permissions. Proxmox storage plugins have expectations (ownership, write access, consistent file modes). Test with the same user/context Proxmox will effectively use.

5) Read the kernel logs

dmesg will often say what CIFS refused, what security mode was attempted, and what status code came back. Proxmox GUI errors are famously minimalist. The kernel is not.

What “Permission denied” actually means in CIFS

On Linux, CIFS is implemented by the kernel module and driven by mount.cifs. When something fails, you might see:

mount error(13): Permission denied
CIFS: VFS: cifs_mount failed w/return code = -13

Error 13 is “EACCES.” It’s a bucket that catches multiple failure modes:

Bad credentials: wrong username/password, wrong domain, expired password, locked account.
Bad auth mechanism: server requires Kerberos, client tries NTLM; server requires signing, client can’t; server rejects guest access.
Share-level deny: user can authenticate but isn’t allowed to access the share.
Filesystem-level deny: share is accessible, but NTFS/ACL denies folder creation or writes.
Protocol mismatch: SMB1 disabled; client tries SMB1; some systems respond with confusing auth-related errors.
Encryption/signing policy mismatch: server enforces it, client doesn’t comply (or vice versa), and the failure surfaces as access denied.

One dry comfort: CIFS has exactly one talent—making different problems look identical.

Interesting facts and history that explain today’s pain

SMB started in the 1980s at IBM and was popularized by Microsoft; it’s older than many of the “modern” storage stacks it now haunts.
“CIFS” is basically SMB1 as branded by Microsoft in the 1990s. Linux folks still say “mount CIFS” even when negotiating SMB3.
SMB1 is effectively dead for security reasons; many servers disable it by default. Clients trying SMB1 can get misleading failures.
SMB2 arrived with Windows Vista/Server 2008 and fixed major performance problems (fewer round trips, pipelining, better caching behavior).
SMB3 (Windows 8/Server 2012 era) introduced encryption, multichannel, and better resilience—features that change how “permission denied” shows up under policy enforcement.
NTLM is a compatibility workhorse and a security liability; enterprises increasingly force Kerberos or disable NTLM, which breaks “it worked last year” scripts.
Linux CIFS file mode semantics are synthetic: file_mode/dir_mode do not rewrite server ACLs; they’re client-side presentation unless Unix extensions / POSIX mapping is used.
Extended attributes matter: mapping Windows ACLs to Linux permissions uses xattrs; disabling them can turn “works in Explorer” into “permission denied” on Linux.
SMB signing used to be a “maybe”; now it’s often mandatory in hardened environments. When mismatched, the error is rarely friendly.

Proxmox context: where CIFS mounts live and how PVE uses them

Proxmox VE (PVE) is Debian-based. When you add a CIFS storage in the GUI, Proxmox generally:

Stores config in /etc/pve/storage.cfg (cluster filesystem).
Mounts the share under /mnt/pve/<storageid>.
Uses pvesm to activate the storage, and systemd mount units may be involved depending on version and how it’s configured.

Proxmox isn’t special here. It’s Linux. But Proxmox is opinionated about storage behavior:

Backup jobs need reliable write access and stable file locking semantics.
ISO/template stores are mostly read-heavy but still need directory creation during uploads.
Some features behave poorly on flaky SMB shares (especially when the NAS has “helpful” opportunistic locking policies).

Rule: First make the mount work on the CLI. Then make Proxmox happy. If you do it in reverse, you’ll blame the GUI for a kernel problem.

Hands-on tasks: commands, outputs, and decisions (12+)

Each task below has: a command, realistic output, what it means, and what decision you make next. Run these on the Proxmox node that’s failing.

Task 1: Confirm the hostname resolves the way you think

cr0x@server:~$ getent hosts nas01
192.168.50.20   nas01.lab.local nas01

Meaning: The node resolves nas01 to 192.168.50.20. If it resolves to an old IP, you’ll “authenticate” against the wrong host and lose hours.

Decision: If resolution is wrong, fix DNS or use the IP address in the Proxmox storage definition temporarily to eliminate ambiguity.

Task 2: Verify TCP/445 is reachable (no guessing)

cr0x@server:~$ nc -vz nas01 445
Connection to nas01 445 port [tcp/microsoft-ds] succeeded!

Meaning: Network path and firewall allow SMB. If this fails, “Permission denied” might be a red herring from a middlebox or a fallback path.

Decision: If it fails, stop. Fix routing/firewall/VLAN/ACLs before touching credentials.

Task 3: See what SMB dialects the server advertises

cr0x@server:~$ smbclient -L //nas01 -m SMB3 -U 'LAB\backupuser'
Password for [LAB\backupuser]:
        Sharename       Type      Comment
        ---------       ----      -------
        backups         Disk      Proxmox Backups
        isos            Disk      ISO Library
        IPC$            IPC       IPC Service (NAS)
SMB1 disabled -- no workgroup available

Meaning: We can authenticate and list shares using SMB3. The “SMB1 disabled” line is good news.

Decision: If listing shares fails with NT_STATUS errors, fix auth/domain/dialect first. Don’t touch mount options yet.

Task 4: Test access to the specific share (list a directory)

cr0x@server:~$ smbclient //nas01/backups -m SMB3 -U 'LAB\backupuser' -c 'ls'
Password for [LAB\backupuser]:
  .                                   D        0  Wed Dec 25 10:21:11 2025
  ..                                  D        0  Wed Dec 25 10:21:11 2025
  pve01                               D        0  Tue Dec 24 18:02:44 2025

                52403200 blocks of size 1024. 39122432 blocks available

Meaning: Auth and share-level authorization are fine. If mount still fails, suspect dialect/security options, creds formatting, or kernel CIFS quirks.

Decision: If this works but mounting fails, read dmesg after a mount attempt and compare security/dialect negotiation.

Task 5: Try a manual mount with explicit, boring options

cr0x@server:~$ sudo mkdir -p /mnt/test-backups
cr0x@server:~$ sudo mount -t cifs //nas01/backups /mnt/test-backups -o username=backupuser,domain=LAB,vers=3.0,sec=ntlmssp,iocharset=utf8,nounix,uid=0,gid=0,file_mode=0640,dir_mode=0750
cr0x@server:~$ mount | grep test-backups
//nas01/backups on /mnt/test-backups type cifs (rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=backupuser,domain=LAB,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.50.20,file_mode=0640,dir_mode=0750,nounix,serverino,mapposix,acl,rsize=1048576,wsize=1048576,actimeo=1)

Meaning: The mount works. That already tells you the world: kernel CIFS is fine, network is fine, auth is fine. Now the issue is probably Proxmox config, credentials storage, or different options being used.

Decision: Diff your successful options against Proxmox’s options. Make Proxmox behave like your manual mount.

Task 6: If the mount fails, immediately read kernel logs

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Thu Dec 26 09:11:07 2025] CIFS: Attempting to mount //nas01/backups
[Thu Dec 26 09:11:07 2025] CIFS: VFS: \\nas01 Send error in SessSetup = -13
[Thu Dec 26 09:11:07 2025] CIFS: VFS: cifs_mount failed w/return code = -13

Meaning: Authentication setup failed, not path resolution. When it’s “SessSetup,” it’s almost always credentials, domain, security mode, or server policy (signing/NTLM restrictions).

Decision: Force vers and sec. If using AD, consider Kerberos (sec=krb5) and verify time sync.

Task 7: Inspect what Proxmox thinks the storage is

cr0x@server:~$ cat /etc/pve/storage.cfg
cifs: smb-backups
        path /mnt/pve/smb-backups
        server nas01
        share backups
        username backupuser
        domain LAB
        content backup
        options vers=3.0,sec=ntlmssp,iocharset=utf8,nounix

Meaning: Proxmox stores the definition here. If options is missing, Proxmox may use defaults you won’t like.

Decision: Add explicit options. If a password is stored elsewhere, ensure it matches and isn’t truncated or mis-escaped.

Task 8: Activate the storage and watch the exact error

cr0x@server:~$ sudo pvesm status
Name         Type     Status           Total            Used       Available        %
local        dir      active       24545689600      7512332288     17033357312   30.60%
smb-backups  cifs     inactive              0               0               0    0.00%
cr0x@server:~$ sudo pvesm activate smb-backups
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

Meaning: Proxmox is failing to mount even if your manual test worked (or you haven’t tested manually yet).

Decision: If manual mount succeeds but pvesm fails, Proxmox is not passing the same options or is using different credentials handling. Capture the mount command being executed (see next task).

Task 9: Trace the mount attempt (yes, with strace)

cr0x@server:~$ sudo strace -f -o /tmp/pvesm.strace pvesm activate smb-backups
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
cr0x@server:~$ tail -n 30 /tmp/pvesm.strace
execve("/usr/sbin/mount.cifs", ["mount.cifs", "//nas01/backups", "/mnt/pve/smb-backups", "-o", "username=backupuser,domain=LAB,vers=3.0,sec=ntlmssp"], 0x7ffd0a1c2c90 /* 18 vars */) = 0
...
write(2, "mount error(13): Permission de"..., 39) = 39

Meaning: Proxmox is calling mount.cifs without your full set of options. Missing nounix, iocharset, UID/GID, etc. Sometimes those omissions matter; sometimes they just change how permissions are presented after mount.

Decision: Put the missing options into the Proxmox storage definition. Don’t rely on defaults across kernel updates.

Task 10: Use a credentials file (and fix its permissions)

cr0x@server:~$ sudo install -d -m 0700 /root/.cifs
cr0x@server:~$ sudo bash -c 'cat > /root/.cifs/nas01-backups.cred <

Meaning: This removes shell escaping issues and avoids leaking secrets in process lists. The permissions matter; too-open credentials files can be rejected or just be a bad day.

Decision: Prefer a credentials file for Proxmox too (depending on your operational model). At minimum, stop embedding passwords in ad-hoc commands.

Task 11: Check clock skew (Kerberos environments will punish you)

cr0x@server:~$ timedatectl
               Local time: Thu 2025-12-26 09:25:41 UTC
           Universal time: Thu 2025-12-26 09:25:41 UTC
                 RTC time: Thu 2025-12-26 09:25:41
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Meaning: Time is synced. If you’re using sec=krb5 and the clock is off, auth can fail in ways that look like “permission denied.”

Decision: If not synced, fix NTP before you debug anything else in Kerberos land.

Task 12: Inspect server-side policy expectations (signing/encryption)

cr0x@server:~$ sudo modinfo cifs | head
filename:       /lib/modules/6.2.16-3-pve/kernel/fs/smb/client/cifs.ko
license:        GPL
description:    VFS to access servers complying with the SNIA CIFS Specification e.g. Samba and Windows
author:         Steve French

Meaning: You’re using the in-kernel SMB client. Kernel version changes can change defaults around signing and dialect selection.

Decision: If a mount “used to work” and now fails after updates, treat it as a default-change problem. Pin explicit options.

Task 13: Verify you can write and create directories (Proxmox needs this)

cr0x@server:~$ sudo touch /mnt/test-backups/.pve-write-test
cr0x@server:~$ echo $?
0
cr0x@server:~$ sudo mkdir -p /mnt/test-backups/.pve-mkdir-test
cr0x@server:~$ ls -ld /mnt/test-backups/.pve-mkdir-test
drwxr-x--- 2 root root 0 Dec 26 09:27 /mnt/test-backups/.pve-mkdir-test

Meaning: The mounted credentials can write and create directories. If Proxmox backups fail later, you’re less likely to chase ACL ghosts.

Decision: If you get “Permission denied” here, your issue is authorization (share ACLs / filesystem ACLs), not mount mechanics.

Task 14: Observe the effective mount options in reality

cr0x@server:~$ sudo findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /mnt/test-backups
//nas01/backups /mnt/test-backups cifs rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=backupuser,domain=LAB,uid=0,gid=0,file_mode=0640,dir_mode=0750,nounix,serverino,mapposix,acl

Meaning: This is the ground truth of what the kernel accepted. If you set an option and it doesn’t appear here, it didn’t take.

Decision: Use findmnt output to drive the Proxmox config and to document operational expectations.

Task 15: If the share is on Samba, confirm server sees your user (server-side validation)

cr0x@server:~$ ssh admin@nas01 'sudo smbstatus -b | head'
Samba version 4.17.12
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
----------------------------------------------------------------------------------------------------------------------------------
24188   backupuser   domain users  192.168.50.11 (ipv4:192.168.50.11:54132)  SMB3_11           -                    partial

Meaning: The server sees your session. If the server never sees it, the failure is before authentication completes (dialect/security, firewall, etc.).

Decision: If the server sees the login but denies access to the share path, fix share definitions and filesystem ACLs.

Mount options that matter (and the ones that lie to you)

CIFS mount options are where good intentions go to get audited. The trick is to pick a small set of explicit options and treat them like an API contract.

The “make it explicit” baseline

For most Proxmox-to-NAS setups that use local users or AD with NTLMSSP, start here:

vers=3.0 (or 3.1.1 if you know both ends support it consistently)
sec=ntlmssp (or sec=krb5 for Kerberos environments)
iocharset=utf8
nounix (often reduces permission/ownership weirdness unless you truly use Unix extensions)
uid=0,gid=0 (or a service account on the Proxmox host if you want non-root ownership presentation)
file_mode=0640,dir_mode=0750 (presentation layer; still helpful)

Why nounix so often? Because SMB “Unix extensions” and POSIX mapping can be a compatibility minefield across NAS vendors and Samba versions. If your NAS advertises half-baked POSIX semantics, Linux will believe it and then you’ll get permission behavior that makes you question your career choices.

Dialect selection: `vers=` is not optional in production

Yes, the client can negotiate automatically. No, you should not rely on it for Proxmox storage.

Symptom: “Permission denied” after an update or after changing a NAS security policy.
Root cause: default dialect preference changed, SMB1 is disabled, or SMB3 signing policy changed.
Fix: pin vers=3.0 (or 3.1.1) and move on with your day.

Security mode: `sec=` is where enterprise policy hides

Common options you’ll see:

sec=ntlmssp: widely compatible, still common, often allowed but sometimes restricted.
sec=krb5: Kerberos, best choice in AD environments if you can manage keytabs and time sync.

If your org disables NTLM, mounts that worked for years will start failing with “Permission denied.” The password didn’t change. The policy did.

Signing and encryption: policy mismatch can look like auth failure

Depending on kernel and server, you might need options like:

seal (SMB encryption)
sign (signing enabled) or server enforcement

These aren’t always necessary. They’re frequently required by policy when the share carries sensitive backups.

UID/GID mapping: mounts can succeed and still be “permission denied” later

This is the classic trap: the mount is successful, but when Proxmox tries to write, you see permission errors in backup jobs.

SMB doesn’t naturally “be Linux.” Ownership and modes are mapped. If the server exposes ACLs that don’t translate cleanly, the client shows permissions that don’t reflect reality. Or vice versa.

Opinionated guidance:

If you’re using a NAS as a dumb backup target, prefer nounix and manage permissions at the share/ACL level.
If you truly need POSIX semantics (shared home directories, multi-user workflows), use Samba with Unix extensions configured correctly and test thoroughly. Don’t assume your NAS vendor got it right.

One short joke (1 of 2)

SMB “Permission denied” is like a corporate calendar invite: it doesn’t tell you what’s wrong, just that your afternoon is gone.

Credentials vs authorization: share ACLs, NTFS ACLs, and NAS quirks

“Correct credentials” is not the same as “you are allowed to do the thing.” SMB makes a clean separation:

Authentication: prove who you are (password/Kerberos/NTLM).
Authorization: determine what you can access (share permissions + filesystem permissions/ACLs).

Share permissions vs filesystem permissions

Many NAS systems implement two layers:

Share-level access: who can connect to //server/share.
Filesystem-level ACL: what you can do inside (create, delete, rename).

You can pass layer one and fail layer two. The client may still report “permission denied,” and you’ll swear the password is wrong because that’s the only lever you’ve been pulling.

Domain formatting: `DOMAIN\user` vs `user@domain`

SMB stacks differ. Some like LAB\backupuser. Some prefer backupuser@lab.local. Linux mount.cifs typically wants username= and domain= (or embed the domain in the username).

Practical rule: use the same format that succeeded with smbclient, then translate it into mount options.

Guest access and “map to guest” behavior

Some Samba/NAS configs allow guest access, some explicitly forbid it. If your client accidentally attempts guest or anonymous auth (empty username, wrong domain mapping), you can get:

successful connection but read-only access, or
immediate permission denied.

Pin credentials explicitly. Avoid “it’ll just use my logged-in user” thinking on a Proxmox node.

Kerberos in Proxmox environments

If you’re mounting from a domain-joined Linux host with a keytab, Kerberos is a strong choice. But it’s operationally strict:

Time sync must be correct.
DNS must be correct.
SPNs must exist and match the server name you’re using.

Kerberos failures can degrade into access denied messages. If you use sec=krb5, commit to the prerequisites.

Three corporate mini-stories (because you will live these)

Mini-story 1: The incident caused by a wrong assumption

The team had a Proxmox cluster backing up to a central NAS over SMB. The storage was added in the GUI, it mounted, and backups ran for months. Everyone got comfortable.

Then the security group rolled out an AD policy to disable NTLM in phases. They sent an email. It landed where policy emails go: the same place as “mandatory compliance training” and “fun virtual team building.”

One Tuesday morning, backups started failing with mount error(13): Permission denied. The on-call engineer did the expected dance: reset the password, retyped the password, tried a different account. Same failure. Proxmox was blamed. The NAS was blamed. The network was blamed. Time was blamed, briefly, because time is always a suspect in distributed systems.

It turned out the credentials were correct. Authentication was being rejected because NTLM was no longer allowed for that account class. The mount needed Kerberos: sec=krb5, a keytab, and stable DNS.

The wrong assumption wasn’t “the password is wrong.” The wrong assumption was “auth policies don’t change underneath working systems.” They do. Quietly. On a schedule.

Mini-story 2: The optimization that backfired

A storage engineer wanted faster backups. Reasonable. They tuned mount options for throughput, including aggressive caching behavior and larger read/write sizes. Backups got faster in small tests.

Then came restore day. A VM restore failed intermittently with corruption symptoms: missing chunks, checksum mismatches at the application layer, and occasional “stale file handle”-like behavior. The SMB share wasn’t losing data; the client-side behavior was returning inconsistent reads during a concurrent write workload.

The “optimization” was a cocktail of options that made sense in isolation but not together for a backup workload that expects strong consistency. The team had effectively turned their backup target into a slightly enthusiastic cache with opinions.

They rolled back to stricter caching semantics and simpler options. Performance dipped. Reliability returned. The lesson was painful and predictable: for backups, consistency beats cleverness. Always.

Mini-story 3: The boring but correct practice that saved the day

In another shop, the SRE team had a policy: every remote filesystem mount must be reproducible with a single documented CLI command, and every mount must pin an explicit SMB dialect and security mode. No exceptions. It was a little annoying. People complained. The policy stayed.

During a Proxmox upgrade cycle, a subset of nodes started failing CIFS mounts. The GUI error was, as expected, “Permission denied.” The difference was that the team already had “known good” mount commands and findmnt outputs captured from before the upgrade.

They compared the options being used pre/post change and found that one node had drifted: it relied on defaults and negotiated a different dialect due to a NAS-side policy tweak. They fixed the storage config by pinning vers=3.0 and the security mode explicitly, then re-ran the documented CLI mount test. Done.

Boring practice. Fast recovery. Everyone went back to pretending they enjoy change windows.

Common mistakes: symptom → root cause → fix

This section is blunt because production is blunt.

1) Symptom: “Permission denied” but `smbclient -L` works

Root cause: mount uses different dialect/security than smbclient, or Proxmox passes fewer options than your test.
Fix: force vers=3.0 and sec=ntlmssp (or krb5) in Proxmox storage options. Verify with strace and findmnt.

2) Symptom: manual mount works as root, but Proxmox backups fail with permission errors

Root cause: authorization inside the share: filesystem ACL denies create/write/rename in the path Proxmox uses, or NAS enforces “admin only” operations.
Fix: test write/create/delete on the mounted path; fix share ACL and underlying filesystem ACL. Don’t paper over with file_mode alone.

3) Symptom: it worked yesterday; today “Permission denied” after updates

Root cause: default option or dialect negotiation changed; server disabled SMB2/SMB1 fallback; NTLM policy tightened.
Fix: pin vers and sec. If NTLM was disabled, move to Kerberos or re-enable NTLM (if your security team allows it, which is a different kind of incident).

4) Symptom: “Permission denied” only when using a hostname, but IP works

Root cause: SPN / DNS / name-based policy (Kerberos expects the hostname), or you’re resolving to the wrong host.
Fix: fix DNS, verify getent hosts, and for Kerberos use the canonical hostname that matches the server’s SPN.

5) Symptom: Proxmox GUI storage add fails, but CLI mount works

Root cause: Proxmox storage config missing required options, or it’s storing credentials differently than your CLI test.
Fix: add the storage via CLI or edit /etc/pve/storage.cfg carefully; verify with pvesm activate and strace to see the exact mount call.

6) Symptom: you can read but not write

Root cause: share is read-only for that user, or underlying ACL denies write/create/delete.
Fix: use smbclient to attempt a write, and test on the mount with touch/mkdir. Fix server-side permissions, not client-side cosmetics.

7) Symptom: “Permission denied” when password contains special characters

Root cause: shell escaping or Proxmox config parsing got you; your password is not what you think it is.
Fix: use a credentials file with strict permissions. Stop pasting secrets into commands.

8) Symptom: intermittent permission issues under load

Root cause: locking/oplocks/leases behavior, NAS bugs, or caching options that don’t match workload consistency needs.
Fix: revert to conservative options; ensure the NAS is supported for heavy concurrent writes; consider NFS for Linux-centric workloads if your environment allows it.

Checklists / step-by-step plan

Checklist A: Get a reliable mount on the Proxmox node (CLI first)

Resolve the server name: getent hosts nas01. If wrong, fix DNS or use IP temporarily.
Verify reachability: nc -vz nas01 445. If blocked, fix network/firewall.
Confirm credentials and share visibility: smbclient -L //nas01 -m SMB3 -U 'LAB\backupuser'.
Confirm you can access the share: smbclient //nas01/backups -m SMB3 -U 'LAB\backupuser' -c 'ls'.
Create a credentials file with 0600 perms.
Mount with pinned options (vers, sec, nounix, iocharset, UID/GID and modes).
Test write/create/delete in the mount path.
Capture findmnt output as your “known good” reference.

Checklist B: Make Proxmox use the same mount behavior

Inspect /etc/pve/storage.cfg for the CIFS storage entry.
Set explicit options to match the successful CLI mount: dialect, security mode, and any compatibility flags.
Run pvesm activate <storageid>.
If it fails, run dmesg -T | tail -n 50 immediately after.
Use strace on pvesm activate to confirm what options are passed to mount.cifs.
Verify the mount is present under /mnt/pve/<storageid> with findmnt.
Trigger a small Proxmox backup to validate actual workload behavior (write + rename patterns).

Checklist C: Kerberos track (when NTLM is not allowed)

Confirm time sync: timedatectl shows synchronized.
Confirm DNS correctness for the SMB server name.
Obtain and install a keytab for the service principal (operationally: coordinate with directory services).
Mount with sec=krb5 and use the correct server hostname (the one matching the SPN).
Validate with kernel logs if auth fails; Kerberos failures can show up as access issues.

Paraphrased idea (reliability quote): Gene Kranz’s well-known mission-control principle is essentially “be strict and competent.” That mindset applies perfectly to storage mounts.

One short joke (2 of 2)

Nothing says “enterprise storage” like a protocol called “Simple” that needs 14 options to do a basic mount.

FAQ

1) Why does Proxmox say “Permission denied” when the credentials are correct?

Because the error often reflects authorization (share ACL/NTFS ACL), policy (NTLM disabled, signing required), or dialect/security negotiation failures, not just password validity.

2) Should I always set `vers=3.0`?

In production, yes—set an explicit dialect you know the server supports. If you have a modern NAS/Windows/Samba, SMB3 is the right baseline. If the server supports SMB3.1.1 reliably, you can use that, but consistency matters more than theoretical upgrades.

3) What’s the difference between `sec=ntlmssp` and `sec=krb5`?

ntlmssp uses NTLM-based authentication and is widely compatible. krb5 uses Kerberos and is typically preferred in AD environments with stronger policy control, but it requires time sync and correct DNS/SPN setup.

4) I can list the share but can’t create files. Why?

Share-level access allows you to connect, but filesystem ACLs can still block writes. Test with touch on the mount and fix server-side ACLs. Client-side file_mode won’t override server authorization.

5) Do `file_mode` and `dir_mode` fix permissions?

They mostly affect how permissions are presented on the Linux client. They do not magically grant write rights if the server denies them.

6) Why does using a credentials file help?

It avoids shell escaping problems, prevents secrets from appearing in process listings, and keeps the mount command sane. It also makes it harder to accidentally paste the wrong password with invisible characters.

7) Proxmox mounts under `/mnt/pve`. Can I mount elsewhere?

Proxmox expects to manage storages under /mnt/pve/<storageid>. You can mount manually elsewhere for testing, but the storage definition should align with Proxmox’s conventions unless you have a strong reason to diverge.

8) Is CIFS a good choice for Proxmox backups?

It can be. But treat it like a networked dependency with policy changes and NAS firmware quirks. If you control both ends and your environment is Linux-heavy, NFS often has fewer identity/ACL translation surprises. If you’re in Windows/AD land, SMB with Kerberos is a solid enterprise path.

9) What’s the single best troubleshooting signal?

dmesg immediately after the failure. It often tells you whether the failure happened during session setup, tree connect, or later authorization checks.

Conclusion: practical next steps

When Proxmox CIFS says “Permission denied,” stop debating whether the password is correct and start collecting evidence. Prove network reachability, prove share access with smbclient, pin the SMB dialect and security mode, then make Proxmox use the exact same mount options that worked on the CLI.

Next steps that actually move the needle:

Run smbclient against the exact share and user you intend to mount with.
Do one manual mount with explicit vers and sec, then verify with findmnt.
Test write/create operations on the mount path—don’t assume.
Make Proxmox match your known-good mount options and validate with pvesm activate plus dmesg.
Document the final mount option set. Defaults change. Your future self won’t remember why this worked.