Skip to main content
Participant
October 1, 2010
Answered

could not save because write access was not granted (Mac OS)

  • October 1, 2010
  • 56 replies
  • 429649 views

I keep getting the above error when working off of my xserve in photoshop. It is new in CS5 which we have recently upgraded to. Several people at my office are getting it. Sometimes it displays a random name with afp in front of it (I assume it is the temp name when photoshop is swapping out the new file for the old file.) It only seems to happen with psd and psb files. I have write access to the volume in question and it doesn't matter if I am the only one accessing the folder or not. I can save as and it seems to work; but it does delete the file.

Very frustrating. Anybody have any ideas? My IT guys are struggling with it, and one of them used to work on the Flash team as well as at Apple.

This topic has been closed for replies.
Correct answer Jeff-Adobe

Hi Criss,

I get what you write. I realize the issue may not be with you.

Sorry for talking past each other. If changing the code in PS to be more like other adobe apps is not an option I think only Apple can fix this particular issue we have isolated.

Might be worth a tech note from Adobe still since it is a pretty bad outcome of the issue as things are now that only seems to affect Photoshop and Xsan 3 customers.

As an end customer it's very easy to get the impression that this is a

Photoshop bug since the issue only occurs in Photoshop.

Once again if you want my help to isolate the effects of the issue I can help with access to our system to isolate.

I am sorry for my tone in last posts, issues like these are very frustrating but I should not let that frustration result in unfair comments here. (I would edit out the quark comment if I could).


Hi everyone,

The recent Mac OS X 10.8.4 released yesterday has specifically named the following fix:

  • Resolves an issue saving files to an Xsan volume from certain applications

referenced from this Apple KB article. http://support.apple.com/kb/HT5730

If you are still experiencing this issue, please update to 10.8.4 and then re-test in your environment. Please let us know if you are still experiencing issues.

The KB article also mentions this fix:

  • A fix for an issue that may prevent changes to files made over NFS from displaying
  • A fix for an issue that may prevent documents from being saved to a server using SMB

In general this OS update has a number of network save fixes in it that we recommend users try out.

Thanks,

Jeff

56 replies

Participant
October 14, 2010

relates to the problem but for cs4, might

shed some light

http://www.outsmartcomputers.com/2009/05/issues-with-version-cue-cs4/

Tai_Lao
Inspiring
October 14, 2010

Your link is broken. When you click on it, it begins with “http://http://www…

Let me try to fix it for you:

http://www.outsmartcomputers.com/2009/05/issues-with-version-cue-cs4/

October 14, 2010

Hello,

I'm going to have our engineers look into the behavior you are experiencing and fix it if its an issue with ExtremeZ-IP.

Group Logic has a dedicated maintenance engineering team ready to fix problems with ExtremeZ-IP. They will review all of the information posted on this thread.

You can help us find the cause faster if you can open a support case here: http://support.grouplogic.com/?page_id=39 We may ask for more information to help us find the problem.

Once we find the problem, if its in ExtremeZ-IP, we will notify anyone who has an open case what we have learned, the schedule for fixing it and work with you to test the fix once its done.  As you can imagine, some fixes take longer than others but consistently reproducing the problem is critical first step.

If the problem turns out to be outside of our control, we will pass along the information we to the appropriate contacts at Adobe, Apple or other vendor and assist them in any way we can to address the problem.

With your help, we'll do our best to help resolve this situation promptly.

- Reid

T. Reid Lewis
President
Group Logic, Inc.

Participant
October 13, 2010

For what it is worth, I get a lot of these errors and file deletions in my setup which is a snow leopard machine with a snow leopard xserve. I never got them in CS4. And I get both the .afpDeleted name as well as the correct name in the error dialogue box. 

October 13, 2010

There might be hope the files are still there!

While researching I found this out...

Go into terminal, to get to the directory where you want to look:

cd [then drag the folder into the terminal window]

and run: ls -la

This will show all files including "dot files" with a period at the front that Finder will not show

If you find one, you need to change the name and undo the hidden flag, here's how:

mv .afpDeletedxxxxxx newname.psd

chflags nohidden newname.psd

October 13, 2010

The following shots are of test files from a production server running Xinet Fullpress, I mention the extremeZIP article because it is the only seemingly solidly documented article on an issue that quite a few people seem to be having.

So I ran some tests to recreate the problem, because if it can't be recreated it's not a problem in the IT world I know because I am in the IT Dept at an advertising agency here in Chicago administrating over a 130 Macs… so that aside, here's a long winded run down of the tests

I've posted screenshots at:

http://picasaweb.google.com/116782194976328390062/PhotoshopFileSavingIssue?authkey=Gv1sRgCMK3xpaVrIfFgAE

And a movie of a Save action stuck attempting to save to .afpDeleted file while the source file is not on the server:

http://www.youtube.com/watch?v=5FgmaaPamvc

These are unlisted galleries and videos and will be removed when no longer needed

-----------------

2 machines are used for the test

Machine #1 is running OS X 10.6.4 and is browsing the folder with Finder

machine #2 also 10.6.4 with CS5 is saving to the same file at the moment computer #1 is browsing it with Finder and generating a preview

Most times, the file is deleted and replaced, Finder will "kick you out" of the folder when the file is resaved, or other times show no preview, the timing needs to be precise (yet we have users who aren't trying this on purpose at all and manage to have this happen to them!).

When a write error does occur sometimes it says:

A)

"Could not save "name" because write access was not granted" with the correct name used and the files remains.

B)

"Could not save "name" because write access was not granted" with the correct name used and the original file is gone but a .afpDeletedxxxxxxxx file is found in the directory via Terminal

C)

"Could not save "name" because write access was not granted" with the name .afpDeletedxxxxxxxxxx used and the original file is gone although the .afpDeleted file is found via terminal, it can be copied to a name that Finder will not hide, but it's hidden flags are set and 'chflags nohidden' needs to be run for it to appear in Finder

In scenario C, Photoshop will attempt to save to the .afpDeleted name with using Save even though the document name is being displayed properly in the Photoshop window. Using lsof it can be seen that Photoshop have the resource fork in use (only after the 2nd save attempt though), closing all open documents will still have this file in use, only upon quitting will it not be.

I wish I had taken a look at the .afpDeleted flags to see if it was locked or not during this, but lsof results of it being in use is pretty weird!

So here's some more puzzling evidence, thanks for your help.

Chris Cox
Legend
October 13, 2010

The .afp deleted files are not Photoshop's.

Those are from the AFP protocol, or the ExtremeZIP server code (most likely the latter).

October 13, 2010

Running Xinet Fullpress which uses the K-AShare for AFP protocol implementation... we also have the SMB protocol running on it as well, so I'll do the same test but with SMB protocol and see what happens.

Participant
October 13, 2010

t've had this occur at 3 different companies using  CS3 & 4. i'm an I.T idiot but was told it was something to do with version cue and the server. in all cases it was fixed outside the retouching studio so had nothing to do with the workstation. sorry cant be more specific but that might point you in the right direction

Chris Cox
Legend
October 13, 2010

was told it was something to do with version cue and the server.

Unless you're using VersionCue, it shouldn't enter into the problem (it isn't involved in normal file saves/opens).

More likely it was just an issue on the server.

Known Participant
October 1, 2010

We've been getting this at work too, sometimes various times during the day, sometimes it goes a couple of days without happening. The scariest part is that if it gives you that message and you close the file without saving it again, the file gets deleted and you loose the file. Very, very scary.

But we also found out that if you click ok on the message and save it again straight away (no need for a save as) it works fine.

I posted this a couple of months ago but nobody gave me an answer.

Andre

October 11, 2010

Apparently it's been around for a while... and it's pretty silly that it's not solved in 2010 by either Adobe CS5 or Apple's OS X 10.6.4 . I think though since this doesn't happen with any other files but Photoshop files that I've seem, the Photoshop guys need to look into this and find some new routines to call for saving and/or mitigating locks on files...  either way Adobe and/or Apple engineers should squash this lame bug, even if they are in some contention as to who's fault it is and simply serve their customers. Note: this bug is rearing it's head on Xinet Fullpress system that is running K-AShare for it's AFP stack, so it seems less likely to be an OS X filesystem bug but rather Photoshop's handling of file locks? Any Adobe engineers care to enlighten me and my speculations?

http://support.grouplogic.com/?p=1664

Symptom:

A Photoshop error occurs when saving a file to an Apple File Protocol (AFP) network share. Error – ‘Photoshop could not save “file” because write access was not granted’.

Cause:

When Photoshop saves a document, it deletes the current file, creates a new blank file with the same name, and then attempts to open the new file for writing. Finally, it writes the image being saved to the new file. If any part of this process fails, the original file is lost.

The most common way this error is triggered, is if one user is saving a document while a second user is browsing through the same folder where the document is being saved. The problem happens because when the Finder reads a file to create a preview, a write lock is placed on the file so that it cannot be changed while it is being read. Due to this write lock by the second user the first user is unable to save changes to the file that they just created. Although the timing has to be just right, with many users browsing the directory, the issue can occur frequently.

This error is reproducible against any file server using either AFP or SMB – it does not specifically relate to ExtremeZ-IP. Theoretically the same error can occur even when saving a file locally. You can also trigger the error by having a second Mac browsing for a file in Photoshop or another application’s open dialog.

Workaround:

There is not much that can be done other than reattempting the save, using “Save as” with a unique filename, or saving locally and then copying to the server.

It is a good idea (although maybe not feasible depending on the environment) to avoid having more than one user working on files in the same folder. Photoshop has a number of problems when saving over a network and this is just one you may encounter. Adobe specifically does not support saving over the network. Adobe has a product called Version Cue specifically for managing shared files and file versioning.

Fix:

There is no fix at this time. See workaround

Participant
February 24, 2011

I too am experiencing this with Xinet.

Are you serving Xinet of a MAC server, I cannot remember...

My current theory has to do with POSIX permissions. If you are managing server access using ACLS from other apps, inheritance is like CRAP on OSX for directories, even with a mask. File inheritance works great, which causes an issue with who owns a file once a new directory is added with incorrect permissions.

This is a theory that I am testing against right now.