Problem Renaming or Moving Folders on SMB Share

[ndudley]

We recently moved our main server from an XServe running AFP to Windows 2008r2 using the SMB protocol. We are experiencing an problem with our users being unable to move and/or rename folders and files on the server when connected via SMB from a Mac.

It seems to be that when a folder is open or in use by another user, the file is locked and asks for Admin credentials to move or change the folder. We haven't been able to figure out a fix for the problem. I was wondering if anyone else has stumbled across this problem or has a solution?

[tcam]

have you looked at the ACL on the server?

[Kennedy]

We're having exactly the same issues. The ACLs on the SMB server are perfect.

Users are being prompted for local administrator credentials to move or rename their own folders.

This is a drama, as most of our users are not local administrators of the machines.

Anyone out there have any ideas?

Cheers

[ndudley]

We noticed that even when we enter the local administrator password it doesn't seem to allow the folder to be unlocked...

Still stumped though, we are going to try ExtremeZ-IP to see if we can fix it with a 3rd party tool. I'll update once we have tested it.

[ndudley]

Ok. Just did a little more digging and this seemed to do the trick - haven't tested in a big group but you guys might want to give it a try:

Problem:
Finder creates a .DS_Store file that stores metadata for all files that are opened. What happens with the network share it that the .DS_Store file is recognizing that the file is in use.

Solution:
Prevent Finder from creating .DS_Store files on local machines. Run this command in terminal and reboot.

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

I tested with one file and will keep testing but I figured I'd give you all a heads up, I mad a little progress.

[ndudley]

Not an effective solution. Ignore my previous post.

[dwandro92]

Are your clients running Mavericks?

[Kennedy]

Mountain Lion here. I see lots of hidden files such as .smbdelete etc when clients are accessing folders.

I'm no expert on this, but if these files are being written to or are open even when no action is occurring then there will be issues moving or renaming, surely.

[ndudley]

I have clients running both Mavericks and Mountain Lion. The problem seems to happen with both. Our next step is ExtremeZ-IP

[bentoms]

@ndudley are your users working with Adobe products off the network?

[ndudley]

@bentoms They are, but it also happens with PDFs and Microsoft documents.

[bentoms]

@ndudley, on the Win2k8 server.. Have a look at open files when this happens.

I bet someone has the files or something within the folders open when these issues occur.

The Adobe apps do not support working off of removable media, & some can lock files even if they look to not have anything open.

[ndudley]

@bentoms The problem only happens when another user has a file open in a folder. For Example:

Test folder contains a folder called Nested Test Folder and Nested Test Folder has multiple files in it.

When a user opens a file (using smb on OSX) inside Nested Test Folder it locks it on the SMB server.

This means if a user is trying to Create a new folder called Nested Test Folder Archive and tries to move Nested Test folder into the Nested Test Folder Archive, it asks for an admin username and password - the file doesn't unlock when the admin password is entered.

If the user Force quits finder the file then becomes unlock and you can move things around, but this is definitely not a great work around for the users and we are stumped as to how to fix it. We have tried everything we can think of including using 3rd party tools like ExtremeZ-IP.

[bentoms]

@ndudley, from what you've explained the behaviour is in line with what we see.

Sometimes is stays locked, unless people quit the app that they opened the file from the server. Dream weaver is really bad with this.

We advise people to work locally & archive to the server.

[agirardi]

We are seeing the exact same thing after migrating to a Windows 2012r2 DFS. After some investigation it is folders and files that people are trying to rename, delete, or move while somebody is currently working in that directory. Altering the directory would wreak havoc on the other person using the file share.

I was also going to investigate stopping OS X users from creating .DS_Store on network shares as well.

[tcam]

defaults write com.apple.finder AppleShowAllFiles -bool TRUE
defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
reboot

might be a useful combo for testing.

[winningham_2]

This may or not apply to you, but reading the first post, it sounded similar to something we ran into and I used the below link as a reference.

https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammin...

OS X v10.4 and later implements SMB/CIFS-compatible access control lists (ACLs). Although individual users cannot set or alter ACLs, server administrators can do so. (Administrators can use the SMB server command line to manipulate ACLs, but only if both the client and server are bound to the same Active Directory domain.) However, enforcement of permissions is done only on the server, not on the client.

