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

[sean-gloss]

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.

[C42DCreative]

also for the record, normal guys like me have no idea what "API's" are...

[Chris Cox]

Sorry, I use some terms so often I forget that they're sort of specialized.

API = Application Programming Interface - how an application calls into the OS or OS libraries to get things done.

On your server problem: what OS version are you using, what protocol are you using (SMB, AFP, etc.), and what kind of server (version of that would be helpful, too)?

[C42DCreative]

Setup:

Mac mini (fall 2010) running mac os X server 10.6.4

protocol? not sure. I share files using os X server's server control panel, where you turn on sharing and select folders to share.

We share a common area on the hard drive with jobs, materials, files etc. All clients have read + write abilities (obviously)

the client machines are all iMac 27" running Mac os 10.6.4.

[Chris Cox]

If you aren't specifying a protocol, then it's probably AFP.

And we've tested with that kind of setup, many times, without any problems.

Guess we'll take another look.

[C42DCreative]

Well, I am willing to jump in and help out if needed, send more info etc.. Russel can vouch for me I am really not a bad guy when I am calm and collected. 😉 

Do you have any other advice on what might lead to that kind of error? any other software on the client or server end that could be throwing things off?

[Chris Cox]

I don't know for sure of any other software that could cause it.  But spotlight running on the server, or bad anti-virus might cause similar symptoms - that's all I can guess right now.

[Martin Orpen]

Check your Photoshop Edit Log.

Both Macs running CS5 that have this problem on our network are registering the save with the incorrect file name in their logs:

http://lists.apple.com/archives/colorsync-users/2011/Jan/msg00131.html

Can't offer any explanation as to why Photoshop is doing this because it is a rare event considering how many files we're saving.

My guess is that the remote machine is busy and that, if Photoshop can't get the information it needs within a set time limit, it screws up. The reason for the guess is that ISTR that when throwing this error, Photoshop would also sometimes show Save As dialog boxes with empty file listings or file listings that would appear with a noticeable time lag.

[Chris Cox]

As for the filename -- that's a temporary file, the first part of the safe save.

Then Photoshop calls an OS routine to swap the temp and the file being replaced.

The OS can rename the file as part of the process.

Photoshop doesn't have a timeout like that.

And the save dialog is an OS dialog, not controlled by Photoshop.

This is sounding more and more like another OS bug.

[Martin Orpen]

But why is Photoshop making a log entry saying that a file is saved with a temporary file name? That strikes me as odd because it looks as if Photoshop is treating this incorrect behaviour as an ordinary, valid save operation.

The only thing that the user sees is the error dialog stating that it doesn't have permission to write/overwrite a file with the same temporary name. When what has actually happened is that Photoshop *has* already written the hidden temporary file and then either it or the OS has deleted the original.

Unfortunately it's difficult to isolate the problem because it only started happening last year with two new CS5 installations on new Mac Pros running 10.6.5/6. On older Macs we are still using older versions of Photoshop and they've never exhibited this behaviour.

Thinking about it further I'm certain that this rogue behaviour also produces Save As dialog boxes where the both the file list and the file name fields were both empty -- meaning that either Photoshop or the OS (or both) had lost any reference to what the file should be called and whether it already existed in the destination folder.

If this were just an OS bug then I'd expect to see it happening with other applications -- but honestly cannot recall any occasions when this happened.

I did notice that CS4 would often refuse to save files to both remote and local drives if you mounted/unmounted other volumes (not those that you were using) while working on an image.

HTH

[Chris Cox]

The only thing that the user sees is the error dialog stating that it doesn't have permission to write/overwrite a file with the same temporary name.

Yes, because that is the error that the OS returns to Photoshop.

When what has actually happened is that Photoshop *has* already written the hidden temporary file and then either it or the OS has deleted the original.

Photoshop wouldn't delete anything until the safe save is completed. We're constantly looking for problems and reporting them to the user and trying to avoid data loss.  That's part of why this looks like an OS bug.

Thinking about it further I'm certain that this rogue behaviour also produces Save As dialog boxes where the both the file list and the file name fields were both empty

And, again - that might be true, but it would be further evidence of an OS bug because those dialogs are provided by the OS.

