The problem: Under Mountain Lion (10.8.3) I cannot create new files or save changes to a particular share, which is running Lion (10.7).

I can connect to the shared Mac on my local network (in a business location). I am the administrator of both machines. The remote computer I'm connecting to has several shared drives, and these problems affect all of them.

What I cannot do on the shared drive

  • Create a new file
  • Save (re-save) an existing file I've opened

What I can do on the shared drive

  • Create a new folder
  • Delete folders and files
  • Rename folders and files
  • Move folders and files

Additionally, the following quirks apply:

  • I can view the full file system on the remote computer, including system files; in other words, I am successfully connecting as an administrator user
  • If I try to drag and drop a file from my computer to the remote computer, I get a dialog that says "Finder wants to make changes. Type your password to allow this." This is strange, nonstandard behavior for an already-autheticated admin user doing a simple copy operation to the remote machine.
  • If I type my password and continue, I get another dialog that says "A newer item named [file name] already exists in this location. Do you want to replace it with the older one you're moving?" This is a bogus error, because a newer version of the file did not exist on the remote server. If I click "Keep Both", Finder seems to hang, but it actually begins to create tens of thousands of zero byte files on the remote server: file name-1.png, file name-2.png, etc., all the way up to file name-30000 or so if I don't stop it. However, if I click "Stop" instead of "Keep Both", it cancels. If I click "Replace" it creates a zero-byte file with the correct name, and then gives an error that says "The operation can't be completed because an item with the name "" already exists."
  • Console reports an error when I try to copy to the remote machine: Application App:"Finder" [ 0x0/0x25025] @ 0x0x7fc4ea63e640 tried to be brought forward, but isn't in fPermittedFrontASNs ( ( ASN:0x0-0x4d04d:) ), so denying. I've also seen this error, but it doesn't happen every time: WindowServer[120]: [cps/setfront] Failed setting the front application to Finder, psn 0x0-0x25025, securitySessionID=0x186a5, err=-13066.

I have tried the above using a computer running Lion, and had no problems. This issue only affects my new iMac running Mountain Lion. In this case, Mountain Lion was factory installed. However, I imported my user settings from my old Mac Pro during the install process.

This problem is very similar to one reported by another user at Network share permissions problems in Mountain Lion, but there are some differences, so I asked a separate question. Among other things, there are no applications on my system that "ignore the problem" as in that user's case.

What I've tried/verified:

  • I routinely repair permissions on my iMac, so I'm sure that is not the issue.
  • I have verified that the files/folders have the correct sharing permissions.
  • Other uses, including a Mountain Lion user on another machine, can copy/save files to the remote computer.
  • Deleting the Finder preferences file (~/Library/Preferences/com.apple.finder.plist) did not help.
  • Logging is as the Guest user on my local machine, I could connect and copy files to the remote computer. This suggests the issue is limited to my local user account.
  • If I use Terminal to do the copy, I get an "Operation not permitted" error. It creates a zero KB file on the destination server, as before. However, I discovered by accident that if I immediately do the same command line copy operation again, without deleting the zero KB file, it successfully copies. I guess for now this will be my workaround.
  • The fPermittedFrontASNs error message can be an indication of the 'Gatekeeper' mechanism getting in the way. Try turning off the 'Gatekeeper' mechanism by going to System Preferences > Security & Privacy > General tab and allowing applications to downloaded from 'anywhere', then try the file copy again. – IconDaemon Apr 4 '13 at 18:31
  • I tried changing that, but when I do I still experience the problem described above, in that the file doesn't fully copy. I don't get the fPermittedFrontASNs error for the Finder, but instead I get an fPermittedFrontASNs error for Console: coreservicesd[69]: Application App:"Console" ... tried to be brought forward, but isn't in fPermittedFrontASNs ... so denying.. – Michael Apr 4 '13 at 19:45
  • Was Console.app running at the time? – IconDaemon Apr 5 '13 at 11:42
  • Yes, Console.app was running while I was troubleshooting the problem. – Michael Apr 8 '13 at 13:10

After spending maybe 12 hours or more troubleshooting this issue over the past month or so, and realizing it was isolated to my user account, I decided to recreate my user account from scratch. This has solved the problem, and I am now able to connect to the remove server and add/edit files without difficulty.


I have similar messages. I suspect this is an Access Control List problem. In Terminal, enter "/bin/ls -le /Volumes" to see if there are ACL entries.

ACL entries can be cleared --sometimes-- by "/bin/chmod -N ." for the current directory. "sudo" may be required also. See "man chmod" for more info on Access Control List entries. These were added in 10.4 to match capabilities in Windows Server. But I have found, for single users, they create more problems than solutions.

  • There are ACLs on the Volumes I'm having trouble with. However, we have a multi-user environment, and the ACLs were added to prevent problems we were having with permissions. It was working well until I upgraded to OS X 10.8. The problem appears limited to my user account, rather than a problem with ACLs themselves. – Michael Apr 30 '13 at 15:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .