Skip to main content

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?

@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.


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.


@J.P.

Thanks!


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.


@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.


they are using AFP but they seem to have this intermittently


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.


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


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.


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


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


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


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.


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.


FYI:

We posted about this in our blog:

Mac Bug Connecting To Non-Apple SMB Shares

We filed a bug with Microsoft & Apple enterprise support and it was found to be a Apple bug and is rumored to be fixed in macOS High Sierra. I would recommend testing the macOS High Sierra beta/GM or wait until the official release on Sept 25th and test again.

Note, we do not see the issue with Apple Server SMB shares.


God Bless you @uurazzle

razzle dazzle!

For the record, we've been having this issue for years. Definitely an OS X/Apple root cause/problem.


My two cents here. I've been using Univention Corporate Server which uses Samba 4.6.x for it's shares and as an AD server. I've found that on the Linux side of things I needed the VFS objects of Catia and Fruit. You have to enable extended attributes for each share too. It for the most part works on our Yosemite through High Sierra machines. Since enabling these options I've noticed server load go WAY down. I also disabled ACLs so that it's just simple UNIX permissions since we are an all Mac shop. Now if I can just keep the browsers from periodically crashing.


Hey everyone,

I solved this issue by following various instructions.

First, on the macOS client, issue the commands found in Adjust SMB browsing behavior in macOS High Sierra 10.13.

Then, on the Samba server, use the configuration https://gist.github.com/raspi/9986175. Note that I only used the...

[global]

...section from that config. And obviously tailor the config to your own environment.

The Samba server I use is a FreeBSD 11.1 machine with Samba installed via the pkg(7) command. The package is samba47-4.7.4_1. But any OS should work as long as Samba is properly configured. I use user type Samba security and created the Samba user via this command:

sudo pdbedit -a username

Ideally use the same username / password as the one from which the macOS client is going to access the Samba share.

Note that I did have to reboot the macOS client to make sure it worked properly. Otherwise, the Finder would refuse to unmount the SMB volume or would throw an exception saying that the file(s) were already in use. Which was pure BS.

HTH,

David


ndudley, did you ever find a solution to your problem? I work in an environment that uses iMac computers running OS 10.9.5 and they are connecting to a Microsoft 2016 Server via SMB. The issue we are exhibiting is similar to what you were experiencing in that the Mac creates multiple files on the server side and then fails to release them once the customer on the Mac side closes the files thus prompting the customer with a file in use error window. Any help is greatly appreciated


I am having a lot of problems with Excel and SMB shares on our Windows 2012 R2 Shares server.

I am ready to either switch the effected users to PC's or put ExtremeZ-IP on the server.

Problems include...
• Open Files - Files locked because they show as open on the files server until the user un-mounts the volume
• .smbdelete file - appearing and causing issue when users try to save xlsx files
• Errors - users cant save xlsx files but can save xls files
• Ghost folders mutiplying every time a user saves certain excel files. Example "every time a user saves an excel file called test... a folder is created test.xls.sb-141gbdb4949-zxlu8w" The next save will create another folder but the charaters after xls.sb- are different.

I have to say... Mac SMB and Windows SMB do not play well at all. I have tried multiple fixes to no avail. Has anyone found 100% success fixing these issues. All my Macs are on High Sierra.

Thanks,
Ray


@rgerman I use Acronis Files Connect and have so for years, which allows you to share out shares as AFP. No issues. I have not tested this part out, but supposedly 10.13's SMB config is better than all previous versions. Might want to play with that.


Apple doesn't play well with others period, they play by their own think different rules.
That said, have not seen the issue you're reporting @rgerman outside of one caveat. If people on Mac use cover view, having a file selected or previewed in any way is the same as having it open. We found this a couple years back and had to advise all users never to use cover flow because of that issue.


Extreme z - ip resolves the issues, however , if you grant read/write access to the . Temporary items hidden folder at the root of the share, that shld resolve it also.
Its down to the cached fkle excel creates. You wouldnt have issues saving it as an non xlxs file..
Gluck!!


I still get errors, even when read/write is granted to the invisible .Temporary Items folder. The issue seems to be tied to .xlsx format. Oncve the error comes up, the user is unable to save the file to the server or even locally. The only way to save the file is to change the save format to .xls


I loaded Acronis Files Connect; formerly ExtremeZ-IP on our server and connected the users via AFP. Since, then... I have not had any reports of the xlsx issue. Seems to be the only solution until Apple fixes the SMB issues.