sec = ntlmおよびsec = ntlmv2で試行されたUbuntu 13.10でCIFSマウントが失敗する



使用しているコマンドは、Redhatマシンでは機能しますが、Ubuntu 13.10(カーネル3.11.0-15-generic)では機能しません


sudo mount -t cifs //$/StructuralBiology/RAW-Data /home/rawdata2 -o user=hari.lastname,rw,soft,nosuid,uid=1000,gid=1000



mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)


[169895.357046] CIFS VFS: cifs_mount failed w/return code = -13
[170370.733123] CIFS VFS: cifs_read_super: get root inode failed



I recently ran into this very issue. Your problem is that you can't mount a subfolder of a smb/cifs share -- you can only mount the share itself (i.e. don't try to mount '//server/share/dir-1/dir-2/dir-3', instead mount '//server/share'). Try...

sudo mount -t cifs //$ /home/rawdata2 -o user=hari.lastname,rw,soft,nosuid,uid=1000,gid=1000

... and then access the desired directory via '/home/rawdata2/StructuralBiology/RAW-Data'

If you really want that 'RAW-Data' directory to be available as '/home/rawdata2', then you can mount the share to an out of the way location and use a symlink like this...

sudo mount -t cifs //$ /home/.hidden-mount -o user=hari.lastname,rw,soft,nosuid,uid=1000,gid=1000

ln -s /home/.hidden-mount/StructuralBiology/RAW-Data /home/rawdata2


So it seems that the Linux kernels in Ubuntu 13.10 may have different defaults for the mount.cifs program.

I was reading the cifs documentation and it had the text:

           SMB protocol version. Allowed values are:

           ·   1.0 - The classic CIFS/SMBv1 protocol. This is the default.

           ·   2.0 - The SMBv2.002 protocol. This was initially introduced in Windows Vista Service Pack 1, and
               Windows Server 2008. Note that the initial release version of Windows Vista spoke a slightly different
               dialect (2.000) that is not supported.

           ·   2.1 - The SMBv2.1 protocol that was introduced in Microsoft Windows 7 and Windows Server 2008R2.

           ·   3.0 - The SMBv3.0 protocol that was introduced in Microsoft Windows 8 and Windows Server 2012.

So I assumed that the archive$ was a Microsoft Windows 7 and Windows Server 2008R2 based server.

So finally I got this command ( old command with vers=2.1 added) to mount the share

alias mountr2='sudo mount -t cifs //$/StructuralBiology/RAW-Data /home/rawdata2 -o user=hari.lastname,rw,soft,nosuid,uid=1000,gid=1000,vers=2.1

The share then mounted just as before with full read and write permissions. Sadly this took me a long while ( two plus months) to figure out.

Hoping the cifs module and mount.cifs program could spit out more useful and meaningful error messages to not make this process such a blackbox.


I have had this problem on various networks which needed samba filesharing services from an Ubuntu or LinuxMint-based file server.

In every case, while the user's samba account had a password and allowed browsing (and manipulating files) of a share through a file manager, fstab mounts did not work.

This is regardless of having set sec=ntlm or sec=ntlmv2 or sec=ntlmssp or any of the various other options typically offered as a "solution" (i.e. such as setting the file_mode or user or gid)

In every case the solution for our installations has ended up being the same: reset the samba user's password and the mount works, regardless of setting options!

I'm not sure what happens when the password is "inherited/converted" from the user's Linux account, but there seems to be a significant problem there, notwithstanding the ability to browse (not mount) a samba share.

I am now going to cross post this reply to a couple similar AskUbuntu posts which promote the same "answers" which often do not seem to help those with problems.

Perhaps this approach will help you with your fstab samba mounting challenge. I hope so and good luck.

mount -t cifs -o ro,iocharset=utf8,sec=ntlm,username=everyone,password=null,vers=3.0 // /mnt/cifs 



I know it doesn't pertain to your issue exactly, but I just want to add one note for people using the KRB5 mount method and seeing:

mount error(13): Permission denied

I was running into an issue on Debian 8.10 kernel 3.16 where KRB5 + SMB1.0 was the only combination that worked.

Mounting using vers={2.0, 2.1, 3.0} yielded Permission Denied, but this was working on other (newer) Linux hosts.

Upgrading to kernel 4.10 fixed this issue. Hopefully this helps somebody out there!