Bug 4404 - Vista and Offline Files broken, with Office 2007 (and more?)
Summary: Vista and Offline Files broken, with Office 2007 (and more?)
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.24
Hardware: x64 Windows XP
: P3 major
Target Milestone: 3.0.26
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
Depends on:
Reported: 2007-02-19 16:40 UTC by Tim Bishop
Modified: 2019-03-13 23:18 UTC (History)
1 user (show)

See Also:

tcpdump without offline files enabled, behaviour is correct. (186.69 KB, application/octet-stream)
2007-02-20 10:35 UTC, Tim Bishop
no flags Details
tcpdump with offline files enabled, behaviour is broken. (232.86 KB, application/octet-stream)
2007-02-20 10:36 UTC, Tim Bishop
no flags Details
Samba 3.0.25rc1 exhibting problem (454.17 KB, application/octet-stream)
2007-04-22 13:12 UTC, Tim Bishop
no flags Details
Dump from Windows 2003 server showing correct behaviour. (477.48 KB, application/octet-stream)
2007-04-22 13:13 UTC, Tim Bishop
no flags Details
testparm output (8.38 KB, text/plain)
2007-04-25 15:55 UTC, Tim Bishop
no flags Details
Patch (961 bytes, patch)
2007-06-04 18:29 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Bishop 2007-02-19 16:40:59 UTC
[logged with OS as XP since Vista is not listed - could it be added?]

I have a share exported from a Samba server (version 3.0.24 with the latest patches applied, running on FreeBSD) to a Windows Vista machine. The problem is only exhibted when I enable Offline Files (by selecting Always Available Offline) on a directory within the share. It works fine on a "normal" directory.

The problem is easy to reproduce. After enabling Offline Files open Word 2007 and make a new document. Hit save, and place it in the offlined directory named test.docx. On the Vista client I see two files:


The latter is the "usual" temporary file. It vanishes when I close Word. On the Unix filestore I see:


I've scanned the samba logs with debugging turned on and I can see it doing something with "E28BEAE6.tmp" and "test.docx" - maybe it's trying to write to a temporary file first and move it in to place (which maybe fails?). But I need some advice on what log level to use to get the best info here.

This scenario also occurs if you edit an existing file and save it. On the Vista machine it appears fine, on the Unix filesystem you see the original unedited file and a new .tmp file.

It's worth noting that the Sync Manager does notice this abnormality and attempts to let you fix it up, but it doesn't seem to work correctly in the useful direction (vista->samba).

Of course I'm happy to do what I can to help investigate this. Let me know if I can provide any logs or other relevant information.
Comment 1 Volker Lendecke 2007-02-20 03:07:32 UTC
Have you applied the patches in http://www.samba.org/samba/patches/?

Comment 2 Tim Bishop 2007-02-20 04:01:15 UTC
Yes, I've applied all of them.
Comment 3 Tim Bishop 2007-02-20 04:42:44 UTC
Just done some further testing. I can replicate the problem using the same version of Samba but on a Solaris server. I can confirm it all works as it should against a Windows server.
Comment 4 Volker Lendecke 2007-02-20 04:49:59 UTC
So the next step is clear: We need comparative sniffs against windows and Samba. See http://wiki.samba.org/index.php/Capture_Packets for hints how to create sniffs.


Comment 5 Tim Bishop 2007-02-20 10:34:31 UTC
Unfortunately I can't get Wireshark (or, more likely, WinPcap) to work - it can't detect the network interface in my laptop.

So the best I can do at this point is provide tcpdumps from the server side. I've done two captures.

dump.ok - without offline files enabled where it works fine
dump.bad - with offline files where it's broken

In both cases I saved a file to \\vulture\files\home\offlinetest called test.docx. In the failure case I was left with 4608E83B.tmp rather than test.docx.

In the many times I've tried this I have occasionally noticed the .tmp file on the Vista end for a split second before it vanishes. So this likely supports my idea that it's writing to a temporary file first.


