8

I have a line in my /etc/fstab for ages that stopped working since 13.04:

//192.168.100.2/share   /mnt/popcorn      cifs username=MyUserName,password=MyPassword,user,gid=sambashare,file_mode=0664 0   0

and it gives me:

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

dmesg is as helpful as sunshine in the desert:

[  622.471321] CIFS VFS: Send error in SessSetup = -13
[  622.471458] CIFS VFS: cifs_mount failed w/return code = -13

I know the user/pass combo is correct, as this works fine:

bart@dosar:~$ smbclient //192.168.100.2/share --user=MyUserName
Enter nmt's password: 
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.32]
smb: \> ls
...

How can I permanently mount a CIFS/Samba share on Ubuntu 13.04 ?

4 Answers 4

12

according to (https://wiki.ubuntu.com/MountWindowsSharesPermanently) should be:

//servername/sharename  /media/windowsshare  cifs  username=msusername,password=mspassword,iocharset=utf8,sec=ntlm  0  0

Try to look what you are doing wrong. Make it simple, remove the file_mode, user and gid, maybe the iocharset and sec variables as well. If this will work, add always one...

6
  • No such luck. Removed everything, still same error. Jun 27, 2013 at 19:47
  • 5
    Adding sec=ntlm fixed it. Thanks. Jun 27, 2013 at 19:49
  • 2
    Add "users," before "username" and your non-root users should be able to mount this. Jan 22, 2015 at 19:56
  • 2
    The ntlm option doesn't work anymore. I still get the same error, and when I look in the kern.log I see this: ``` Aug 11 21:23:44 Z390-AORUS-PRO-WIFI kernel: [ 890.694034] CIFS: VFS: bad security option: ntlm Aug 11 21:23:44 Z390-AORUS-PRO-WIFI kernel: [ 890.695254] bad security option: ntlm ```
    – Raleigh L.
    Aug 12, 2022 at 4:25
  • 1
    @Raleigh L. : True, ntlm was removed from kernel because it is a risky auth. (git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/…) This is an old ticket and od advice. You can try to replace ntlm by Kerberos (sec=krb5) or a completely different auth /mount as afpfs, depending on what the target supports.
    – Dee
    Nov 26, 2023 at 17:19
5

The

sec=ntlm

doesn't solve the problem on my desktop (Ubuntu 13.10). It seems the parameter format changed a bit about the domain. Used to work this before but does not now:

-o username=msdomain/msusername,password=mspassword

I've changed to this format:

-o dom=msdomain,username=msusername,password=mspassword

and it works well now.

2

sec=ntlm worked for me too...

I had load of problems with this from the CLI and fstab but it worked fine from the GUI (on Fedora 20) to a home NAS and to rule out things like complex passwords I created a user with a simple username and password and then used the CLI command mount.cifs to test with. I kept getting permission denied (13) all the time so did a Wireshark of the GUI and CLI attempts.

If you do this then you want the Protocol Response message back from the server and expand all of the fields to check for the version/dialect (in my case the server wanted version 1.0) and more importantly the security requirements, a 1 means that the server requires something and my server required password encryption so setting sec=ntlm fixed it for me :-D.

Many thanks to Dee above!

1
  • Welcome to Ask Ubuntu! Please don't add 'thanks' as answers. Invest some time in the site and you will gain sufficient privileges to upvote answers you like, which is the Ask Ubuntu way of saying thank you.
    – guntbert
    Nov 21, 2014 at 19:55
1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .