mount.cifs fails to use the password from a credentials file, but if the same password is used on the command-line it works fine:
> # mount /store
> mount error 13 = Permission denied
> Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
> # mount -opassword=mypassword /store
> mount.cifs warning - password specified twice
(succeeds, returns 0)
The failed mount prints this to dmesg:
> Status code returned 0xc000006d NT_STATUS_LOGON_FAILURE
> CIFS VFS: Send error in SessSetup = -13
> CIFS VFS: cifs_mount failed w/return code = -13
Using Debian Samba packages with version 1:3.2.0~pre3-1 on powerpc and x86.
I have checked the credentials file and there are no spaces in it, just
the same worked fine with Debian samba packages with version 1:3.0.28a-2.
I'm guessing this is probably fixed by
46614ca... Revert "mount.cifs: Zero mountpassword content before freeing."
on v3-2-test but I haven't had the chance to build with that patch yet.
Relying on /etc/fstab to provide the credentials option:
//erwin.network.midg3t.net/store /store cifs uid=ted,gid=ted,credentials=/home/ted/.smbcreds-erwin 0 0
The problem is that the '\n' is maintained at the end of the password. It was introduced by cc23f91d639db61903bf8b6c9fa46ec9c1f44178.
Changing the 3rd argument of strlcpy from MOUNT_PASSWD_SIZE+1 to length+1 should do the trick (that's what the username processing code does), but the intention to remove the '\n' is more obvious if you set
temp_val[length] = '\0';
before breaking out of the for loop 13 lines above (the one that determines the password's length).
The next block of code that processes the domain looks similarly buggy.
Uh, I misquoted my credentials file in comment #0. The second line actually starts with "password=" like it should.
Created attachment 3272 [details]
Patch as mentioned in comment #2
This does the trick.
Created attachment 3273 [details]
Great catch thanks ! Sorry for messing this up. I like this patch better as it more correctly expresses the intent, plus I want to make sure all strlcpy calls use the correct physical buffer size to ensure I don't mess these up. Can you test this patch and confirm it still works for you ?
Tested attachment #3273 [details], it fixes the problem. Thanks Jeremy.
Just got this on Fedora 9 preview, which uses 3.2.0-1.pre3.
What version of Samba does change cc23f91d639db61903bf8b6c9fa46ec9c1f44178 correspond to?
Ah, I found it.
So the change was made on 24 April 2008, whatever version that was.
Fedora 8 and Ubuntu 8.4 are both using Samba 3.0.x, so I guess they're unaffected.
(In reply to comment #8)
> So the change was made on 24 April 2008, whatever version that was.
It was made shortly before 3.2.0-pre3 - that's the first release it was in.
Looks like the fix was checked in on May 1st.
Can this now be closed?
Yes, this bug is now fixed. Closing.