(files will be attached shortly)
Comment 6 Tim Bishop 2007-02-20 10:35:24 UTC
Created attachment 2305 [details]
tcpdump without offline files enabled, behaviour is correct.
Comment 7 Tim Bishop 2007-02-20 10:36:26 UTC
Created attachment 2306 [details]
tcpdump with offline files enabled, behaviour is broken.
Comment 8 Gerald (Jerry) Carter (dead mail address) 2007-04-06 08:56:31 UTC
Jeremy, Here's another Vista bug we should review.  Maybe not for 3.0.25
but probably soon.
Comment 9 Jeremy Allison 2007-04-07 23:58:00 UTC
It turns out that we weren't doing the protocol correctly for tconX, NTCreateX and NTTransCreate - who knew we'd still be finding things like this in 2007 ? :-).
When the extended response bit is set in the tconX request that changes the response from 3 words to 7 - the extra words are the share access control mask, when the NTCreateX/NTTransCreate extended response bit is set the reply adds 32 extra bytes containing the access mask of the file (used for caching locally I believe) and for pipes contains two access masks (don't know why).

This bug might be fixed for 3.0.25rc1 now, but I don't have an Office 2007 environment set up yet so can't officially test.

Comment 10 Gerald (Jerry) Carter (dead mail address) 2007-04-10 10:08:34 UTC
Should be fixed in 3.0.25rc1.  Please reopen if not.
Comment 11 Tim Bishop 2007-04-21 19:22:26 UTC
Sorry for the delay, I've only just managed to get 3.0.25 rc1 installed. I'm afraid this bug isn't fixed but it has changed.

When saving a file from Office 2007 I now get an "Access denied" error message. From the Vista end I can see the file name I tried to save as with a size of 0kb. On the Samba end I can see:

-rwxr--r--   1 tdb   users  9846 Apr 22 01:19 AB8B4671.tmp
-rwxr--r--   1 tdb   users     0 Apr 22 01:20 test.docx

So it looks like you're tweaking the right bit of code, but something is still not right.

I'll look at doing a packet capture tomorrow.
Comment 12 Jeremy Allison 2007-04-22 01:40:38 UTC
A packet trace would definately help, as would a packet trace from Vista to a Windows 2003 server where this works. Please use the same filename in each case for the Word file.
Comment 13 Tim Bishop 2007-04-22 13:09:38 UTC
Ok, dumps are done and will be attached shortly. They were taken using tshark on the server side (I can't get wireshark to run on my vista machine). In both cases I saved a new file called tdbtest.docx from Word 2007 in to a folder called offlinetest (which had previously been "made available offline") in a share called junk. I used the samba Vista client in both cases.

Maybe worth noting that since I upgraded to 3.0.25rc1 I can't make any new folders available offline from the vista client. I get the same access denied message.
Comment 14 Tim Bishop 2007-04-22 13:10:38 UTC
I should have added this bit of info to that last message. This is what the filesystem looks like on the samba server - the temporary file name might be useful when looking through the dumps?

-rwxr--r--   1 tdb   users  9868 Apr 22 19:01 F6383BB4.tmp
-rwxr--r--   1 tdb   users     0 Apr 22 19:02 tdbtest.docx
Comment 15 Tim Bishop 2007-04-22 13:12:08 UTC
Created attachment 2397 [details]
Samba 3.0.25rc1 exhibting problem

Dump taken using tshark on the samba server.
Comment 16 Tim Bishop 2007-04-22 13:13:26 UTC
Created attachment 2398 [details]
Dump from Windows 2003 server showing correct behaviour.

Dump taken using tshark on the windows 2003 server.
Comment 17 Jeremy Allison 2007-04-24 15:51:38 UTC
I have found the fix for this. Set :

map acl inherit = yes

in the [global] section of your smb.conf. You don't want to know how long it took for me to find this :-).

Comment 18 Gerald (Jerry) Carter (dead mail address) 2007-04-25 06:14:15 UTC
Comment 19 Tim Bishop 2007-04-25 15:54:36 UTC
Sorry to do this, but it's still behaving the same with this option set. Attached is the output of testparm to confirm that.

I hate being a pain :-(

Comment 20 Tim Bishop 2007-04-25 15:55:09 UTC
Created attachment 2415 [details]
testparm output
Comment 21 Gerald (Jerry) Carter (dead mail address) 2007-04-28 21:50:26 UTC
Are you running on Linux and have the acl,user_xattr options 
enabled for the mount?  ANd do you have the libacl and libattr devel 
packages installed before compiling smbd?
Comment 22 Tim Bishop 2007-04-29 05:29:49 UTC
I'm running on FreeBSD 6.2. I also replicated the initial issue at work on Solaris 9. I've not tried with Linux and don't have access to a Linux system.
Comment 23 Gerald (Jerry) Carter (dead mail address) 2007-04-29 06:38:21 UTC
Apparently without EA's you cannot do inherited ACLs and therefore cannot do offline support.  Jeremy might be willing to make a change to drop the DACL_ACL_PROTECTED FLAG in some cases but this is no longer considered a show stopper for 3.0.25.
Comment 24 Tim Bishop 2007-04-29 13:40:52 UTC
Just to clarify, has Vista changed behaviour with offline files? Because this all works fine with XP.
Comment 25 Jeremy Allison 2007-06-04 18:29:34 UTC
Created attachment 2734 [details]

There's an off-by-one bug in returning the access mask associated with an offline file. Please test this patch against 3.0.25a.
Comment 26 Tim Bishop 2007-06-08 13:34:10 UTC

I've tested this new patch and I can now confirm the strange Permission Denied messages I had been getting in 3.0.25 have gone away.

However, the original problem unfortunately still persists.

Comment 27 Oliver Cronk 2010-10-17 15:07:53 UTC
Would be happy to help with getting this one resolved (from the testing side) as its quite an annoying bug (I can confirm it also happens on Windows 7 x64 with Office 2007). Its possible that Office 2010 doesn't have the issue but cannot confirm that for definite just yet.
Comment 28 Oliver Cronk 2010-10-17 15:13:35 UTC
Similar MS bug report / workaround: http://support.microsoft.com/kb/2002109
Comment 29 Tim Bishop 2010-10-17 16:23:27 UTC
I can confirm the issue on Win 7 x64 with Office 2010.
Comment 30 Björn Jacke 2019-03-13 23:18:30 UTC
this problem was unseen for long, closing as fixed now.