mount.cifs said the credentials were formatted incorrectly. It was right.

I was changing a Linux CIFS mount from a direct NAS hostname to a DFS path. The new path worked interactively in smbclient, but the same account failed when I mounted it through /etc/fstab.

The first line from mount looked almost too obvious:

Credential formatted incorrectly

Then it carried on, tried the mount, and failed with the much less helpful:

mount error(13): Permission denied

The kernel log filled in the rest:

CIFS: Status code returned 0xc000006d STATUS_LOGON_FAILURE
CIFS: VFS: \\files.example.net Send error in SessSetup = -13
CIFS: VFS: cifs_mount failed w/return code = -13

Permissions looked guilty. They weren't.

The red herrings

This was a DFS namespace, so the hostname resolved to a healthy collection of domain controllers. The CIFS kernel messages also mentioned DFS and server inode numbers:

CIFS: VFS: The server doesn't seem to support them properly or the files
might be on different servers (DFS)

That sent the investigation toward referrals, share permissions, SMB versions, and whether the storage team had finished configuring the new path. All reasonable suspects.

There was another confusing detail. Listing shares with smbclient fell back to an anonymous login and returned nothing useful, but connecting interactively with an explicit domain user worked. The path existed. The account had access. The server was quite happy.

Only the kernel CIFS mount failed.

Read what mount.cifs actually parsed

Running the mount verbosely exposed the effective authentication options:

sudo mount -v /mnt/example

Among the output was this combination:

user=EXAMPLE\sambauser,domain=example.net

The domain was present twice: once as part of the username and again in the dedicated domain field.

The credentials file looked like this:

username=EXAMPLE\sambauser
password=secret
domain=example.net

smbclient was perfectly capable of authenticating when I supplied the identity interactively. mount.cifs parsed the credentials file, complained about its format, and handed the server an identity it rejected.

The error wasn't lying. I just assumed it was a prelude to the real error instead of the real error itself.

The fix

Put the username and domain in their own fields:

username=sambauser
password=secret
domain=example.net

Using the short NetBIOS domain worked too:

username=sambauser
password=secret
domain=EXAMPLE

Then protect the file, because it contains a plaintext password:

sudo chmod 600 /home/sysadmin/.smbcredentials

The existing fstab entry could stay as it was:

//files.example.net/Public/path /mnt/example cifs credentials=/home/sysadmin/.smbcredentials,uid=sysadmin 0 0

After removing the domain prefix from username, the mount worked.

A useful comparison

When smbclient works but mount.cifs doesn't, don't treat that as proof that the credentials file is fine. They use different SMB implementations and may not parse the same authentication input in the same way.

Check what the mount helper is actually sending:

sudo mount -v /mnt/example
sudo dmesg --ctime | tail -50

If the credentials file came from Windows or was edited in several places, check its field names and line endings without printing the password:

sudo sed \
  -e 's/^password=.*/password=REDACTED/' \
  -e 's/^username=.*/username=REDACTED/' \
  /home/sysadmin/.smbcredentials | sed -n l

The lines should end in $, not \r$, and there should be no spaces around =.

Takeaway

STATUS_LOGON_FAILURE doesn't always mean a bad password or missing share permission. If mount.cifs says Credential formatted incorrectly, believe it before debugging the entire DFS setup.

And specify the domain once. Telepathy still isn't a supported mount option.

Got a mount that works everywhere except where you need it? Send me the details and I'll take a look.

• Linux
• Infrastructure