Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

File Locks and SMB shares with ML

I've been doing a lot of research on SMB and the way it locks files during access. I've made a lot of ground work in my research but could use a little further assistance from this support community.


The symptom is simple to explain: Users are occasionally being prompt for a username and password when attempting to rename or move files and folders.


After doing some research on this topic, I have discovered that there is a direct relationship to files being open on the server at the time the user is attempting to rename or move the folder. The following thread, albiet old, appears to have nailed the problem on the head http://arstechnica.com/civis/viewtopic.php?p=24558131. In particular, there appears to be file locking happening when preview is turned on through the finder. I've had all users remove preview from their Macs and this appears to have helped reduce the occurances of the password prompt, but has not completly solved the problem. This is also a work around, not a fix.


I've been using a series of command to help me trace the problem including openfile.exe on the Windows 2012 Storage Server (sharing the files via smb only) to discover who has what files open on the server, and the lsof command on the client workstations to discover what process has the file open. So far, the finder is consistently the only thing with the file open... even with the finder preview turned off. I've also found that the "open file" is simply the fact that the offending users Mac has a finder window with just the folder open (none of the files within the folder or previews open).


Is the real solution to simply close all finder windows when you're done working in a folder, or is there more that anyone can think of to help me find out exactly what is holding the file lock? Is this a known bug in the SMB implementation of ML? Can we expect to see a fix with Mavericks which will now be using SMB2.0?


Any help or information anyone can provide would be greatly appreciated. I have a bunch of documentation on this issue and would be happy to share. Please let me know if anyone needs any additional details.

Mac Pro, OS X Mountain Lion (10.8.2)

Posted on Aug 15, 2013 1:08 PM

Reply
29 replies

Aug 16, 2013 6:05 PM in response to Finicle

We are seeing this also, have tried 10.6, 10.7 and 10.8 clients against both server 2008R2 and server 2012.


Exactly the same symptoms as you describe, both the shares MMC utility and lost on the Mac client show that files are open even when they do not apear to be in use.


lsof always shows the finder as the culprit, and quitting the finder will release the file handle and this is immediately seen on the Windows server.


I managed to find some other folks on a spice works board reporting much the same thing.


http://community.spiceworks.com/topic/246675-server-2003-does-not-release-open-f ile-from-osx-lion-client


With server 2003, interestingly someone mentioned that this was not the case with 10.5, we has yet to test this and it's hardly a viable solution.


It looks as this is a Finder issue as opposed to any SMB protocol / oplock issue, but I'm ****** if I know what to do to prevent it. It also looks like it will be challenging to resolve as unless the Finder's behaviour can be modified It will be down to Apple to fix.


FWIW it only seems to happen in directory hierarchys that end in a file (although in real life this will be most if not all of them) with the file at the end of the hierarchy being held open by the Finder indefinitely.


We also need to see weather this is also the case on AFP servers, and possibly Samba running on Linux, I'm pretty sure this is t the case with AFP, but why the Finder would behave differently with one file system than another like this I do 't know.


Happy to discuss this further, as it has pretty sever implications for OS X in the corporate environment.

Aug 22, 2013 9:27 AM in response to Stephen Buckley

Thanks for replying Stephen. I appreciate it more than you might believe.


Thanks for the link to spice works. It looks like that thread is just another of many unconcluded thread about this issue.


I have a few other new discoveries to add to the topic. I'm not sure how much help they are, but I'll mention them anyway just in case and for the sake of discussion.


Looking at the settings in the finder, each view handles preview mode differently. The icon, list, and cover flow views appear to handle each folder's preview settings individually. I can turn off preview for one of the folders, but that setting seems to only apply to that folder. This obviously complicates the ability to control previews from locking files (especially when there are over 40 users). Column view appears to be the only setting that turns off previews globally. If anyone can prove me wrong about any of this, please do so. I would be happy to be corrected! These are just my findings so far.


I also signed up for a developer account which is letting me submit bug reports and is allowing me to test drive Mavericks. I can confirm that file locks currently happen exactly the same with OS X Mavericks. It hasn't been released just yet, but I'm running the current beta version and so far there is no resolution to this problem. I've also submitted this in a bug report to Apple. I fully agree with you that unless someone has knowledge about how to control this in the finder that isn't sharing with the rest of us, then this is likely up to Apple to fix. I will let you know what, if anything, comes from my bug submission.