[tekniq305]

Has anyone figured out a cause/fix for this problem yet? We are having the same thing occur. Win 2012 File Server, Macs (10.8-10.9) files get locked and I sometimes have to go to Open Files on the win server and disconnect them. I was able to reproduce the problem when I would preview a file then close the preview and then try to rename the folder it was in. Curious if anyone has solved this.

[agirardi]

This is exactly the same problem we are seeing. Thank you for putting this succinctly. I can duplicate in the exact same fashion, but have not discovered a cause/fix.

[TrumpetMonkey]

I know this is ages after the problem....But I have a answer.

I came across this thread when I was trying to fix my own problem. Mac OS would force admin credentials to touch anything on samba. It also would show locked if samba was mounted anywhere else.

My server uses JBOD for its drive pooling. I found that the files on the drives (not samba but the actual drive) had new file ownership. This was deceiving because Samba reported a different owner making me over look it. For some reason samba shows file ownership of the person that logged in versus who actually owns the files (admittedly this will probably vary system to system).

My fix. unmount samba shares. Set ownership on all drives. remount. Problem solved.

Hope this helps good luck to everyone else.

[kerouak]

It's down to the fact that someone has something open right enough!

I checked a list and found 1 file open in a folder, it required admin when transferring etc etc. All other folders ok.

[tennsmith]

I have the same issue with 10.6, 10.8, and 10.9. I have pin-pointed it to finder not closing the SMB share. I can use openfiles.exe from a windows box to verify. Run in powershell ISE as administrator to copy paste into notepad for csv viewing. Then filter on username column to find the suspect file or folder that still has a session open.

Below the first query finds the open sessions and the 2nd one disconnects. This isn't a great solution, but it stopped me from wanting to pull out my hair or throw the iMacs out the window of a very tall building!

openfiles.exe /query /s <File_Server_Name>/fo csv /v
openfiles.exe /disconnect /id <FILE_FolderID> /s <File_Server_Name>

Openfiles documentation: http://technet.microsoft.com/en-us/library/bb490961.aspx

[rkovelman]

Not sure if you guys found your answer but to the OP this occurs because Apple and all their wisdom decided to have the Mac OS create preview files for all items contained within that folder. So if a user, even in list mode, is on the server their computer can lock the files, causing the other user to lose their privileges. You can fix this by going to the root of the share on the end user station and doing an apple-J and disabling preview.

Now you might still have an issue. Go back to the server and take ownership of all the files. After that reapply all the permissions. You should be good to go now.

[patrickmullen]

We found that we needed to give Delete access (under "Write" on ACLs) to the group (would work with individual users too) that were supposed to be able to change folder names.

This specifically occurred with us because we have a Deny permission in place to deny anyone not in the group from even seeing the folder.

Presumably, there would be a similar switch on Windows. I imagine it would handle this the same way.

[johnpowell]

@rkovelman When you say "go back to the server" do you mean navigate back to the network drives in Finder, or do you mean to actually log in to the server and make the permission changes from the server's OS?

Have you had any further file access issues since disabling preview? If not, do you know of a way to only disable preview for network drives?

[rkovelman]

@J.P. Yes, mount the server and go to the main folder or share. Then disable the preview and set it as the default option. 10.10 seems to be a bit better with this but not 100% sure yet.

[Mattthew]

@rkovelman

Can you explain what an "apple-J" is? I am trying to fix this problem but I am unfamiliar with this term.

Thank you.

[johnpowell]

The "Apple" key is referring to the Command key. It is to the left and right of your space on an Apple keyboard. Command + J is a keyboard shortcut to bring up the view options.

[Mattthew]

@J.P.

Thanks!

[macboy81]

Is disabling the Preview the only fix for this.

We have acronis access connect (extremez-ip) connecting our windows file servers to our design team all using macs but we have a lot of problems with moving files or renaming files. They can enter the password and it works but we want to prevent the password pop up box.

[rkovelman]

