Bug 905929 - mounting of cifs shares is failing
Summary: mounting of cifs shares is failing
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: cifs-utils
Version: 18
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Jeff Layton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-30 13:56 UTC by Terry Polzin
Modified: 2014-06-18 07:42 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-06-10 19:21:46 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Terry Polzin 2013-01-30 13:56:06 UTC
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:

Comment 1 Ian Kent 2013-01-31 00:35:59 UTC
I'm struggling to see how this is an autofs problem.

Can you provide information about the autofs configuration you
are using?

Comment 2 Terry Polzin 2013-01-31 01:23:25 UTC
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

Comment 3 Ian Kent 2013-02-12 06:17:32 UTC
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?

Comment 4 Terry Polzin 2013-02-12 15:14:11 UTC
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?

Comment 5 Terry Polzin 2013-02-12 15:19:32 UTC
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?

Comment 6 Ian Kent 2013-02-13 00:08:08 UTC
(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.

Comment 7 Terry Polzin 2013-02-13 13:24:28 UTC
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

Comment 8 Ian Kent 2013-02-15 09:29:51 UTC
(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.

Comment 9 Jeff Layton 2013-02-21 11:59:27 UTC
(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.

Comment 10 Terry Polzin 2013-03-01 15:53:22 UTC
I can not mount shares by the command line either.

Comment 11 Terry Polzin 2013-03-01 16:02:47 UTC
I get  a -13 with sec=ntlmssp from the command line

Comment 12 Jeff Layton 2013-03-01 23:50:59 UTC
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?

Comment 13 Terry Polzin 2013-03-02 01:30:17 UTC
[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

Comment 14 Jason Burgess 2013-03-07 14:56:38 UTC
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)

Comment 15 Jason Burgess 2013-03-07 14:57:25 UTC
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)

Comment 16 Ian Kent 2013-03-08 08:12:31 UTC
(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.

Comment 17 Jeff Layton 2013-03-08 11:58:06 UTC
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.

Comment 18 Terry Polzin 2013-03-08 12:21:38 UTC
Mount target machine is windows 2008 r2 server only authentication is AD how would you suggest I login?

Comment 19 Jeff Layton 2013-03-08 13:03:57 UTC
(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

Comment 20 Jason Burgess 2013-03-08 13:40:36 UTC
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

Comment 21 Terry Polzin 2013-03-08 14:53:15 UTC
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

Comment 22 Jeff Layton 2013-03-08 15:10:52 UTC
(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.

Comment 23 Terry Polzin 2013-03-08 15:15:10 UTC
Typo, my bad.

mount -t cifs -o creds=/root/olympic_ad  //misfs012/vol2/ /mnt
mount error(13): Permission denied

Comment 24 Terry Polzin 2013-03-11 14:58:18 UTC
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

Comment 25 Jeff Layton 2013-03-11 15:02:28 UTC
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.

Comment 26 Terry Polzin 2013-03-11 15:11:07 UTC
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.

Comment 27 Jeff Layton 2013-03-11 15:35:37 UTC
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.

Comment 28 Sergio Basto 2013-03-17 03:02:55 UTC
(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 ?

Comment 30 Sergio Basto 2013-03-17 05:41:12 UTC
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"

Comment 31 Jeff Layton 2013-03-17 10:40:56 UTC
(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.

Comment 32 Jeff Layton 2013-03-17 10:42:08 UTC
Terry, did any of the suggestions I made in comment #27 work?

Comment 33 Terry Polzin 2013-03-17 18:54:04 UTC
Jeff,

The only way my mounts work is if I use sec=krb5, which means I have to kinit every 24 hours.

Comment 34 Terry Polzin 2013-04-03 17:06:29 UTC
I have discovered that I was using a complete path name not a windows share name

Comment 35 Jeff Layton 2013-04-13 01:17:46 UTC
Terry, does that mean that this is now working for you?

Comment 36 Sergio Basto 2013-04-25 23:27:27 UTC
(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.

Comment 37 Terry Polzin 2013-04-26 19:43:50 UTC
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.

Comment 38 Jeff Layton 2013-06-10 19:21:46 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.