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.

[Winterfield2817]

I have this same problem (just upgraded from CS5 to CS6) but I'm on a solitary Mac at home, no server, no shared files, no source control, just a standard home network. Save-as does not work, flattening does not work, in fact nothing I tried works. I continually get the "can't save this file because write access was not granted" error message.  CS5 worked fine. My next step will be to open a support ticket.

Until I can figure this out, I won't be able to use PS CS6 at all.  What's up with this?

[j. scriba]

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

I can hardly believe you are saying this.

I'm sure you're aware of the fact that these days people work on thousands of pictures a day in a collaborative environment.

No matter who's fault this is, the fact is that no other program I use exhibits this issue.

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.

You're probably right that something is wrong with my server. Still, no other program I use ever exhibits this problem.

The fact that numerous other users in various different environments suffer from this issue makes me wonder if your approach is adequate.

If there are tons of customers out there in a world with imperfect server structures - wouldn't it make sense to use a file handling procedure that deals with these imperfections?

Obviously most other programs can deal with it, Photoshop can't.

[Chris Cox]

Still, no other program I use ever exhibits this problem.

Most other applications don't do as much error checking and reporting as Photoshop.   Photoshop is telling you about errors that most other applications would simply ignore.

It's not a huge number of customers with server problems -- many people are using network servers without any such problems.

And our file handling is supposed to deal with this sort of problem, but somehow an OS or server API is not doing the right thing.

Yet when we test it on our huge mix of systems, everything works fine.

[Todd_Shirley]

Chris Cox wrote:

It's not a huge number of customers with server problems -- many people are using network servers without any such problems.

I think the correct way to put it is"not a huge number of customers REPORT server problems". Like many in this list, I've been doing this for a long time, and every environment I've worked in and every peer or IT person I've ever spoke to about this has encountered similar problems "working off the server" with Photoshop. Most companies just do what we do and what Adobe recommends: copy files local to work on them and then copy them back to the server when done. We don't waste time reporting known bugs to Adobe. (or writing lengthy rants in forums )

ID and AI don't do as much error checking.  We know that.  Many other applications don't even try to do a safe save.

What does Photoshop do differently: check for errors, tell the user about errors, and do a safe save to minimize file loss.

Oh, and we have changed our saving code several times over the years -- yet the errors persist on some servers (but never ours).

OK, why don't these other Adobe products do much error checking? And you call it a "safe save", but many in this thread report LOSING data. How is it that doing MORE error checking and doing SAFE saves results in data loss, but ID and AI do neither and users experience no data loss or problems?

Message was edited by: Todd Shirley

[Chris Cox]

it seems like Adobe should send an engineer out into the real world to one of the thousands of businesses who experience this problem on a regular basis and try to figure out what they are doing wrong.

We have, repeatedly.  See my previous post.

We've even brought a few servers in house to analyze - same results: server issue.

I think the correct way to put it is"not a huge number of customers REPORT server problems".

Which is why we ask customers how they work, and if they have experienced any problems.  Many do work directly off the server, without problems.

Others have problems with the server, then solve the server issue and continue to work without problems.

considering how this server issue has been a known problem for at least 10 years

That's just it:  this is not a known bug in Photoshop.

The only known problem is "networks and servers are difficult to setup, maintain and troubleshoot".

If there is a bug, we'd love to find it and solve it.  But we've been chasing this sort of problem for years, and always finding the problem is external to Photoshop.

[Martin Orpen]

Chris, it would be helpful to me if you could explain exactly how the Photoshop Save works.

I cannot understand how any application would end up reporting that it couldn't write a temporary file -- when it already has.

Or how, if it can't write the temporary file, it still manages to allow or cause the original file to be deleted?

Photoshop *is* exhibiting peculiar behaviour here no matter what the underlying cause of the problem is...

[Chris Cox]

Safe save:

write to a temporary file

swap/replace the temporary with the original

The error seems to occur when moving the temporary to replace the original file.

The only way the original could be deleted is if the OS or server mangles the swap/replace operation.

[Martin Orpen]

So the .afpDeleted* file that is all that remains your cherished image on the remote disk is what exactly?

If it is the temporary file, then it *has* been written -- so the dialogue box is incorrect.

If it is the deleted original then why does the dialogue box show the temporary file name and not the original file name?

