Bug 5994 - mount.cifs: brl option does not produce documented semantics for fcntl(F_SETLK)
Summary: mount.cifs: brl option does not produce documented semantics for fcntl(F_SETLK)
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: user space tools (show other bugs)
Version: 2.6
Hardware: Other Linux
: P3 normal
Target Milestone: ---
Assignee: Steve French
QA Contact:
URL: http://bugs.debian.org/483507
Depends on:
Reported: 2008-12-25 11:33 UTC by Debian samba package maintainers (PUBLIC MAILING LIST)
Modified: 2019-12-08 03:24 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Debian samba package maintainers (PUBLIC MAILING LIST) 2008-12-25 11:33:17 UTC
The above URL gives the entire bug report from our user. I'm just passing it through as, frankly, this goes much further than my own expertise

Getting more details or rationale probably needs to get in touch with the original bug submitter...

Christian Perrier, on behalf of samba package maintainers in Debian
Comment 1 Daniel Kahn Gillmor 2008-12-26 16:35:05 UTC
I'm the original reporter.  it's been a while since i reported this, but i'm happy to dig back into my notes if i can help move the problem toward a resolution.
Comment 2 shirishpargaonkar@gmail.com 2009-03-05 12:33:34 UTC
I am using the test program, the only modification I did was to add a printf in
the else of both if (0 != fcntl()) statements.

I do not see errors, the F_SETLK command with F_WRLCK type succeeds.

Using cifs vfs version 1.57 and samba server version 3.2.5.

Comment 3 shirishpargaonkar@gmail.com 2009-03-05 13:44:15 UTC
cifstest6:~ # grep mnt /proc/mounts
//cifstest8/smb8 /mnt/smb_a cifs rw,mand,unc=\\cifstest8\smb8,
username=root,addr=,posixpaths,acl,rsize=16384,wsize=57344 0 0

cifstest6:~ # echo -n a > /mnt/smb_a/foo

cifstest6:~ # chmod g+s,g-x /mnt/smb_a/foo

cifstest6:~ # ls -la /mnt/smb_a/foo
-rwxr--r-- 1 nobody nobody 1 Mar  5 13:35 /mnt/smb_a/foo

cifstest6:~ # /tmp/fcntltest /mnt/smb_a/foo
fcntl fd F_RDLCK SETLK64 succeeded
fcntl fd F_WRLCK SETLK64 succeeded
Comment 4 Debian samba package maintainers (PUBLIC MAILING LIST) 2009-04-04 08:22:46 UTC
Shirish mentioned this bug is not reproducible on 3.2.5
Comment 5 Geert Janssens 2011-01-28 04:31:06 UTC
How about this situation:
I have an sqlite3 file that is hosted on a Windows XP machine. The share is mounted via mount.cifs on my Fedora 14 client machine. Whenever I try to use the sqlite3 file, I get locking errors. Some searches on the web referred to the nobrl option and eventually lead to this bug report. Using nobrl indeed does remove the locking errors, but is not really a good solution.

I googled for "sqlite3 cifs" and it returned several threads along the same lines. The problem also appears when a Vista server is used (according to these threads). And some seem to suggest that the problem doesn't happen when working between Windows machines (ie using a Windows pc for both the server side and the client side).

It's not clear to me if my issue is what this bug is about, but I got here via lauchpad bug 117730, which linked to the debian bug in the url above which got me here.

It seems this bug has been closed because it was not reproducible with a Samba server. I am however using a Windows XP machine as a server, and only use the mount.cifs client application. Is that supposed to work without problems ? I sure doesn't for me. If it should, then IMO this bug should be reopened.
Comment 6 Andrew N. 2019-12-08 03:24:44 UTC
Looks like this issue was not fixed by now (Ubuntu bionic 18.04.3)

Same behavior as described with sqlite3 and strace:
fcntl(3, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=1073741824, l_len=1}) = 0
fcntl(3, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=1073741826, l_len=510}) = -1 EACCES (Permission denied) 

the second one fcntl works fine on local filesystem but not on cifs 2.10, kernel 4.15.0-72

The workaround is to mount samba share with nobrl option 

Please adjust status of this issue, this should be CONFIRMED