We ran a trial version of ExtremeZ-IP so that we had an AFP connection to our 2012 windows server. I can confirm that we had the same problem there. We also had a 10.6 Server running with everyone connecting to it via AFP. The file lock problem did not happen for us with the Mac server. The problem really does seem to be related to both the finder and the SMB protocol.


Lastly, thanks for the heads up about the directory hierarchies that end in a file. I will be looking at that in this environment to see if I can draw the same conclusion.

Sep 5, 2013 7:37 PM in response to Finicle

I've been researching the exact same issue for the past few weeks. So frustrating. I've come across the same dead-end discussions that I'm sure you all have as well. If I come across any additial details in my process, I'll be sure to return and share some findings, as I hope you will as well.


Maybe we can help eachother by sharing a detailed running list of various troubleshooting steps we've all attempted. Certainly Stephen, Fincle, and I are having the same issue and have come to the same conculsion.


btw, my current environment:


-Windows Server 2008 R2 file server (Active Directory)

-Clients running 10.6.x and 10.8.x having same issues as described above

-Clients making heavy use of InDesign, but reports from users that this happens on other filetypes as well as renaming/moving directories


My suspicion was that it might be the whole Named Streams business, but don't know, and none of the tests I've run are conclusive.


Anyways, will keep my eye on this thread and keep my fingers crossed. There is hope, I'm sure.

Sep 6, 2013 9:35 PM in response to ingrelli

It is def preview and/or quick look. I've setup a lab environment and am in the process of running some tests. I'm able to effectively recreate the locking conditions and can recreate at will. I am in the process of rolling out a couple OS X VMs to test different ways of disabling quick look and/or preview, I will then also test w/ InDesign (because the Adobe software may also preview files and not release them properly as well).


Getting closer to some sort of (hopefully) workable solution/workaround. Will update this weekend or early next week with my findings.

Oct 2, 2013 7:40 AM in response to ingrelli

Sorry for the delay in replying, clearly this is a reasonably common problem! We have now had time to trace the issue, and come up with some work arounds of our own and run them for a little while.


Ingrelli is indeed correct, this issue is down to the Finder and it's icon preview feature, we can corelate the files the finder has open (using lsof on the client) with the files seemingly "held" open on the Widnows file server. Quitting the Finder or unmounting the share drops these files being held open.


This appears not to happen on AFP volumes, but as we haven't tested thus much I can't comment as thi is due to AFP server not caring that files are held open or that the Finder behaves differently, I suspect the former.


I can however confirm that OS X 10.9 preview still exhibits this behaviour.


Our fix which apears to be meeting with some success has been a two pronged approach:


  1. To use MCX (via Casper) to force the Finder to not generate icon previews in any of it's view modes.
  2. To delete any existing .DS_store files on shares and to force out the setting using MCX (via Casper) to prevent tehir creation on network volumes.


The most ardous part of this once we had arrived at a strategy was to constructsome MCX that would reliably set the Finder icon views preferences; Due to their being burried a couple of dictionaries deep in the Finder preferences, defaults can't touch the key/value pairs, and using plist buddy wasnt effective as the Finder would most likely be running when plist buddy made it's changes, causing them to get overwritten or cause the Finder to hang.


Neverthe less my Colleauge Josh managed to get some working XML that could be pushed via MCX to achieve the desired effect.


We have now been runnign this solution for a couple of weeks and appart from some user confusion about the icon previews disapearing the outcome has been positive with a dramatic reduction in the reports of files and folders unable to be renamed/moved.


I have asked Josh if he wouldn't mind contributing to this thread with the details of how we developed the XML fragment psuhed via MCX to set the Finder preferences as this was by far the most involved part of the process.


I'd be interested in others experiences with this issue and your solutions.


Stephen

Nov 20, 2013 4:33 AM in response to Finicle

Hello all - many apologies for my delay in posting here; and Squiggle, thanks for the second-hand nudge. As Stephen said we have been testing a solution concerning a setting in Finder's view options for the last few months, and these seem to have solved the issue in hand.