If you can't recreate this issue in-house then perhaps it might be worthwhile giving customers who are suffering a modified version of PS which dumps more information to the dialogue box or console during the Save operation?

[Chris Cox]

So the .afpDeleted* file that is all that remains your cherished image on the remote disk is what exactly?

We don't know.

Again, we've never been able to reproduce the problem.

We are already trying to connect with some customers experiencing this problem to get them an instrumented copy of Photoshop.

[Martin Orpen]

The problem has occurred again today so I can now confirm that the .afpDeleted* file is the original image.

I can also confirm that Time Machine wasn't involved as this happened around 40 minutes after the last backup.

Again, I don't get how this error can be blamed entirely on the OS?

There are no other hidden or temporary files at this location so it appears that Photoshop is NOT safe saving *anything* (or is both saving AND the deleting the new data) before flagging the original file for deletion.

And how on earth does the new name of the original file, now flagged for deletion, end up in the warning dialogue in PS?

Confusing

[Chris Cox]

The problem has occurred again today so I can now confirm that the .afpDeleted* file is the original image.

That tells us something.  That means that the OS API to replace the original file failed partway through.

(otherwise the original would still be in place)

Again: if the OS and server were working correctly, this should be impossible.

Photoshop wrote to a temporary, called the OS to replace the original with the temporary, and the OS failed partway through that operation.

If the save failed at points where Photoshop has control then the original would be intact, both files would be there, or the newly saved file would be there.

OK, now we have more information for our investigation - thank you.

[IT Temp]

okay... just wrote a lengthy reply and Adobe forums responded with "Page not found" and pressing back in browser history returned me to a blank reply slate... What an awful way to handle forms... Now I shall to remember to Cmd+A -> Cmd+C before submitting.

Anyways... a short summary:

We've started seeing this on one workstation this week. To me it looks like it may have something to do with permissions on the PS executable folder vs user system rights vs user share rights. In short ACL conflicts.

I'll be digging into the ACLs in the morning.

Do you want us to run a debug logging PS CS5? It would also be possible for you to get a peak via remote if you'd like some real world hands on with the error

[syuroff]

Like Martin, I too have a team of designers and production staff who would be willing to try a version of Photoshop with additional debug code in hopes it might help understand this issue.  We're seeing it on CS5, running on OS X.6.5 and X.6.6 on MacBookPros and Quad core Xenons, writing to an Xserve running 10.5.8, via Apple native AFP.

