You typed the mount command you’ve typed a hundred times. It worked on Ubuntu 22.04. It worked on that one old jump host nobody dares patch. Now on Ubuntu 24.04 you get the classic, useless punchline: “Permission denied”.
This is one of those failures where the server is technically telling the truth, but the client is the one speaking the wrong dialect. The fix is usually a single mount option. The hard part is knowing which option, and proving it before you “fix” it into a worse problem.
Fast diagnosis playbook (check these first)
If you’re on-call, you don’t have time to become a part-time SMB historian. Here’s the fastest path to the likely bottleneck, in the right order.
1) Confirm the server speaks the SMB version you’re asking for
Most Ubuntu 24.04 “Permission denied” tickets are actually “protocol negotiation and auth expectations changed.” Start with SMB dialect.
- If the server is old or locked down: set
vers=3.0orvers=2.1explicitly. - If it’s ancient NAS gear: you might need
vers=1.0(and then you should plan its retirement).
2) Confirm the auth mechanism (sec=) matches the server’s policy
Windows and many NAS appliances increasingly reject NTLM variants. Some environments require Kerberos. Some “security hardening” boxes require NTLMv2 only. Make sec= explicit and stop guessing.
3) Check the kernel log for the real reason (don’t trust mount’s one-liner)
mount.cifs likes to summarize everything as “Permission denied.” The kernel’s CIFS client will tell you whether it’s a bad password, bad SPN, missing key, clock skew, or signing failure.
4) Prove your credentials are what you think they are
Wrong domain, wrong username format, special characters in passwords, or a credentials file with Windows line endings can all translate into “permission denied.” Yes, even in 2025.
5) Only then chase filesystem permissions and ACLs
POSIX permissions are often not the first problem. On SMB, you can authenticate successfully and still be denied by share permissions or NTFS ACLs. But if you can’t authenticate, permission checks are irrelevant.
One operational rule: don’t change three variables at once. Dialect, auth, and identity mapping are three separate dials. Turn them one at a time and observe.
What “Permission denied” really means for CIFS on Ubuntu 24.04
On Linux, “Permission denied” on a CIFS mount usually maps to EACCES (error 13). That error is thrown for multiple distinct situations:
- Authentication failure (bad user/pass, wrong domain, wrong auth method).
- Authorization failure (you authenticated, but the share denies access).
- Negotiation mismatch (SMB dialect or signing/encryption mismatch, sometimes exposed as access denied).
- Kerberos plumbing failure (no ticket, wrong SPN, clock skew, keytab mismatch).
- Machine policy mismatch (server rejects guest, rejects NTLM, requires signing, requires encryption).
- Client-side mapping confusion (mount succeeds but operations fail; apps report “permission denied” later).
Ubuntu 24.04 isn’t “breaking CIFS” for fun. It ships newer kernels, newer Samba client tools, and stricter defaults in ecosystems that are trying to kill off insecure SMB/NTLM configurations. That’s a good thing for security. It’s just a bad thing for your sleep.
Paraphrased idea (attributed): Werner Vogels has argued you should build systems assuming failure is normal, then engineer for recovery.
CIFS mounting is a perfect example: assume negotiation and auth will fail in new and creative ways, and build a repeatable diagnosis path.
The exact mount options that fix it (copy/paste, then adjust)
Below are the mount option sets that most often turn Ubuntu 24.04 “Permission denied” into a clean mount. Start with the one that matches your environment. Don’t freestyle.
Case A: Modern Windows / Samba server, local credentials (most common)
If you’re mounting a share with a username/password (not Kerberos), and you don’t want surprises:
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
-o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,seal,sign,uid=1000,gid=1000,dir_mode=0770,file_mode=0660,nofail,x-systemd.automount
Why this works:
vers=3.0: makes negotiation explicit; avoids “helpful” fallback behavior that varies by server.sec=ntlmssp: common for Windows when Kerberos isn’t used.sign: satisfies servers requiring signing; if the server doesn’t require it, signing is usually still fine.seal: enables SMB3 encryption where supported; if the server requires encryption, this avoids a denial.uid/gid+file_mode/dir_mode: gives consistent ownership/mode for Linux processes.x-systemd.automount: avoids boot hangs and makes mounts resilient.
Case B: Windows server requires SMB signing, but encryption is not enabled
If seal causes problems (older server, performance concerns, or server policy doesn’t support it), drop it but keep signing:
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
-o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,sign,uid=1000,gid=1000,dir_mode=0770,file_mode=0660
Case C: Old NAS or old Samba that can’t do SMB3
This is where “Permission denied” often hides a dialect refusal. Try SMB2.1 first:
cr0x@server:~$ sudo mount -t cifs //nas01/Archive /mnt/archive \
-o credentials=/etc/cifs/archive.cred,vers=2.1,sec=ntlmssp,uid=1000,gid=1000,dir_mode=0775,file_mode=0664
If the device is truly ancient, vers=1.0 might be the only answer. It’s also a good reason to file a replacement request with a very calm subject line.
Case D: Active Directory with Kerberos (the “it works on one host” special)
For AD-integrated environments, Kerberos is the correct long-term choice. It also fails in more interesting ways.
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Engineering /mnt/eng \
-o vers=3.0,sec=krb5,cruid=1000,multiuser,seal,sign,uid=1000,gid=1000,dir_mode=0770,file_mode=0660
Notes: cruid= ties the mount’s credential cache to the right local user. multiuser allows multiple users’ Kerberos creds to be used on one mount (useful on shared hosts, dangerous if you don’t understand it).
Case E: Domain user with NTLMSSP, but the domain formatting is the culprit
This is where “permission denied” is just your username not being parsed as you think. Use one of these forms:
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
-o username='EXAMPLE\jdoe',password='REDACTED',vers=3.0,sec=ntlmssp
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
-o username='jdoe',domain='EXAMPLE',password='REDACTED',vers=3.0,sec=ntlmssp
Case F: Share allows guest, but Ubuntu doesn’t guess “guest” anymore
Guest access is increasingly blocked (for good reasons). But if you genuinely have a read-only public share:
cr0x@server:~$ sudo mount -t cifs //nas01/Public /mnt/public \
-o guest,vers=3.0,sec=none,ro,uid=1000,gid=1000,dir_mode=0555,file_mode=0444
Be explicit. If the server rejects guest, this will still fail—but now you know you’re not accidentally sending a username you didn’t intend.
Joke #1: SMB is the only protocol that can be simultaneously “backwards compatible” and “no longer supports the thing you’ve used for 12 years.”
Practical tasks: commands, outputs, and the decision to make (12+)
This is the part you use during incidents. Each task has: the command, what the output means, and what decision you make next.
Task 1: Confirm the kernel and cifs-utils version (baseline matters)
cr0x@server:~$ uname -r
6.8.0-41-generic
cr0x@server:~$ dpkg -l | grep -E '^ii\s+cifs-utils'
ii cifs-utils 2:7.0-2ubuntu2 amd64 Common utilities for SMB/CIFS mounts
Meaning: You’re on the newer CIFS client stack; defaults and security capabilities differ from older hosts.
Decision: Stop comparing behavior to Ubuntu 20.04/22.04 unless you also compare sec, vers, and signing/encryption requirements.
Task 2: Verify name resolution (permission errors can mask “wrong server”)
cr0x@server:~$ getent hosts filesrv01.example.com
10.20.30.40 filesrv01.example.com
Meaning: DNS resolves to an IP. If it resolves to a different IP than expected (VIP moved, split DNS, stale /etc/hosts), you may be authenticating to the wrong machine.
Decision: If the IP is unexpected, fix DNS/hosts before touching mount options.
Task 3: Confirm the TCP port is reachable (firewalls lie quietly)
cr0x@server:~$ nc -vz filesrv01.example.com 445
Connection to filesrv01.example.com (10.20.30.40) 445 port [tcp/microsoft-ds] succeeded!
Meaning: Port 445 is reachable. If it fails, you don’t have an auth problem—you have a network problem.
Decision: If blocked, stop. Escalate to network/security; don’t “fix” CIFS options.
Task 4: List shares with smbclient (auth sanity check)
cr0x@server:~$ smbclient -L //filesrv01.example.com -U 'EXAMPLE\jdoe'
Password for [EXAMPLE\jdoe]:
Sharename Type Comment
--------- ---- -------
Finance Disk Finance Share
Engineering Disk Engineering Share
IPC$ IPC Remote IPC
SMB1 disabled -- no workgroup available
Meaning: Credentials are accepted and SMB negotiation works. That’s half the battle.
Decision: If smbclient fails with NT_STATUS_ACCESS_DENIED, focus on username/password/domain/sec. If it succeeds but mount fails, focus on mount options (signing/encryption, vers, Kerberos, idmap).
Task 5: Test access to the specific share (share ACL vs mount failure)
cr0x@server:~$ smbclient //filesrv01.example.com/Finance -U 'EXAMPLE\jdoe' -c 'ls'
Password for [EXAMPLE\jdoe]:
. D 0 Mon Dec 9 12:01:00 2025
.. D 0 Mon Dec 9 12:01:00 2025
budgets D 0 Mon Dec 9 12:01:00 2025
104857600 blocks of size 1024. 51372800 blocks available
Meaning: You can authenticate and you can access the share content. If mount still says “permission denied,” the issue is almost certainly negotiation/security options, not NTFS/share ACLs.
Decision: Try explicit vers= and sec=, then signing/encryption.
Task 6: Run the mount with verbose output (user-space hints)
cr0x@server:~$ sudo mount -vvv -t cifs //filesrv01.example.com/Finance /mnt/finance \
-o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,sign
mount.cifs kernel mount options: ip=10.20.30.40,unc=\\filesrv01.example.com\Finance,vers=3.0,sec=ntlmssp,sign
mount error(13): Permission denied
Meaning: Still ambiguous. This is why we check kernel logs next.
Decision: Go to dmesg and look for CIFS messages with the real cause.
Task 7: Read kernel messages for CIFS (the truth lives here)
cr0x@server:~$ sudo dmesg -T | tail -n 30
[Mon Dec 29 10:15:22 2025] CIFS: VFS: \\filesrv01.example.com Send error in SessSetup = -13
[Mon Dec 29 10:15:22 2025] CIFS: VFS: cifs_mount failed w/return code = -13
Meaning: Session setup failed (auth/negotiation). Sometimes you’ll see more specific lines like “Server requires packet signing” or “Krb5 authentication failed.”
Decision: If logs mention signing/encryption, add sign and/or seal. If they mention Kerberos, move to Kerberos diagnostics.
Task 8: Confirm what security modes the client thinks it can use
cr0x@server:~$ modinfo cifs | grep -E 'parm:|version' | head
version: 2.45
parm: CIFSMaxBufSize:Network buffer size (int)
parm: SecurityFlags:SecurityFlags, comma separated (int)
Meaning: Kernel CIFS module is present and modern. You won’t “fix” this by reinstalling cifs-utils.
Decision: Focus on configuration and server policy mismatch, not package churn.
Task 9: Inspect the credentials file for format problems (permissions and CRLF)
cr0x@server:~$ sudo ls -l /etc/cifs/finance.cred
-rw------- 1 root root 58 Dec 29 10:01 /etc/cifs/finance.cred
cr0x@server:~$ sudo sed -n '1,5p' /etc/cifs/finance.cred
username=jdoe
password=REDACTED
domain=EXAMPLE
Meaning: The file is root-readable only (good). If it’s world-readable, you’ve invented a credential leak.
Decision: If the file came from Windows tooling, check for CRLF. CRLF can make the password wrong in a way you won’t spot by looking.
cr0x@server:~$ sudo cat -A /etc/cifs/finance.cred
username=jdoe$
password=REDACTED$
domain=EXAMPLE$
Meaning: $ at line ends indicates LF. If you see ^M$, convert it (dos2unix) and retry.
Decision: Fix line endings before you blame the server.
Task 10: Try a different SMB dialect (fast, reversible)
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
-o credentials=/etc/cifs/finance.cred,vers=3.1.1,sec=ntlmssp,sign
mount error(13): Permission denied
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
-o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,sign
Meaning: If 3.1.1 fails but 3.0 succeeds, the server might be picky about negotiation or security features tied to newer dialects.
Decision: Pin the working vers explicitly in /etc/fstab and document why.
Task 11: Try explicit security mode (sec=) rather than relying on defaults
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
-o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmv2,sign
mount error(13): Permission denied
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
-o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,sign
Meaning: Some servers accept ntlmssp but reject ntlmv2 (or vice versa). In AD contexts, you may be expected to use Kerberos instead.
Decision: If ntlmssp doesn’t work and policy says “Kerberos only,” stop forcing NTLM and move to Kerberos configuration.
Task 12: Verify the mount is actually using the options you think it is
cr0x@server:~$ mount | grep /mnt/finance
//filesrv01.example.com/Finance on /mnt/finance type cifs (rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=jdoe,uid=1000,gid=1000,dir_mode=0770,file_mode=0660,soft,nounix,serverino,mapposix,nofail)
Meaning: The running mount shows the negotiated settings. This catches the classic problem where you edited /etc/fstab but didn’t remount, or you’re looking at the wrong mountpoint.
Decision: If the displayed vers or sec isn’t what you intended, you’re not testing the right thing.
Task 13: Confirm file operations actually work (mount success can still hide permission issues)
cr0x@server:~$ touch /mnt/finance/.cifs-write-test
touch: cannot touch '/mnt/finance/.cifs-write-test': Permission denied
Meaning: You mounted the share, but you’re not allowed to write. That’s an authorization/ACL problem, not mount negotiation.
Decision: Validate share permissions and NTFS ACLs for the user. Don’t keep changing sec and vers; you already got in.
Task 14: Inspect ACL-ish behavior from Linux (spot mapping confusion)
cr0x@server:~$ ls -ld /mnt/finance
drwxrwx--- 2 cr0x cr0x 0 Dec 29 10:20 /mnt/finance
cr0x@server:~$ ls -l /mnt/finance | head
total 0
drwxrwx--- 2 cr0x cr0x 0 Dec 9 12:01 budgets
Meaning: The local ownership/modes are client-side presentation, not necessarily the server’s NTFS reality (unless you’re using SMB POSIX extensions end-to-end).
Decision: If Linux apps rely on POSIX semantics, decide whether you need Samba on the server side with proper POSIX mapping, or whether SMB is just a transport for “dumb” file access.
Active Directory / Kerberos cases (where “permission denied” lies)
If your organization has AD, odds are someone has pushed “NTLM: disabled” or “SMB signing required” via policy. That’s not a bug. It’s an operational constraint. The CIFS client must match the server’s required auth and integrity settings.
Kerberos prerequisites you can’t wish away
- Time sync must be sane. Kerberos is allergic to clock drift.
- DNS must be correct. Kerberos uses service principal names (SPNs) that depend on names.
- Ticket cache must exist for the user doing the mount (or you must use a keytab and the right mount mode).
Task 15: Check time sync (Kerberos cares, a lot)
cr0x@server:~$ timedatectl
Local time: Mon 2025-12-29 10:22:11 UTC
Universal time: Mon 2025-12-29 10:22:11 UTC
RTC time: Mon 2025-12-29 10:22:11
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Meaning: Time is synchronized. If it’s not, Kerberos can fail as “permission denied” because you never successfully authenticate.
Decision: If unsynchronized, fix NTP/chrony before any CIFS tweaks.
Task 16: Verify you have Kerberos tickets (user-space sanity check)
cr0x@server:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: jdoe@EXAMPLE.COM
Valid starting Expires Service principal
12/29/25 10:00:01 12/29/25 20:00:01 krbtgt/EXAMPLE.COM@EXAMPLE.COM
Meaning: You have a TGT. If you don’t, a sec=krb5 mount will fail.
Decision: Acquire a ticket with kinit, or use a system keytab approach if this must be non-interactive.
Task 17: Try Kerberos mount with explicit cruid (avoid wrong cache)
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Engineering /mnt/eng \
-o vers=3.0,sec=krb5,cruid=1000,sign,seal
Meaning: If this works but the same command without cruid fails, you were using the wrong credential cache (common when using sudo).
Decision: Standardize Kerberos mounts with cruid and systemd automount units, not ad-hoc sudo sessions.
Joke #2: Kerberos is like a nightclub bouncer: impeccable security, and absolutely no patience for your clock being five minutes off.
UID/GID mapping and why your files “work” but your apps don’t
This is the quieter failure mode. The mount succeeds. Directory listings work. Then your application fails to create lock files, or your CI job can’t chmod, or your container can’t write.
There are two broad worlds:
- “Presentation mapping” where you force ownership with
uid=,gid=, and modes. This is common and often sufficient. - True identity mapping where SIDs map to POSIX IDs. This is more complex and usually an enterprise choice, not a Linux-client-only tweak.
What to do on Ubuntu clients (pragmatic default)
Unless you have a full AD-to-POSIX identity design, do not pretend you do. Use simple mapping:
uid=,gid=to make ownership predictable for the consuming service account.file_mode=,dir_mode=to match what the Linux process expects.- Consider
nopermif the server enforces ACLs and you don’t want the Linux client to second-guess access (this can be useful, and it can be dangerous).
Task 18: Detect the “noperm needed” scenario
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
-o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,uid=1000,gid=1000,dir_mode=0770,file_mode=0660
cr0x@server:~$ sudo -u '#1000' ls /mnt/finance
ls: cannot open directory '/mnt/finance': Permission denied
Meaning: The client-side permission check is denying access for the local UID, even though the server might allow it based on SMB credentials.
Decision: Try noperm only if you understand that the server is the source of truth, and you’re not relying on local mode bits for enforcement.
cr0x@server:~$ sudo umount /mnt/finance
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
-o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,noperm,uid=1000,gid=1000,dir_mode=0770,file_mode=0660
Signing, encryption, and the corporate security tax
SMB signing and SMB encryption are the two policy levers that most often turn into “Permission denied” when clients don’t comply.
SMB signing
Signing protects integrity: it prevents tampering. Many Windows environments require it, especially for domain-related shares or hardened servers.
On Linux CIFS mounts, you can force it with sign. If the server requires signing and the client doesn’t do it, the server can refuse session setup or subsequent operations.
SMB encryption (seal)
Encryption protects confidentiality. SMB3 encryption is negotiated and can be required per-share on Windows. On Linux, seal enables encryption.
Encryption can reduce throughput and increase CPU. Sometimes that’s acceptable. Sometimes it’s a surprise performance incident waiting to happen. The point is: make it explicit and capacity-plan it.
Task 19: Spot signing/encryption-related failures in kernel logs
cr0x@server:~$ sudo dmesg -T | grep -i cifs | tail -n 10
[Mon Dec 29 10:30:10 2025] CIFS: VFS: Server requires packet signing to be enabled
[Mon Dec 29 10:30:10 2025] CIFS: VFS: cifs_mount failed w/return code = -13
Meaning: You’re being denied because you didn’t sign.
Decision: Add sign and retry. If you already have sign and still see this, you may be negotiating an older dialect—pin vers=3.0 or higher.
Three corporate mini-stories from the trenches
1) Incident caused by a wrong assumption: “Permission denied means the password is wrong”
They had a payroll integration running on a small Ubuntu fleet. The shares lived on Windows. A routine OS refresh moved two application nodes to Ubuntu 24.04. The mount failed at boot. The team assumed a credential rotation went wrong because, well, that’s what always happens when something says “permission denied.”
The immediate response was predictable: re-issue passwords, re-check the secrets manager, re-roll service accounts. Hours passed. Nothing changed. The old nodes still mounted fine. The new nodes didn’t. That should have been the clue, but incidents don’t reward subtlety.
Eventually someone checked dmesg and found the server required signing. The older nodes had been implicitly negotiating a different dialect and signing behavior; the new nodes were not matching the policy. Adding vers=3.0,sign fixed it instantly.
The postmortem takeaway wasn’t “read dmesg.” That’s too easy. The takeaway was that SMB policies are a three-party contract: server config, domain policy, and client defaults. When you upgrade one party, you renegotiate the contract whether you meant to or not.
2) Optimization that backfired: “Let’s disable encryption for performance”
A different company ran build artifacts over SMB because “it’s basically a network drive.” They enabled SMB3 encryption at some point after a security audit. Performance dipped. Developers complained. Leadership heard “slow builds” and demanded action.
The infra team removed seal from mount options to speed things up. It worked in one environment. In another environment, the exact same fstab change caused mounts to fail with “permission denied.” Not everywhere—only for certain shares.
The reason was subtle but perfectly logical: encryption was required per-share on some servers. The ones hosting sensitive artifacts enforced it. The others didn’t. Removing seal was effectively an access violation, not a performance tweak.
They ended up doing the boring engineering: keep seal, measure CPU overhead, and move the busiest builders to instances with more CPU headroom. The optimization backfired because they optimized the wrong layer—policy, not throughput.
3) Boring but correct practice that saved the day: “systemd automount + nofail + pinned options”
A healthcare org (yes, that kind of uptime pressure) had a rule: network mounts must never block boot. Every CIFS mount used systemd automount, nofail, and explicit vers/sec pinned to what the server team supported.
One morning, a domain controller maintenance window created transient Kerberos issues. Several hosts lost the ability to mount AD-protected shares at boot time. But the hosts still came up, services started, and the monitoring stack stayed alive. The mounts retried when accessed and recovered once Kerberos stabilized.
There was still impact—some app jobs couldn’t read their input for a while. But the infrastructure didn’t fall into a boot loop or get stuck in emergency mode. That difference matters. A lot.
The best part: the incident notes were short because the behavior was already expected. “Mounts are on-demand; check tickets; check DC reachability; wait; verify remount.” Boring. Correct. Life-saving.
Common mistakes: symptom → root cause → fix
This section is deliberately specific. CIFS fails in repeating patterns. Recognize the pattern, apply the fix, move on.
1) Symptom: mount error(13) immediately, smbclient works
Root cause: signing/encryption mismatch, or mount is using different defaults than smbclient.
Fix: pin options: vers=3.0,sec=ntlmssp,sign; add seal if server requires encryption. Verify with mount | grep and dmesg.
2) Symptom: mount works with IP, fails with hostname
Root cause: DNS/SPN mismatch (especially with Kerberos), or you’re hitting a different server behind a name.
Fix: use correct DNS, confirm getent hosts. For Kerberos, ensure the SPN matches the hostname you mount.
3) Symptom: works on one Ubuntu host, fails on another with same command
Root cause: different kernel/client defaults, different credential cache (Kerberos), different DNS, or different crypto policy.
Fix: compare uname -r, dpkg -l cifs-utils, and the output of mount -vvv plus dmesg. Make vers and sec explicit.
4) Symptom: mount succeeds, but writes fail with “Permission denied”
Root cause: share ACL / NTFS ACL denies write; or share is read-only; or you mounted with ro.
Fix: confirm with smbclient write test; check server-side permissions. Don’t touch vers/sec; auth is already fine.
5) Symptom: “Permission denied” only when running under systemd at boot
Root cause: network not ready, DNS not ready, Kerberos ticket not available, or mount executed before dependencies.
Fix: use x-systemd.automount, nofail, and consider _netdev. For Kerberos, ensure ticketing happens before access or use a keytab strategy.
6) Symptom: “Permission denied” after password rotation, but credentials file looks correct
Root cause: CRLF line endings, quoting issues, or hidden characters in the password.
Fix: inspect with cat -A; convert to LF; retype carefully; avoid copying through rich-text tools.
7) Symptom: “mount error(13)” only for some shares on the same server
Root cause: per-share policy (encryption required, different ACL model) or share permissions differ.
Fix: test each share with smbclient //server/share. Add seal for sensitive shares if required.
Checklists / step-by-step plan (boring on purpose)
Use this when you want your future self to send you a thank-you note.
Checklist 1: One-time host setup (Ubuntu 24.04 CIFS client)
- Install tools:
cifs-utils,smbclient, and Kerberos tools if needed. - Create a credentials file under
/etc/cifs/with0600perms owned by root. - Create the mount point with correct ownership and permissions for the consuming service.
- Decide auth model: NTLMSSP vs Kerberos. Don’t “try both” in production configs.
- Pin
versandsec. Addsign. Addsealif required or desired.
Checklist 2: Production fstab entry that won’t ruin your boot
A sane baseline fstab line for password-based auth:
cr0x@server:~$ sudo bash -lc "cat >> /etc/fstab <<'EOF'
//filesrv01.example.com/Finance /mnt/finance cifs credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,sign,seal,uid=1000,gid=1000,dir_mode=0770,file_mode=0660,nofail,_netdev,x-systemd.automount,x-systemd.idle-timeout=600 0 0
EOF"
Then validate without rebooting:
cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo mount -a
Decision: If mount -a fails, read dmesg. Don’t reboot hoping it will “clear it.” That’s not a strategy; that’s superstition with extra steps.
Checklist 3: Incident response sequence (15 minutes, disciplined)
- Check connectivity to port 445 (
nc -vz host 445). - Check DNS mapping (
getent hosts). - Validate credentials with
smbclient -Land share access withsmbclient //host/share. - Mount with explicit
versandsec(start atvers=3.0,sec=ntlmssporsec=krb5). - Add
sign; addsealif logs suggest encryption required. - Read
dmesgfor CIFS messages after each attempt. - Once mounted, run a write test (
touch) to distinguish auth vs ACL.
Interesting facts & context (because SMB has baggage)
- SMB started at IBM in the 1980s before Microsoft made it famous. The protocol’s age shows up as “compatibility” quirks today.
- “CIFS” is essentially SMB1-era branding. Linux still uses “cifs” terminology for historical reasons, even when you’re mounting SMB3.
- SMB1 being disabled is now the norm. Many servers refuse it outright; clients that assume fallback to SMB1 hit confusing access errors.
- NTLM has been on the “please stop” list for years. Many enterprises are actively removing NTLM authentication in favor of Kerberos.
- SMB signing used to be optional and now is often required. This flips old defaults on their head in hardened environments.
- SMB3 introduced encryption, which is negotiated and can be required per share. That’s why “some shares work” is a real symptom.
- Linux CIFS client behavior is split between user-space and kernel.
mount.cifspasses options; the kernel does most of the real work and logs the real errors. - Kerberos failures often look like permission failures because the server can’t distinguish “bad ticket plumbing” from “no access” in a client-friendly way.
- UID/GID on CIFS is mostly a client-side illusion unless you deploy full identity mapping and/or POSIX extensions consistently.
FAQ
1) Why does Ubuntu 24.04 show “Permission denied” but Ubuntu 22.04 worked?
Because you changed the client behavior by upgrading: newer kernel CIFS code, different default negotiation, and stricter security expectations. Pin vers and sec to stop relying on defaults.
2) What’s the single best “first fix” mount option?
vers=3.0. It removes a huge class of negotiation ambiguity. Pair it with sec=ntlmssp for password auth or sec=krb5 for AD Kerberos.
3) Should I use sec=ntlm or vers=1.0 to make it work?
Only if you’re dealing with truly legacy infrastructure and you’ve accepted the security risk. If you need it temporarily, isolate it, document it, and plan an exit. Treat it like running telnet in production: possible, but not a lifestyle.
4) What’s the difference between sign and seal?
sign enforces integrity (messages can’t be tampered with unnoticed). seal enables SMB encryption (confidentiality). Servers may require one or both.
5) smbclient works, mount fails. How is that possible?
smbclient and the kernel CIFS mount can negotiate slightly differently and use different defaults. Also, mount can be rejected due to signing/encryption requirements that your smbclient test didn’t trigger the same way. Use kernel logs (dmesg) to see why mount is rejected.
6) Where should I put credentials, and how should it be secured?
Use a credentials file like /etc/cifs/share.cred owned by root with permissions 0600. Don’t embed passwords in /etc/fstab. Don’t leave it readable by service users “for convenience.”
7) My mount works interactively but fails at boot. What’s the fix?
Use nofail,_netdev,x-systemd.automount so the system boots regardless of network timing, and the mount happens on first access. For Kerberos, ensure tickets are available in the context doing the access, or use a keytab-based design.
8) Should I use noperm?
Sometimes. It can solve local permission-check mismatches when the server is the real enforcer. But it also removes a layer of local protection. Use it intentionally, not as a superstition.
9) Why do I see weird ownership like everything owned by root or nobody?
Because SMB doesn’t inherently map Windows identities to Linux UIDs/GIDs without additional mechanisms. Set uid=, gid=, and modes for predictable Linux behavior, or implement proper identity mapping if your environment demands it.
10) Is CIFS mounting inside containers a good idea?
Not by default. Mount CIFS on the host and bind-mount into containers, unless you fully understand kernel capabilities, credential handling, and how your orchestrator treats mounts.
Conclusion: next steps that stick
If Ubuntu 24.04 says “Permission denied” on a CIFS mount, assume it’s a mismatch between what you’re asking for and what the server policy requires. Then prove it with the right evidence.
Do this next:
- Run
smbclienttests to separate credential/ACL issues from mount negotiation issues. - Pin
vers=3.0and the correctsec=value. Addsign. Addsealif required. - Read
dmesgafter every failed attempt; treat mount’s error text as a summary, not a diagnosis. - Put the working configuration into
/etc/fstabusingnofailandx-systemd.automountso the next reboot doesn’t become your next incident.