Essentially, we found that Finder was holding files open whenever the 'Show Icon Preview' option was set, on any of the four folder views, on any client machine accessing the share. Below is a piece of documentation I wrote up for our Service desk explaining how to diagnose and manually fix this issue on the client:


- In Finder, open any folder


- Click on the cog icon and select 'show view options.' Check that, in the dialogue box which appears, the 'Show icon preview' box is not checked. Click the other three Finder views and check it's turned off here too.

- Click 'Use as Defaults'


User uploaded file


In order to make this change remotely on multiple machines, you will need to change the clients' com.apple.plist files, and set every instance of the <showIconPreview> key to <False>. This is nested within several key / dictionary pairs in com.apple.finder.plist, once under <standardViewOptions> and thrice within <standardViewSettings>. As Stephen has already mentioned, the fact that this key is nestled deep within compound dictionaries seems to render them untouchable by defaults, though I would be very happy to be corrected on this.


How you push this change out will depend on your management system. We had been using Casper to

to create a managed preference pertaining to <standardViewOptions> and <standardViewSettings> within com.apple.finder.plist. These contained as values the entire dictionary associated with these keys, with the value for each <showIconPreview> set to false. This was then applied at a User Enforced Level (running every logon after Finder has set up the system defaults).


As a side note, I have found that certain machines (Such as the 10.8.3 machine I'm working on now) contain a key named <FK_StandardViewSettings>, which I have been unable to ascertain the purpose or origination of. These don't seem to affect the fix, so we've left them alone.


Irritatingly, Casper has dropped support for custom Managed Preferences in their latest release, so this problem has now resurfaced. I will keep this page updated with any fixes or workarounds I find.


Hope that helps,


Josh Smith


Jan 31, 2014 1:09 PM in response to Finicle

Just found this post at the prompting of a colleague. We've experienced similar issues on 10.8 systems. Disabling the preview sppeared to help but we have also made sure our virus protection software is not scanning mounted shares. The server should be scanning the files on the server anyway so that doesn't problematically reduce our security footprint.

Feb 4, 2014 12:26 PM in response to Finicle

I did some careful testing and narrowed this down to occuring under a very restrictive and repeatable circumstance:


This is how I recreated the problem.


1. Create two accounts on the Windows 2008 R2 file server to use to log in to the file server.

2. Use two Macs, and log in to each with a different standard user account. Mine were bound to Active Directory, but the accounts I used on the Macs were local accounts.

3. On Mac #1, log in the Windows file server.

4. Create a new folder

5. Copy some documents in it, but make sure that at least one of the documents does not have an embedded preview image

6. In a Finder window, switch to Column View. Make sure "Show preview column" is checked under View Options and set that as the Default for all folders in View Options.

7. Navigate inside your test folder and select the document that has an embedded preview so it appears in the preview column.

8. On Mac #2, log in to the Windows file server.

9. Try to rename the folder containing the document you have the Finder previewing on Mac #1. You will be able to do so.

10. On Mac #1, select the document that does not have an embedded preview and view it in the Preview column.

11. On Mac #2, try to rename the folder containing it. You wil be prompted to enter administrator credentials.


You can navigate away from the file in the Finder on Mac #1, or close all the Finder windows. Mac #2 will stull receive the authentication prompt.


Authenticating as an administrator will bring up an error dialog indicating you do not have permission to rename that folder.


Only when Mac #1 disconnects from the Windows file server can Mac #2 rename the parent folder.


Having "Show icon preview" in the View Options for any of the four Finder views did not cause the problem. I verified this by enabling that option but disabling show preview column in column view.


I have filed this with the Apple Bug Report tool.

Apr 5, 2014 4:33 PM in response to joshsmith2

Have you tested this on Mavericks and Mountain Lion, in their current releases?


And would anyone happen to know if this issue still happens in mavericks smb, since smb is now the default method of connection?


And has anyone heard back from Apple with their open support case regarding this specific issue and the current workaround?


We are a Mac support company, and look after many small businesses that have 2 to 10 macs. And so in most cases there is no management software in place.


But having a patch or fix provided by apple, expecially now that their mavericks server is using smb by default would obviously be ideal.


Lastly, has anyone seen this in effect when connecting via nfs?


Jamie

File Locks and SMB shares with ML

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.