@macboy81 Yes but Extremez-IP should resolve this in of itself since AFP is understood at all ends, workstation and server. Apple's implementation of SMB is just awkward to say the least. If they are using AFP there should not be a password pop up box.

[macboy81]

they are using AFP but they seem to have this intermittently

[rkovelman]

That might be a permission issue on the server. I would go back and check the general Users group that is auto added and check the propagation. Sorry hard to say without seeing it.

[Proactis]

If you're looking to change the Finder view options settings for icon previews via a script, check out this thread:

https://jamfnation.jamfsoftware.com/discussion.html?id=2046#responseChild122072

[michaelhusar]

Found this one on .smbdelete - kudos to emc community
https://community.emc.com/thread/227240?start=0&tstart=0
http : //www.opensource.apple.com/source/smb/smb-759.40.1/kernel/smbfs/smbfs_smb.c
(...)
These .smbdelete files a OS X's way of deleting files that are still kept "open" by some process.
(...)
Simple repro with 2 clients.

1. Take a png or other image file and copy it to an Isilon SMB share from one Mac.
2. Open that file from one Mac (client 1) in Preview.
3. Open the same file in Preview on your other Mac (client 2).
4. isi smb openfiles list -v should show 2 IDs that have the same file open for read.
5. From client 1 go into the Finder and delete the file. Finder will not complain and the file will be deleted.
6. On Isilon, you'll see that the file has been renamed to .smbdelete<string>.
7. On client 1 close Preview. The .smbdelete file stays there.
8. On client 2 close Preview. The .smbdelete file remains.

And thus you now have an orphaned .smbdelete file that won't go away.

The .smbdelete file will go away if you close client 2's Preview app before client 1's, but there's no telling how often that will happen in reality.

[rgerman]

We also had the issue with a Windows 2012 R2 server. When a Mac opens up a a folder on a share on this server via SMB. Windows server is showing that it is open, under Computer Management, Shared Folders, Open Files, even if the folder is then closed. This prevents users from moving or renaming said folder and being presented with a prompt for an administrators password.

The only way to close the open files is to dismount it on the Mac.

Has anyone found a solution... Seems like Apple should have thought about this since they killed off AFP

[rgerman]

We also had the issue with a Windows 2012 R2 server. When a Mac opens up a a folder on a share on this server via SMB. Windows server is showing that it is open, under Computer Management, Shared Folders, Open Files, even if the folder is then closed. This prevents users from moving or renaming said folder and being presented with a prompt for an administrators password.

The only way to close the open files is to dismount it on the Mac.

Has anyone found a solution... Seems like Apple should have thought about this since they killed off AFP

[rgerman]

We also have this issue with our Windows 2012 R2 server used for shares. When a Mac opens up a a folder on a share on this server via SMB. Windows server is showing that a file is open, under Computer Management, Shared Folders, Open Files, even if the folder is then closed. This prevents users from moving or renaming said folder and being presented with a prompt for an administrators password.

The only way to close the open files is to dismount it on the Mac.

Has anyone found a solution... Seems like Apple should have thought about this since they killed off AFP

[rkovelman]

That is correct, and why we use ExtremeZ-IP. I wouldnt say AFP is killed off and SMB is not the answer as the SMB specific to the Mac was developed by Apple so a lot of what should happen does not. Deploying SMB to a workforce of all Macs or even some can cause issues, not to mention the quickness of SMB vs AFP is less to be desired.

[yadin]

For what it may be worth...
Just encountered this and it was rather baffling. Mac wanted admin to rename a folder. Windows said the item was in use, close it and try again. Neither of these was true of course. Yes looking at open file handles in the MMC on the server showed they were open, but that's innocuous and irrelevant, no files were open, just folders.

The REAL issue was an item down in a sub folder of that folder that couldn't be renamed, which also could not be renamed. In that case, it was due to a corrupt character in the file name (invisible on Mac, bullet dot on Windows). Once a new folder of the same name minus the bad character was made and everything moved, the bad one could be deleted on the server. Problem solved, all behavior normal at that point up through the parent items.

Not saying this is the only cause for this type of behavior, but something to be aware of.