Description of problem: Autofs will not mount cifs share. Authentication is AD. Version-Release number of selected component (if applicable): autofs.x86_64 1:5.0.7-9.fc18 How reproducible: Consistantly Steps to Reproduce: 1. cd into directory controled by autofs 2. 3. Actual results: /var/log/messages: an 30 07:59:50 voyager kernel: [ 1062.528961] CIFS VFS: default security mechanism requested. The default security mechanism will be upgraded from ntlm to ntlmv2 in kernel release 3.3 Jan 30 07:59:50 voyager kernel: [ 1062.571769] Status code returned 0xc000006d NT_STATUS_LOGON_FAILURE Jan 30 07:59:50 voyager kernel: [ 1062.571788] CIFS VFS: Send error in SessSetup = -13 Jan 30 07:59:50 voyager kernel: [ 1062.572044] CIFS VFS: cifs_mount failed w/return code = -13 Expected results: Share mounts correctly Additional info:
I'm struggling to see how this is an autofs problem. Can you provide information about the autofs configuration you are using?
auto.master # For details of the format look at autofs(5). # /epage /etc/auto.epage -timeout=30 /nfs /etc/auto.nfs40 -timeout=30 /cifs /etc/auto.cifs -timeout=30 # /winhome /etc/auto.winhome -timeout=30 #/ /etc/auto.misc # # NOTE: mounts done from a hosts map will be mounted with the # "nosuid" and "nodev" options unless the "suid" and "dev" # options are explicitly given. # /net -hosts # # Include central master map if it can be found using # nsswitch sources. ##company -fstype=cifs,rw,noperm,user=tpolzin,passwd=xxx ://corfs006.olympic.olysteel.corp/company #company -fstype=cifs,rw,noperm,user=olympic\\tpolzin,pass=xxx ://corfs006.olympic.olysteel.corp/company tpolzin -fstype=cifs,rw,noperm,user=olympic\\tpolzin,pass=xxx ://misfs012.olympic.olysteel.corp/vol2/home/tpolzin #images -fstype=cifs,rw,noperm,user=olympic\\tpolzin,pass=xxx ://databunker.olympic.olysteel.corp/images #support -fstype=cifs,rw,noperm,user=olympic\\tpolzin,pass=xxx ://databunker.olympic.olysteel.corp/support logs -fstype=cifs,rw,noperm,user=olympic\\tpolzin,pass=xxx ://foundatiasysmon.olympic.olysteel.corp/logs # Note that if there are entries for /net or /misc (as # above) in the included master map any keys that are the # same will not be seen as the first read key seen takes # precedence. # +auto.master auto.cifs
Is this really you map configuration, with map entries in-line in the master map? Can you re-post your configuration please? Since autofs just calls mount.cifs(8) have you investigated what may have changed with it?
What part of the following error don't you understand? Feb 7 14:26:44 voyager kernel: [23373.087130] CIFS VFS: default security mechanism requested. The default security mechanism will be upgraded from ntlm to ntlmv2 in kernel release 3.3 If I add sec=ntlmv2 to the options in /etc/auto.cifs the return in /var/log.messages is cifs_mount failed w/return code = -22 otherwise it is cifs_mount failed w/return code = -13 The default security message is coming from the kernel, something with the way it is compiled?? Is ntlmv2 not implemented correctly or completely?
(In reply to comment #5) > What part of the following error don't you understand? It's not the error that I don't understand, it's the post with your configuration. It implies you have map entries in-line in the master map with is wrong. I just wanted to clarify what the configuration really is. > > Feb 7 14:26:44 voyager kernel: [23373.087130] CIFS VFS: default security > mechanism requested. The default security mechanism will be upgraded from > ntlm to ntlmv2 in kernel release 3.3 > > If I add sec=ntlmv2 to the options in /etc/auto.cifs the return in > /var/log.messages is > > cifs_mount failed w/return code = -22 > > otherwise it is > > cifs_mount failed w/return code = -13 > > The default security message is coming from the kernel, something with the > way it is compiled?? Is ntlmv2 not implemented correctly or completely? I don't know since I'm not very familiar with the cifs code. I'll say it again, since autofs just calls mount.cifs(8), have you investigated what may have changed with it? (which implies, although it isn't clear, user space cifs mount and kernel module, since they are intimately related) Perhaps you should consider changing the component of this bug to cifs-utils or kernel. The cifs-utils maintainer is probably more likely to be familiar with this issue.
Manual mount works fine. I believe that I have stated that. My configuration has worked fine without changes in F16; F17. *************** auto.master *************** # # $Id: auto.master,v 1.4 2005/01/04 14:36:54 raven Exp $ # # Sample auto.master file # This is an automounter map and it has the following format # key [ -mount-options-separated-by-comma ] location # For details of the format look at autofs(5). # /epage /etc/auto.epage -timeout=30 /nfs /etc/auto.nfs40 -timeout=30 /cifs /etc/auto.cifs -timeout=30 # /winhome /etc/auto.winhome -timeout=30 #/ /etc/auto.misc # # NOTE: mounts done from a hosts map will be mounted with the # "nosuid" and "nodev" options unless the "suid" and "dev" # options are explicitly given. # /net -hosts # # Include central master map if it can be found using # nsswitch sources. # # Note that if there are entries for /net or /misc (as # above) in the included master map any keys that are the # same will not be seen as the first read key seen takes # precedence. # +auto.master ************************************ ################################## auto.cifs ################################### company -fstype=cifs,rw,noperm,user=olympic\\tpolzin,pass=Bulld0g ://corfs006.olympic.olysteel.corp/company tpolzin -fstype=cifs,rw,noperm,user=olympic\\tpolzin,pass=Bulld0g ://misfs012.olympic.olysteel.corp/vol2/home/tpolzin #images -fstype=cifs,rw,noperm,user=olympic\\tpolzin,pass=Bulld0g ://databunker.olympic.olysteel.corp/images #support -fstype=cifs,rw,noperm,user=olympic\\tpolzin,pass=Bulld0g ://databunker.olympic.olysteel.corp/support logs -fstype=cifs,rw,noperm,user=olympic\\tpolzin,pass=Bulld0g ://foundatiasysmon.olympic.olysteel.corp/logs I have no issue with NFS automounts (/epage;/nfs) that are in my configuration
(In reply to comment #7) > Manual mount works fine. I believe that I have stated that. My > configuration has worked fine without changes in F16; F17. No you didn't say that. > > *************** > auto.master > *************** > # > # $Id: auto.master,v 1.4 2005/01/04 14:36:54 raven Exp $ > # > # Sample auto.master file > # This is an automounter map and it has the following format > # key [ -mount-options-separated-by-comma ] location > # For details of the format look at autofs(5). > # > /epage /etc/auto.epage -timeout=30 > /nfs /etc/auto.nfs40 -timeout=30 > /cifs /etc/auto.cifs -timeout=30 > # /winhome /etc/auto.winhome -timeout=30 > #/ /etc/auto.misc > # > # NOTE: mounts done from a hosts map will be mounted with the > # "nosuid" and "nodev" options unless the "suid" and "dev" > # options are explicitly given. > # > /net -hosts > # > # Include central master map if it can be found using > # nsswitch sources. > # > # Note that if there are entries for /net or /misc (as > # above) in the included master map any keys that are the > # same will not be seen as the first read key seen takes > # precedence. > # > +auto.master > ************************************ > > ################################## > auto.cifs > ################################### > company -fstype=cifs,rw,noperm,user=olympic\\tpolzin,pass=Bulld0g > ://corfs006.olympic.olysteel.corp/company > tpolzin -fstype=cifs,rw,noperm,user=olympic\\tpolzin,pass=Bulld0g > ://misfs012.olympic.olysteel.corp/vol2/home/tpolzin > #images -fstype=cifs,rw,noperm,user=olympic\\tpolzin,pass=Bulld0g > ://databunker.olympic.olysteel.corp/images > #support -fstype=cifs,rw,noperm,user=olympic\\tpolzin,pass=Bulld0g > ://databunker.olympic.olysteel.corp/support > logs -fstype=cifs,rw,noperm,user=olympic\\tpolzin,pass=Bulld0g > ://foundatiasysmon.olympic.olysteel.corp/logs OK, that's more like what I expected, I need to be sure. Since you can manually mount these mounts, assuming you use exactly the same options as in your map, and autofs just calls mount(8) then we should check the mount command that autofs is using, maybe it's been broken in some way. We can see that in debug log output. To get full debug log output two things need to be set, first syslog needs to be logging the debug output and the LOGGING configuration parameter needs to be set for autofs. I usually send all the facility daemon output to a separate log file using: daemon.* /var/log/degug which will get what we need. I don't know if rsyslog requires the log file to already exist as syslog did but I always create the file (touch /var/log/debug) before restarting rsyslog anyway. Then change LOGGING="none" to LOGGING="debug" in /etc/sysconfig/autofs and restart autofs. With this log we should see the mount command that autofs is using.
(In reply to comment #5) > What part of the following error don't you understand? > > Feb 7 14:26:44 voyager kernel: [23373.087130] CIFS VFS: default security > mechanism requested. The default security mechanism will be upgraded from > ntlm to ntlmv2 in kernel release 3.3 > > If I add sec=ntlmv2 to the options in /etc/auto.cifs the return in > /var/log.messages is > > cifs_mount failed w/return code = -22 > That was a bug in some kernel versions, which didn't properly recognize the sec=ntlmv2 mount option. But, that kernel message about the default sec= option changing was poorly implemented. The real change was to move to sec=ntlmssp, which should work better in most cases. Some windows machines will reject "bare" NTLMv2 auth. > otherwise it is > > cifs_mount failed w/return code = -13 > > The default security message is coming from the kernel, something with the > way it is compiled?? Is ntlmv2 not implemented correctly or completely? -13 is EACCES which just means that the login didn't work. Like Ian suggests, I'd start by making sure you can mount these shares "by hand" before mixing in autofs.
I can not mount shares by the command line either.
I get a -13 with sec=ntlmssp from the command line
Ok, then that's the first thing to figure out. Can you detail specifically what command you're running to mount the share? Are you able to connect to the share using smbclient from the samba-client package?
[root@yorktowne ~]# smbclient -L misfs012.olympic.olysteel.corp -U olympic\\tpolzin Enter olympic\tpolzin's password: Domain=[OLYMPIC] OS=[Windows Server 2008 R2 Standard 7601 Service Pack 1] Server=[Windows Server 2008 R2 Standard 6.1] Sharename Type Comment --------- ---- ------- ADMIN$ Disk Remote Admin Archive Disk C$ Disk Default share Company Disk D$ Disk Default share F$ Disk Default share H$ Disk Default share Home Disk IPC$ IPC Remote IPC Load Scripts Disk MIS Disk MISMP254-1 Printer MISMP254-1 MISTESTPrint Printer MISTESTPrint print$ Disk Printer Drivers prnproc$ Disk Printer Drivers S$ Disk Default share Support Disk T$ Disk Default share UMSD Disk Vol2 Disk Connection to misfs012.olympic.olysteel.corp failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND) NetBIOS over TCP disabled -- no workgroup available [root@yorktowne ~]# smbclient \\\\misfs012.olympic.olysteel.corp/Vol2/home/tpolzin -U olympic\\tpolzin Enter olympic\tpolzin's password: Domain=[OLYMPIC] OS=[Windows Server 2008 R2 Standard 7601 Service Pack 1] Server=[Windows Server 2008 R2 Standard 6.1] tree connect failed: NT_STATUS_BAD_NETWORK_NAME
Not sure if this is the same issue, but as of last week I could not mount from command line either using CIFS: # /sbin/mount.cifs //server_a/d /mnt/server_a -o user=user Password for user@//server_a/d: <deleted> mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Linux 3.8.1-201.fc18.i686.PAE #1 SMP Thu Feb 28 19:37:29 UTC 2013 i686 i686 i386 GNU/Linux Fedora release 18 (Spherical Cow)
(In reply to comment #14) > Not sure if this is the same issue, but as of last week I could not mount > from command line either using CIFS: > > # /sbin/mount.cifs //server_a/d /mnt/server_a -o user=user > Password for user@//server_a/d: <deleted> > > mount error(22): Invalid argument > Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) It might be useful to have a look at the mount.cifs man page and type changing your options to the supported ones and check on recommended usage. The user= option, although apparently allowed, is not recommended and is not actually a valid mount.cifs option.
cifs.ko will allow user= as an option, but that can cause problems with some versions of /bin/mount which use a bare "user" option to indicate that it's a non-superuser mount. So that's the main reason we don't recommend its use. I suspect that this is the same problem as reported in bug 919084, so it may be best to just dup this one to that one for now.
Mount target machine is windows 2008 r2 server only authentication is AD how would you suggest I login?
(In reply to comment #0) > Actual results: > /var/log/messages: > an 30 07:59:50 voyager kernel: [ 1062.528961] CIFS VFS: default security > mechanism requested. The default security mechanism will be upgraded from > ntlm to ntlmv2 in kernel release 3.3 > Jan 30 07:59:50 voyager kernel: [ 1062.571769] Status code returned > 0xc000006d NT_STATUS_LOGON_FAILURE > Jan 30 07:59:50 voyager kernel: [ 1062.571788] CIFS VFS: Send error in > SessSetup = -13 > Jan 30 07:59:50 voyager kernel: [ 1062.572044] CIFS VFS: cifs_mount failed > w/return code = -13 > My mistake -- this (older) kernel is already using sec=ntlm by default. It may not like your username. You may want to try passing in the domain separately: domain=olympic,username=tpolzin It would also be good to do a mount with the '-v' option enabled so we can see what's actually being passed to the kernel. (In reply to comment #13) > [root@yorktowne ~]# smbclient -L misfs012.olympic.olysteel.corp -U > olympic\\tpolzin > Enter olympic\tpolzin's password: > Domain=[OLYMPIC] OS=[Windows Server 2008 R2 Standard 7601 Service Pack 1] > Server=[Windows Server 2008 R2 Standard 6.1] > > Sharename Type Comment > --------- ---- ------- > ADMIN$ Disk Remote Admin > Archive Disk > C$ Disk Default share > Company Disk > D$ Disk Default share > F$ Disk Default share > H$ Disk Default share > Home Disk > IPC$ IPC Remote IPC > Load Scripts Disk > MIS Disk > MISMP254-1 Printer MISMP254-1 > MISTESTPrint Printer MISTESTPrint > print$ Disk Printer Drivers > prnproc$ Disk Printer Drivers > S$ Disk Default share > Support Disk > T$ Disk Default share > UMSD Disk > Vol2 Disk > Connection to misfs012.olympic.olysteel.corp failed (Error > NT_STATUS_RESOURCE_NAME_NOT_FOUND) > NetBIOS over TCP disabled -- no workgroup available > [root@yorktowne ~]# smbclient > \\\\misfs012.olympic.olysteel.corp/Vol2/home/tpolzin -U olympic\\tpolzin > Enter olympic\tpolzin's password: > Domain=[OLYMPIC] OS=[Windows Server 2008 R2 Standard 7601 Service Pack 1] > Server=[Windows Server 2008 R2 Standard 6.1] > tree connect failed: NT_STATUS_BAD_NETWORK_NAME That won't work with smbclient. You have to connect to a share and then cd into the directory. Try passing in something like this instead as the "device" and see it if will connect: //misfs012.olympic.olysteel.corp/Vol2
Adding "sec=ntlm" allowed me to mount the filesystem: /sbin/mount.cifs -v //server01/d /mnt/server01 -o username=processor,password=<removed>,sec=ntlm mount.cifs kernel mount options: ip=192.168.1.10,unc=\\server01\d,sec=ntlm,user=processor,pass=<removed> # df -k Filesystem 1K-blocks Used Available Use% Mounted on //server01/d 871903776 108341096 763562680 13% /mnt/server01
This command fails: mount -t cifs -o creds=/root/olympic_ad //olyfs012/vol2/ /mnt mount error(13): Permission denied This command works: smbclient //misfs012/vol2/ -U XXX\\yyy Although it does not leave me where I wish to be. I also want to work directly in a mounted directory, not move files back and forth to it. I can do that with winSCP. I short if I can access a windows 2008 server r2 share via smbclient why can't I mount it? Should be simple enough when it worked in F15;16;17
(In reply to comment #21) > This command fails: > > mount -t cifs -o creds=/root/olympic_ad //olyfs012/vol2/ /mnt > mount error(13): Permission denied > > This command works: > > smbclient //misfs012/vol2/ -U XXX\\yyy > You're mounting from two different hosts? That doesn't really tell me much. Are you also able to connect to //olyfs012/vol2 with smbclient? > Although it does not leave me where I wish to be. I also want to work > directly in a mounted directory, not move files back and forth to it. I can > do that with winSCP. > > I short if I can access a windows 2008 server r2 share via smbclient why > can't I mount it? Should be simple enough when it worked in F15;16;17 Because they use a completely different codebase. smbclient lives entirely in userspace and mounting via cifs is done almost entirely via the kernel.
Typo, my bad. mount -t cifs -o creds=/root/olympic_ad //misfs012/vol2/ /mnt mount error(13): Permission denied
Following command works on machine that is joined to domain. mount.cifs //misfs012/vol2 /mnt -o user=olympic\\tpolzin.sec=krb5 no other sec value works tried ntlm ntlmv2 nrlmssp
Yes, you currently really do need to know what sort of authentication you intend to use. If you have the machine set up with the AD server as a a krb5 KDC, then sec=krb5 is probably what you want. Note that with sec=krb5, you don't even really need a "username=" parameter, since that's basically ignored as long as you have a credcache already. I'll go ahead and close this as NOTABUG since you found the right mount option to use. Please reopen if you have further questions.
So how do I mount the same share on machines that are not joined to the domain this was just a test to see what may work. Don't close this just because something worked.
The server in question will need to accept some sort of username/password auth type. If the other sec= types aren't working, then it sounds like it's not accepting those properly. This syntax is also questionable: user=olympic\\tpolzin I'd switch to using the better supported "username=tpolzin,domain=olympic" syntax. You may also need to use the kerberos realm name in the domain= field instead of the old NT4 style domianname.
(In reply to comment #4) > What part of the following error don't you understand? > > Feb 7 14:26:44 voyager kernel: [23373.087130] CIFS VFS: default security > mechanism requested. The default security mechanism will be upgraded from > ntlm to ntlmv2 in kernel release 3.3 The default security mechanism only changed with kernel 3.8 ?
https://ask.fedoraproject.org/question/23874/fedora-18-mountcifs-error-13/
Hi, just check it and positive Default security mode changed from kernel-3.7.9 to kernel-3.8.1 and kernel-3.8.3 . My smb4k stops to work with my smb share when use kernel-3.8 . workaround on smb4k is force configurations -> samba -> mounting -> security mode -> use NTLMV (or NTLMV2 also works) but not "use default security mode"
(In reply to comment #28) > > The default security mechanism only changed with kernel 3.8 ? Correct. (In reply to comment #29) > https://ask.fedoraproject.org/question/23874/fedora-18-mountcifs-error-13/ In point of fact, I am interested in fixing this, but it's quite difficult to do. SMB1 authentication is just a mess since it grew "organically" without any sort of standards. There is no way to reliably know what sort of authentication the server supports, so you just have to try something and hope you get it right. Most modern servers support NTLMSSP which is reasonably secure, so that's the current default. If that doesn't work against a particular server, then there's not a lot we can do automatically. We need for the admin to consciously allow sending an unsecure password hash on the wire.
Terry, did any of the suggestions I made in comment #27 work?
Jeff, The only way my mounts work is if I use sec=krb5, which means I have to kinit every 24 hours.
I have discovered that I was using a complete path name not a windows share name
Terry, does that mean that this is now working for you?
(In reply to comment #31) > (In reply to comment #28) > > > > The default security mechanism only changed with kernel 3.8 ? > > Correct. but not the for > (In reply to comment #29) > > https://ask.fedoraproject.org/question/23874/fedora-18-mountcifs-error-13/ > > In point of fact, I am interested in fixing this, but it's quite difficult > to do. SMB1 authentication is just a mess since it grew "organically" > without any sort of standards. There is no way to reliably know what sort of > authentication the server supports, so you just have to try something and > hope you get it right. > > Most modern servers support NTLMSSP which is reasonably secure, > so that's > the current default. ah my server 192.168.1.77 of type Samba 3.0.28a returned unexpected error on SMB posix open, disabling posix open support. Check if server update available > If that doesn't work against a particular server, then > there's not a lot we can do automatically. We need for the admin to > consciously allow sending an unsecure password hash on the wire.
Response to comment #35, Yes, Jeff this working as long as what I want to mount has a windows share name and I can find out what it is. I can then mount with a credentials file. If I try to mount to something with a unc that doesn't a share name or I don't know the share name then I have to authenticate with KRB5 and the machine needs to be joined to the domain and have a valid ticket from the KRB5 server which is in my case a w2k8 r2 machine.
Yes, there's no support in cifs.ko for any sort of "browsing" of shares. cifs.ko is only able to mount shares where the UNC is known. It can also chase DFS referrals, but that's a different matter. Based on that, I'll close this since it sounds like it's working as expected.