You probably would see it in other applications, if they called the same set of APIs that Photoshop calls.  But as we've found - they don't.  Photoshop seems to have been the first application to use some of the Cocoa APIs (that, or other applications didn't notice and report all the bugs in those APIs).

Over the years, we've had reports of this same error in many versions of Photoshop.  But so far it was always traced to problems with the file server.  When the file server software was updated (or replaced), the errors went away.

We'll investigate this again -- but we've never reproduced such a problem with the file servers (many versions, many brands) here at Adobe.

[Martin Orpen]

Thanks for looking at this Chris. I can appreciate the difficulties, the reason that we are saving to a shared volume on G5 is because our XServe has developed a fault and it seems pointless bothering to repair it now that Apple decided to knife us business users in the back. They've forgotten who it was who kept them alive during those lean years before iPods, iPhones and iPads

We had this problem occur twice more today and to try and narrow things down here are some notes:

1. Photoshop CS5 is running on a dual Xeon Mac Pro with 10.6.6

2. The shared volume is on a G5 (4x 2.5 GHz PPC) running 10.5.8

3. The connection between them is Gigabit ethernet and an HP ProCurve Switch

4. This is vanilla AFP, ordinary file sharing on 10.5.8 -- no third party server software

5. No other users were accessing the same files and folders when this happened

6. Photoshop's Edit Log doesn't register the problem when the warning dialogue appears -- the log entry only appears if you cancel the dialogue and then try and Save again. The second save still fails.

7. Save As works without a problem -- even if you save into the same directory and use the original file name. There are no warnings about overwriting because the original file has already been deleted.

8. Locating the lost images is easy from the command line using "find . -name ".afpDeleted*" and they work fine if you rename/mv/cp etc.

This problem started for us as soon as the first new Mac in point 1 arrived -- we'd never seen it before. Another similarly specced Mac Pro has the same problem.

HTH

[Chris Cox]

because our XServe has developed a fault and it seems pointless bothering to repair it now that Apple decided to knife us business users in the back.

Yeah, our build and automated testing people can commiserate.

Thanks for the details.

[Martin Orpen]

Thought I'd try and recreate the problem last night by taking an image that had previously failed to save (156MB PSD) and forcing a continuous edit/resave loop using an AppleScript. Same host Mac and server combination as before.

Arrived at work this morning to find that it has carried out 1,249 saves without an error...

So I'm still assuming that the target disk has to be busy or communication interrupted in some way for this error to occur.

[j. scriba]

Since I have next to 10TB of photos and videos to work with I'm keeping my stuff on a raid system in my basement. The raid is connected to a Mac Pro (running OS 10.5) which shares the volume via afp.

I'm the only user on my "network" using the files from my desktop MacPro (currently using OS 10.6). Ever since I've been running this setup (about three years) I keep having this "write access not granted"-problem when using Photoshop's "save as"-command.

This applies to Photoshop CS3 and CS5 (I skipped CS4) as well as all OS-combinations from, say, 10.3 on desktop and server. No other software I'm running (like InDesign, Final Cut, Logic, whatever) ever gave me this error.

Typically, when I start a Photoshop session saving works a couple of times when I save various iterations of a file under different file names. Then, once the problem pops up Photoshop will refuse to write any new files to the server and I have to resort to saving to a local volume. Restarting Photoshop usually allows me a new couple of saves.

I can definitely see this behavior on a daily basis.

As I can exclude any other users from accessing the file or browsing the directory (as earlier posts suggest) the only other processes that might interfere might be open finder windows on my own desktop or background activities such as Spotlight indexing or whatever.

Someone suggested such a problem may be related to a bug in the raid file system. I know the possibilities are endless. Still, it's a fact that somehow only Phototshop managed to cough on whatever problem is behind this.

I think you are saying that Photoshop calls Cocoa APIs that InDesign probably doesn't?

Well, if that particular API is buggy on Apple's side, why are you insisting on using it if other solutions exist that seem to work?

[Chris Cox]

Well, if that particular API is buggy on Apple's side, why are you insisting on using it if other solutions exist that seem to work?

Prior to Photoshop CS5, Photoshop used the older Carbon APIs the same as InDesign, Illustrator, etc.

Photoshop CS5 now uses the Cocoa APIs and updated several APIs for handling file permissions and parts of the safe save copy mechanism.

The fact that you've had the same problem with Cocoa and Carbon versions would indicate that the fault is more likely in the server protocol or OS.

And if we could ever get this to fail on our own servers, we'd have more information.

But we have never gotten this to happen except with some third party servers that had a clear bug in them.

We'll do more testing and see what we can find....

[Widowsoft]

Hi

One of my customers had same issue they run Xserve Raid SL Server. and use CS5

used terminal and noticed the permissions of the files were the POSIX permissions which did not relate to the Login authorization of ACL's gave posix owner read/write and appears OK  now.

What I ment to say was the POSIX permissions were read only . ODD  but that seems to have sorted for now.

[Martin Orpen]

Yeah, the permissions issue is confusing because Photoshop *should* be able to overwrite the hidden temporary file anyway... all it should do is warn you that the dot prefix isn't a good idea.

What exactly were you seeing with the ACLs?

All of the .afpDeleted* files that litter our server have identical permissions to the ordinary working images in the same folders.

[Martin Orpen]

Hi Widowsoft.

We had this error happen again today so I asked the operator to hold off responding to the warning dialogue and checked the permissions from the Mac that they were saving to.

Checking the directory using ls -le I found ACLs appearing on all the files and folders in the directory. I wasn't expecting any because we're not actively setting them.

Later checks on the same directory show no ACLs.

I checked the Mac and find that Time Machine is set to back up the drive that is being saved to. I couldn't see any other process running that would be likely to impose ACLs -- so maybe Time Machine is the culprit?

It's the same drive that I tested with 1,500 saves last night without any errors so maybe the timing of the save is critical and this is why it seems random -- and that some users can hit save again and it works while others are unable to save at all?

Got any suggestions as to how we can isolate this problem? The only time I've had to tinker with ACLs was to lock down Joomla on our Linux web server...

[Chris Cox]

Yes, it's possible that TimeMachine is involved.

[C-S-S]

Hi Chris,

Im having a similar problem. My studio is set up with 30 retouchers using Photoshop CS5 and Snow Leopard and around the same number of photographers with the same OS and a mix between CS5 and CS2 all Connecting to a windos server via SMB.

We work on approximately 1500 files per day and only ever encountered this error message rarely. Over the past few days it's been happening constantly. Our IT department have no idea how to solve it or create a workaround. Other than to say we'll be switching to a mac server and connecting via AFP at some point soon which will solve the problem?

Three things that are confusing me:

• Why is it that this error has started occuring so frequently, is there anything I can check?

• Why am I able to open up a file, make adjustments, then subsequently have other retouchers do the same things while the file is open and the message doesnt appear, this seems like an inconsistent error..

• We can detect which user is supposed to have the file open, but more often than not when we look at the machine, the file was closed some time earlier. Is this caused by the file lock taking longer to release due to the SMB connection?

Is there any work around you can suggest or way to stop this happening, because its having a massive impact on the ability to hit deadlines and causing all sorts of workflow and DAM issues.

Many Thanks

[Chris Cox]

"write access not granted" warnings are just part of what we're talking about here.

That usually means that some other user, or process, has the file open on the server.

Opening a file doesn't lock the file -- we only use the file while reading it into memory, then let go.

The file should only ever be locked while actively reading or writing it -- but some other applications keep the file open and locked by mistake.

And some OS utilities (AV, thumbnailing, backup utils) can have the file open longer than expected.

We don't know the cause.  It's just an error returned by the OS, which we pass along to the user.

We have no way to know what process, user, etc. has the file open -- just that we could not get write access because the file was busy.

Running a clean server helps (get rid of the extra processes).

But if there is a bug in the OS file protocol stack - that's harder to avoid.

And, again, this sort of problem is one of the reasons we say not to work from a server directly.

[C-S-S]

Thanks for the response.

Am still slightly confused as to why im able to open a file up, then others do the same and save over the image whilst its still open on my screen. I'd expect it to be an open/shut issue; where Someone has the file open, you cant save over it? From the sounds of it this isn't the case?

I realize that Adobe has never supported working off servers directly, but with a workflow dealing with anywhere up to 8000 files per week and the need for constant open access to the files, is there an alternative you can suggest?

Thanks again

[Chris Cox]

The file is only busy in between you hitting the "open" button and the document appearing on the screen. After that, you are working on something in memory and the file is not being used until you hit "save".  The key is: the document in memory and on disk are 2 different things, only related by history (and I don't mean Photoshop's history feature).   Otherwise you would never be able to get thumbnails, backups, or multi-user situations to work at all.  We do a lot of testing to make sure that we hold the files open as short a time as possible.

Copying the file to your local machine, then copying it back is much, much safer.

Or using a file management system of some sort (asset management, SCM, etc.).

[C-S-S]

So theoretically, The only way for this error to be blamed on two machines having the file open at the same time, is if you try and save whilst someone else is trying to open or save. Or an application other than photoshop i.e C1 or finder is using the file.

The fact that we're seeing this error about 300 times a day must be due to a network issue as its very unlikely for two people to be performing the same actions on the same files at the same time..

Another error that often appears before this one; makes refernce to the disk image beig changed since the file was opened, although nobody else has worked on the file.. Very random!

Sorry for all the questions, essentially im on Adobe's side, but my IT department are saying photoshop is the problem not the network..

Thanks

[Chris Cox]

Two machines trying to open or save at the same time is how we normally expect this to happen.

Other applications sometimes have a bug that holds the file open too long.

Seeing it that often probably means an issue on the server, or with the network protocol code in the OS.

Another error that often appears before this one; makes refernce to the disk image beig changed since the file was opened, although nobody else has worked on the file.. Very random!

If it hasn't been touched, then that means it was modified on the server, or that something is returning the wrong date/time stamp for the file (server or OS code).

Sorry for all the questions, essentially im on Adobe's side, but my IT department are saying photoshop is the problem not the network..

Lol. Your IT department needs a bit more experience.