Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Our build environment pumps out the latest build onto a Windows file share in a predefined location. We get file lock problems when remote users open and maintain folders and files on that read-only file share, and this causes our builds to break. Is there any technology that can solve this for us?

I've thought about

  • DFS-R
  • BranchCache
  • Enabling only WebDav and disabling SMB (can you?)

but none of those candidate solutions seem like a great fit so far.

To clarify, assume the path to the "latest build" is \server\share\path\Latest and only the build server has write access. Someone has opened a command prompt or an msi file somewhere in the "Latest" folder. Now the build server is done and needs to purge all content from the folder before copying in all the newly built pieces. No can do.

If an SMB share had had symbolic link support or some idea of transactions like NTFS or being able to rename "open" directories like HFS - but nope.

And putting all binaries in Sharepoint Document folders as has been suggested elsewhere seems like a crappy idea as well because of the data volume. I'd rather go for a WebDAV-only share that mounts like a file system but behaves like a web site.

share|improve this question
Just to clarify, Sharepoint folders can be mounted as Webdav shares, albeit somewhat fussily in Win7 (vista?) onwards. They can then be addressed just as you would a normal SMB share. I can't vouch for how they would treat locks however, so trial and error may be required. – sahmeepee Dec 22 '13 at 18:45

Do you mean they're actually editing these files, or this is some kind of situation where no one is actually using the files but there's a file lock on them?

If they're actually using those files (or have the file open in an editor while they're out having a donut) then you probably don't want those files to be opened in any way other than with an application that opens them with read-only copies or you'll have potential corruption. You said the file share is read-only though. So what are they doing that wouldn't allow multiple opens on the file as read-only? You don't mention what your build process is either, so maybe this is specific to that workflow?

Your best solution may be to try isolating your build environment from your development environments. Have a development process that checks out from a repo all your sources and builds them on a dedicated server and dedicated share, away from anything touched by your developers. That way you don't need to worry about devs altering something or breaking your build process, and the build process won't need to worry about anything being changed as it's working.

share|improve this answer

If you used a Linux file server, these 3 options in smb.conf might be useful.

strict locking = no
blocking locks = no

# from man page: Be careful about disabling locking either globally or in a specific service, as lack of locking may result in data corruption. You should never need to set this parameter.
locking = no

But to use those, you would want a separate share for the writeable clients without the above, which I assume means that warning doesn't apply.

share|improve this answer
The original poster wrote about a Windows file share, no mention of Samba there. – the-wabbit May 8 '12 at 12:23
um... yes, you are right. And I don't think samba runs on Windows. Back to the drawing board... – Peter May 8 '12 at 13:46
is "Opportunistic Locking" the same thing? – Peter May 8 '12 at 13:48
Nope, oplocks are just an optimization allowing clients to cache data. There is no Windows counterpart to Sambas option to disable locks entirely. Running Samba on Windows could turn out as an interesting enterprise. There even seems to be a guy having tried that (as is the case with most insane things), but I would not recommend that kind of setup if you need to rely on it :) – the-wabbit May 8 '12 at 15:31
I agree. Sounds like a great research project, but not something to put in production yet. ;) But you could virtualize it in Linux :) (slower but stable) – Peter May 9 '12 at 10:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.