Bug 700206

Summary: CIFS VFS: unexpected error on SMB posix open
Product: [Fedora] Fedora Reporter: Luc Lalonde <luc.lalonde>
Component: sambaAssignee: Guenther Deschner <gdeschner>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: asn, gansalmon, gdeschner, itamar, jlayton, jonathan, kernel-maint, madhu.chinakonda, ssorce
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-30 14:51:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
Wire capture for samba communications none

Description Luc Lalonde 2011-04-27 18:50:46 UTC
Description of problem:

I get this error while trying to mount home directory from Samba 3.5.8 server:

Apr 27 14:39:44 localhost kernel: [14858.888596] CIFS VFS: server of type Samba 3.5.8 returned unexpected error on SMB posix open, disabling posix open support. Check if server update available.

We use the 'pam_mount' package to mount Samba home directories.  It is working in our labs with Fedora 13... However, now that this error disables 'SMB posix open' we are unable to use Samba for home directories.

Here are our mount options (/etc/security/pam_mount.conf.xml):

<volume fstype="cifs" server="ada.info.polymtl.ca" user="*" path="%(USER)" mountpoint="/usagers/%(USER)" options="dir_mode=0700,file_mode=0600,serverino,nobrl" />

On the server side, 'unix extensions' are enabled.

Kernel version on the fedora-15-beta1 client:

Comment 1 Jeff Layton 2011-04-29 00:55:48 UTC
(In reply to comment #0)
> I get this error while trying to mount home directory from Samba 3.5.8 server:

Are you sure you're getting this on mount? Or are you getting it when doing some sort of access of the actual mount?

Comment 2 Jeff Layton 2011-04-29 12:56:54 UTC
I tried to reproduce this mounting by hand to a server of the same version, but was unable to make this error message pop. What may be most helpful is a capture so I can see what's happening on the wire. Instructions of how to do that are here:


Comment 3 Luc Lalonde 2011-04-29 14:41:30 UTC
Created attachment 495791 [details]
Wire capture for samba communications

Here's the capture as requested...

I've also tried to mount manually without pam_mount using this command:

mount.cifs //sambaserver/p302568 /mnt/cifs/ -o user=p302568,password=ut87nb,serverino,nobrl

And I cannot reproduce the error I get with pam_mount.

Here's the verbose log (I've take out the real servername, ip, username):

Apr 29 10:37:38 localhost sshd[1455]: pam_mount(misc.c:380): 50 22 0:39 / /usagers/username rw,relatime shared:3 - cifs //sambaserver/username/ rw,unc=\\sambaserver\username,username=username,uid=19062,forceuid,gid=7006,forcegid,addr=,posixpaths,serverino,acl,rsize=16384,wsize=57344,actimeo=1
Apr 29 10:37:38 localhost sshd[1455]: command: 'pmvarrun' '-u' 'username' '-o' '1' 
Apr 29 10:37:38 localhost sshd[1460]: pam_mount(misc.c:38): set_myuid<pre>: (ruid/rgid=0/0, e=0/0)
Apr 29 10:37:38 localhost sshd[1460]: pam_mount(misc.c:38): set_myuid<post>: (ruid/rgid=0/0, e=0/0)
Apr 29 10:37:38 localhost sshd[1455]: pam_mount(pam_mount.c:440): pmvarrun says login count is 1
Apr 29 10:37:38 localhost sshd[1455]: pam_mount(pam_mount.c:645): done opening session (ret=0)
Apr 29 10:37:39 localhost kernel: [  315.792692] CIFS VFS: server of type Samba 3.5.8 returned unexpected error on SMB posix open, disabling posix open support. Check if server update available.

Comment 4 Jeff Layton 2011-04-29 15:31:10 UTC
Thanks. wireshark still doesn't decode posix opens correctly, but I can dissect it by hand...

OpenFlags = 0x02
PosixOpenFlags = 0x42 (SMB_O_WRONLY | SMB_O_RDWR) !?!
Permissions = 0x1c0 (0700)
Level = 0x200

So, the PosixOpenFlags look very wrong, but maybe I'm decoding it incorrectly. I'll double check...

Comment 5 Jeff Layton 2011-04-29 15:33:06 UTC
Oh, duh... It's SMB_O_WRONLY|SMB_O_TRUNC, so that should be fine. This looks legit to me, so this may be a samba bug.

Comment 6 Jeff Layton 2011-04-29 15:47:47 UTC
Ok, I can reproduce this now with a small C program that opens a file O_WRONLY|OTRUNC. Samba sends back STATUS_INVALID_PARAMETER for some odd reason. This looks like a samba bug, but I'll do a bit more investigation to be sure.

Comment 7 Jeff Layton 2011-04-29 15:55:33 UTC
Yep, samba bug I think...

call_trans2setfilepathinfo(6) testfile (fnum -1) info_level=521 totdata=18
smbd_do_setfilepathinfo: testfile (fnum -1) info_level=521 totdata=18
smb_posix_open: invalid create mode 0x40
error packet at smbd/error.c(160) cmd=50 (SMBtrans2) NT_STATUS_INVALID_PARAMETER

0x40 is SMB_O_TRUNC and that should clearly be valid on its own.

Comment 8 Jeff Layton 2011-04-29 16:03:07 UTC
From smb_posix_open in the samba sources:

        if((wire_open_mode & (SMB_O_CREAT | SMB_O_EXCL)) == (SMB_O_CREAT | SMB_O_EXCL)) {
                create_disp = FILE_CREATE;
        } else if((wire_open_mode & (SMB_O_CREAT | SMB_O_TRUNC)) == (SMB_O_CREAT | SMB_O_TRUNC)) {
                create_disp = FILE_OVERWRITE_IF;
        } else if((wire_open_mode & SMB_O_CREAT) == SMB_O_CREAT) {
                create_disp = FILE_OPEN_IF;

        } else if ((wire_open_mode & (SMB_O_CREAT | SMB_O_EXCL | SMB_O_TRUNC)) == 0) {
                create_disp = FILE_OPEN;
        } else {
                DEBUG(5,("smb_posix_open: invalid create mode 0x%x\n",
                        (unsigned int)wire_open_mode ));
                return NT_STATUS_INVALID_PARAMETER;

If O_TRUNC is not used with O_CREAT the above fails. It's completely valid to use O_TRUNC on its own in POSIX however.

Comment 9 Jeff Layton 2011-04-29 16:04:05 UTC
Luc, this bug is upstream too. It might not hurt to open a bug for this at bugzilla.samba.org as well...

Comment 10 Luc Lalonde 2011-04-29 17:03:21 UTC
Ok, it's done:


Comment 11 Andreas Schneider 2013-01-30 14:51:29 UTC
Looks like this has been fixed quite a while ago. Closing bug report.