RHEL 6.4 samba-3.6.9-151 includes a Samba file rename behavior change that is not documented in the Samba nor RHEL Release Notes and breaks some Samba client-side applications (e.g., Microsoft Word from Microsoft Office for Mac 2008 and 2011) The error encountered with Microsoft Office for Mac 2011 Word while trying to save to an existing document; "Word cannot save this document due to a naming or permissions error on the destination volume." The user's Word .docx document is 'lost' with only temporary files (e.g., Word Work File L_2.tmp and ._Word Work File L_2.tmp) remaining. The error is caused by the Samba 3.6 server-side file rename routine, vfswrap_rename(), when the routine attempts and fails to rename a file across filesystems resulting in a Samba response of STATUS_NOTE_SAME_DEVICE (rename(2) EXDEV). Some Samba client-side application do not handle the error gracefully. Samba 3.5 and earlier client-side applications do not need to handle the rename() EXDEV situation because Samba 3.5 routine vfswrap_rename() does automatically rename a file across filesystems. The work-around is to enable the Samba 3.5 file rename behavior via the Samba 3.6 newly introduced crossrename VFS module. Module crossrename is not enabled by default. To enable the module, update smb.conf; vfs objects = crossrename crossrename:sizelimit = 300 (300=300MB, 20MB is default) See man vfs_crossrename(8). BTW, RHEL 6.3 supplies samba-3.5.10-125.
Karo: your decision if you want to change the release notes of 3.6 for this retroactively. I'm not sure if this is a good idea. Richard: if you report the OS X client bug to Apple (bugreport.apple.com), you might wanna post the link to the report here. Thanks! BTW: I'm surprised that the temporary dot files from office are not on the same filesystem, I thougt they would be in the same directory, which should usually be the same filesystem ... :)
Good day Bjorn, I suspect Microsoft, not Apple, would need to change Microsoft Word code -- I need to verify. It is ugly but Microsoft Word does work with temporary files in the working directory but also attempts to create/use in the share root directory a directory named .TemporaryItems and file ._.TemporaryItems. It is during the process of renaming the temporary file within the share root .TemporaryItems directory to the working directory that the rename() is attempted and fails if the share root is on a different filesystem than the working directory. At that point Word produces the error and the original file no longer exist in name.
On 2013-06-20 at 18:52 +0000 samba-bugs@samba.org sent off: > https://bugzilla.samba.org/show_bug.cgi?id=9962 > > --- Comment #2 from Richard <rjackson.richard@gmail.com> 2013-06-20 18:52:49 UTC --- > Good day Bjorn, > > I suspect Microsoft, not Apple, would need to change Microsoft Word code -- I > need to verify. > > It is ugly but Microsoft Word does work with temporary files in the working > directory but also attempts to create/use in the share root directory a > directory named .TemporaryItems and file ._.TemporaryItems. It is during the > process of renaming the temporary file within the share root .TemporaryItems > directory to the working directory that the rename() is attempted and fails if > the share root is on a different filesystem than the working directory. At > that point Word produces the error and the original file no longer exist in > name. if the Darwin's smbfs translated to EXDEV on the posix layer on a rename and "mv" for example works right then it is a Office bug, right. You will see the same problem also without smbfs but with local filesystem mounts.
Bjorn, Agreed. The Samba 3.6 file rename function behavior change does highlight a flaw in the way Mac/Word handles a file rename across filesystems with or without Samba. The motivation for this report is to have the Samba 3.6 Release Notes document the Samba 3.6 behavior change. Getting Microsoft/Apple to correct/change Mac/Word is a different challenge. :)
Changing the release notes now does not make sense, I think. Closing out bug report. Thanks!
Documenting the Samba 3.6 file rename behavior change does make sense in the next Samba 3.6 series release. Think if it as a bug that was introduced earlier but addressed with the latest Samba 3.6 series release. It may not make sense in the original 3.6 release notes at this point if there is no practical mechanism.