One thing that caught my eye in this coversation is the idea that backup software could have the file open and cause a conflict (#46).  I use CrashPlanPro for backups, which will be backing up changed files multiple times/day.

To others seeing this: what backup software are you using, and could it potentially have a file marked as open while the backup occurs?  Might NOT having backup software intalled on Adobe's test servers be part of why they've not been able to reproduce this?

[Todd_Shirley]

I have to agree with j. scriba and others who point out that this problem or similar errors occur across different versions of photoshop and different kinds of servers, but not at all with any other programs. I've worked in multiple shops over the last 20 years and it's always been gospel that "you can't work off the server" with Photoshop, but somehow this is never a problem with any other program saving files.

It seems exceedingly odd that no one at Adobe has ever been able to reproduce this problem, and yet the official recommendation is to not work off servers and to only work locally. Obviously this has been going on for years and Adobe has probably heard thousands of complaints, and yet never able to reproduce it. That's just some kind of amazing luck. I'm sure it must have occurred to someone at some point to go out into the field and see if they could figure out why it happens to so many users in so many different environments, right?

Let's think: why does this never happen with InDesign or Illustrator files? Why can't Photoshop emulate these other widely used Adobe products in the way it saves files? Clearly it is doing something different, but why? What is so special about Photoshop's save protocol? Sure, it may very well be a "bug" in all these server configurations, but the fact that it keeps recurring over the years would indicate that there is SOMETHING about how Photoshop saves files that's, well, a little weird. Right? And why exactly can't Adobe change it?

Here's an analogy. We release jobs to printers for our clients all the time, typically InDesign packages. We spend a lot of time preflighting and checking to make sure everything is in order. Sometimes things don't print correctly, and sometimes it is our fault and sometimes it is the printer's fault. Either way the client isn't happy. Even when it is clearly not our fault, we examine our workflow to see if we could make changes that would reduce the chances of errors. We change our "product" to accommodate other vendors' "bugs". I guess if we were basically the only prepress vendor in the world (or at least the dominant one), we could just say "it's the other guy's fault, deal with it". But even then, we'd rather have happy clients. Wouldn't Adobe rather have happy customers?

[Chris Cox]

It seems exceedingly odd that no one at Adobe has ever been able to reproduce this problem, and yet the official recommendation is to not work off servers and to only work locally

We know that server problems exist.

We've seen customer having problems, and how long it takes them to find the cause and fix the network or server issues.

So we should say: "In a perfect world you can work on a network server, but your world probably isn't perfect, so don't do it or you'll end up regretting it."

And yes, we've only been able to reproduce similar issues with servers that had a known bug in them (mostly third party).

Yeah, we've gone out in the field, visited customers -- and found servers with known problems (old versions, misconfigured, faulty hardware, etc.).  Once we found a new bug in AppleShare (and Apple got a patch out pretty quickly).  Once those problems were removed, everything worked reliably.

ID and AI don't do as much error checking.  We know that.  Many other applications don't even try to do a safe save.

What does Photoshop do differently: check for errors, tell the user about errors, and do a safe save to minimize file loss.

Oh, and we have changed our saving code several times over the years -- yet the errors persist on some servers (but never ours).

Many, many times we have worked around OS and server bugs.  But we have to know about the bug, and it has to be something we can work around.  You can't always work around the OS bugs (like low level memory and file IO code).  In this case we can't work around what we don't know about and can't reproduce.

We are trying to do the right thing for our customers, otherwise we would have given up on this issue a long time ago.

Think about it: you keep reporting a problem that looks like a bad server config, we keep testing and never finding a problem -- shouldn't we have concluded that it's all in your server and given up?

Again: we are working hard to do the right thing for customers.

As of right now, we have no evidence whatsoever of a bug in Photoshop.

But we are continuing to investigate.

[j. scriba]

ID and AI don't do as much error checking. We know that. Many other applications don't even try to do a safe save.

What does Photoshop do differently: check for errors, tell the user about errors, and do a safe save to minimize file loss.

May I suggest that you simply add an option in Photoshop file handling settings like:

a) use safe saving (may block saving with faulty servers)

b) use standard saving (may lead to file loss with faulty servers)

This way, you can still tell users that whatever problem they encounter will be their server's problem and you strongly suggest working off local drives.

And many users will opt for a mechanism that so far has worked great for them in ID, AI and other software.

After all, you let users even chose tile sizes, cache levels and other fancy stuff under Photoshop's hood. Why not such a fundamental setting?

You won't get any more complaints from people who can't take proper care of their systems, and we get a less elegant solution that simply works. Everybody wins, right?

[Chris Cox]

Without reproduceable cases to test - we have no idea if that would work.

It all depends on what is wrong with the APIs or servers.

ID and AI probably aren't working - they just aren't reporting the error (and loss of your files) to you.

[j. scriba]

ID and AI probably aren't working - they just aren't reporting the error (and loss of your files) to you.

Em.... Chris, somehow this discussion is turning weird.

I was suggesting you implemented (as an option for Photohop users) the exact same file handling that InDesign and others of your applications are using.

I suggest that you test it to the same level of confidence that you are using in those other products and give users the choice of whether they want Photoshop to run the extra mile of super-safe saving (that may cause their faulty systems to prevent saving at all) or do like the others do (at their own risk).

Are you saying that InDesign is a faulty product that keeps losing files?

Are you saying that everybody who is reporting this Photoshop-problem is probably losing files with their other software?

Are you saying that I'm too (insert a nicer word for "stupid") to realize that I'm constantly losing files, even though I'm pretty sure I've never lost a file in my setup?

I'm actually pretty paranoid about my data. That's the whole point of saving to a remote raid system.

I feel that the process of Photoshop forcing me to copy workfiles to local drives and keep track of which version is replaced by which introduces an element of human error that much more prone to accidentally losing an edited file.

Why do you insist of forcing an extra level of file handling security on Photoshop users if they are content with how all of their other applications are handling this?

If I had the choice of disabling "safe saving" (which might be on by default) and then lose a file it's my choice and my system that screws up.

Why can't I make this choice?

