Bug 11637 - 'Access is denied' error trying to rename to a file that was recently read via a symlink
Summary: 'Access is denied' error trying to rename to a file that was recently read vi...
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.2.4
Hardware: x64 FreeBSD
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-08 12:25 UTC by Martin Simmons
Modified: 2015-12-14 19:50 UTC (History)
0 users

See Also:


Attachments
tcpdump capture of port 445 between the server and client (297.00 KB, application/octet-stream)
2015-12-14 19:48 UTC, Martin Simmons
no flags Details
smbd log between the server and client (4.40 MB, text/plain)
2015-12-14 19:50 UTC, Martin Simmons
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Simmons 2015-12-08 12:25:22 UTC
Running the batch script below on a Windows 8 machine causes the first move command to get an 'Access is denied' error.  After waiting about 10 seconds in the pause command, the identical second move command works.

type m:\tmp\st\b
echo foo > m:\tmp\st\c
move m:\tmp\st\c m:\tmp\st\a
pause
move m:\tmp\st\c m:\tmp\st\a

The directory m:\tmp\st was created on the server with a symlink from b to a like this:

mkdir st
touch st/a
ln -s a st/b
ls -l st
total 1
-rw-rw-rw-  1 martin  users  0 Dec  8 11:46 a
lrwxrwxrwx  1 martin  users  1 Dec  8 11:46 b -> a

Here is the smb4.conf as seen by testparm:

[global]
	workgroup = LISPWORKS
	security = USER
	log file = /var/log/samba/log.%m
	max log size = 50
	unix extensions = No
	printcap name = /etc/printcap
	idmap config * : backend = tdb
	acl allow execute always = Yes
	print command = /usr/bin/lpr -r -P%p %s
	lpq command = /usr/bin/lpq -P%p
	lprm command = /usr/bin/lprm -P%p %j
	veto files = /.tag-base/
	map archive = No
	wide links = Yes

[homes]
	read only = No

I suspect this is caused by a bug/misfeature in oplock handling because I can work around it by adding
veto oplock files = /b/
to smb4.conf.

From the output of smbstatus during the pause, it looks like the Windows 8 machine delays releasing the oplock on tmp/st/b, which causes the rename to fail.

This problem didn't occur with samba 3.6.5 (FreeBSD ports samba36-3.6.5).

This problem also occurs with a Windows 7 client, but not with Windows XP.
Comment 1 Jeremy Allison 2015-12-08 19:16:18 UTC
Can you get a wireshark trace please, plus a debug level 10 log from smbd and upload them both to the bug ?

Thanks.

Jeremy.
Comment 2 Martin Simmons 2015-12-14 19:48:42 UTC
Created attachment 11711 [details]
tcpdump capture of port 445 between the server and client
Comment 3 Martin Simmons 2015-12-14 19:50:21 UTC
Created attachment 11712 [details]
smbd log between the server and client

Ok, I've attached the tcpdump (port445.pcap) and smbd log for this client (log.heapw864).