Why do you feel the need to tell your users that what they normally do with their other software (and Adobe's other products) is a wrong way of doing things and that some of us are driven crazy by Photoshop's file handling only for their own good?

[Chris Cox]

I was suggesting you implemented (as an option for Photohop users) the exact same file handling that InDesign and others of your applications are using.

How would it help to change our code from "safe and telling you about problems" to "unsafe and not reporting errors"?

Then people would lose their documents and never know that a problem happened.

That's not something we would even consider!

If there is a problem in Photoshop, we'll fix it.

If there is a bug in an OS routine, we'll file a bug and try to get it fixed.

But we will not intentionally damage our software just to let you unknowingly lose work!

[Todd_Shirley]

To summarize:  1.Two of Adobe's flagship products, InDesign and Illustrator, save files in a way that is "unsafe and not reporting errors" which leads to a situation where "people would lose their documents and never know that a problem happened."   2. As far as we can tell, Illustrator & InDesign users are completely unaware of this major fault in these products and are somehow ignorant of the fact that they are losing data on faulty servers. These users live in a state of ignorant bliss where they never notice data loss or report saving errors to Adobe.  3. Photoshop saves files in a way that is "safe and telling you about problems" which is superior to the way InDesign and Illustrator save files.  4. For years, Photoshop users have been complaining about difficulty saving files to servers and occasional data loss and corruption, even though Photoshop saves files in a way that is safer and better.  5. For some reason, Adobe doesn't want to implement the safe and superior file saving method with InDesign or Illustrator, nor give Photoshop users the option to use the inferior (but widely used and well liked) saving method used by InDesign and Illustrator.  Is that about it? What am I missing here?

[Chris Cox]

Each product is a separate team.

And no matter how many times we request something, suggest something, write bugs against other products, etc. - we cannot make those other teams do anything (no matter how badly they mess up).

[j. scriba]

>> I was suggesting you implemented (as an option for Photohop users)

>> the exact same file handling that InDesign and others of your

>> applications are using.

How would it help to change our code from "safe and telling you

about problems" to "unsafe and not reporting errors"?

That's not something we would even consider!

I see, so InDesign, Illustrator etc. are broken products.

Amazing that Adobe is very happy charging substantial amounts of money

for them and a large number of customers are happy buying and using

them.

Suppose there was car that ran 200mph smoothly but would

automatically perform a screaming emergency brake maneuver once its

radar detected a pothole in the street.

You would like to drive through potholes just like all the other cars

on the road do and ask the car maker to fit that radar with a switch

so you can disable it on the less-than-perfect roads you need to drive

on.

The car designer would say: There's nothing wrong with the car and

potholes are nothing we can fix. We can't let you go without the

radar, you might have an accident. We suggest you drive on perfect

roads only.

Would you appreciate that attitude?

[j. scriba]

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?

AFP & Mac server won't help.

As you can see in the other posts the issue even happens when a single Mac user accesses a Mac sharing volume.

[Guest]

you should  try that and it will working fine for me .

The Mac is joined to the domain.

Logged onto the Mac with the local admin account... Connected to the server via smb://server/share as a domain admin and everything worked as normal... I moved files, folders, renamed files, and folders, many times, in and out of root folder, up and down the tree structure throughout sub layers, in all view modes and never got prompted to enter a password.Logged onto the Mac with "Domain User" account, connected to server as "Domain User" and Finder breaks rather quickly after a few moves of files and folders. Domain User account was configured using Default Domain User Permission level with full control, and without full control, still prompts for password to make changes.

[alicek98770499]

The short answer from Adobe is that they only support saving to a local disk. The issue appears to be that Photoshop perceives the file on the Server to be locked or in use. By far the easiest workaround is to use Bridge. From Bridge consistently use the shortcut menu with "Open With" and choose Photoshop. Do not use the "Open" function. Do not double click. Your file will now save to your server consistently. If you make a mistake you will need to deselect the folder you are opening from in the finder to release the lock on the file. Alternatively, if you have a Synology server, the Synology app "Cloud Station" will effortlessly synch local and server folders, and it is extremely easy to add or remove folders to synch as you need.

I have no idea why using "Open With" from Bridge works, but it does. It therefore seems that Adobe could potentially solve this issue. My research indicates this is a Mac issue and goes back to at least 2011. At various times Adobe has maintained this is an Apple OS problem (pick which one), that they can't reproduce the issue on their servers, and then finally falls back on "we do not support saving to a server" due to blah, blah, blah. There is probably an incompatibility between some API utilized in Photoshop and Mac networking parameters. I surmise using Bridge as described bypasses this.

Hope this helps.