Participant

Answered

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

Forum|Forum|15 years ago
October 1, 2010
56 replies
429825 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.

Problem or error

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

Show previous replies

Anonymous

After a lot of frustration here today, we were able to resolve this issue by turning off "Show Icon Preview" in the Finder, using OSX 10.7.2.

It looks like, for our situation, this error was the result of a conflict between Photoshop and the Finder. We "fixed" this conflict by turning off the Finder "Show View Options":

Show Icon Preview = OFF

If that is turned off, the problem goes away. Optionally, you can turn off Photoshop's preference to save icon previews. That also "fixed" it. But since Show Icon Preview is a network hog, and our server software (Xinet) already makes icon previews, we chose to turn that off.

Hope that helps a few folks,

James

Tai_Lao

Inspiring

jpword wrote:
…since Show Icon Preview is a network hog, and our server software (Xinet)…

You're working across a network?

This is the boilerplate text often used in connection to saving to a network (please NOTE the part where it explains that normally, it does work, but that it is impossible to troubleshoot someone else's network remotely, and that's why it's not supported by Adobe):

If you are opening files over a network or saving them to a network server, please cease and desist immediately in the event you are currently experiencing problems with one or more files. Working across a network is not supported.

See:

http://kb2.adobe.com/cps/406/kb406793.html

Copy the CLOSED file from your server to your local hard disk, work on it, save it again to your local hard disk, close it, and copy the closed file back to the server.

Of course, the fact that Adobe does not support working across a network does not necessarily mean it won't work. It should.

Adobe's position is that there are too many variables in a network environment for them to guarantee that everything will work correctly in every network, especially given the fact that if something does not work properly, it's probably the network's fault, and Adobe has no way of troubleshooting your network.

If you can't work locally, you are on your own, and if something happens, you're on your own. If you must work from a server, make sure your network administrator is a competent professional.

When problems arise, a lot of valuable work can be lost.

____________

Wo Tai Lao Le

我太老了 No connection to Adobe, just another end user.

Anonymous

Hi,

Yep, over a network.

Works fine with "Show Icon Preview" turned off, which is part of Adobe's "normally, it does work" message... but I completly agree with you, if you have sensitive image files, and no backup, you should certainly not work over the network... but many people do and I wanted to share why Photoshop was denying the write with the, "write access was not granted" message. It's because our server respects locks and the Finder had the resource fork locked trying to make its Icon Preview.

Photoshop should detect when that's the case, and avoid the original file from being deleted. The error is fine, and justified. The delete is not.

Thanks,

James

Tim-Dube

Participant

I have one user with this issue as well. Only happens in Photoshop and not all the time. Seems to only happen with PSD files. My other 12 users, to this point, don't receive the error. CS 5, Lion, saving to a Windows 2008 R2 Server running the latest version of ExtremeZ-IP. This user was having the problem with a previous Mac, which had 10.6 on it, so as a test I moved him to the newer machine he currently uses and same problem pops up. It isn't all the time but does happen every day at least once when trying to save his work.

Going through this forum I don't hold out much hope this will get fixed because it seems Chris has taken on the typical, in my experience at least, Adobe stance of it is never our products that are causing the problem. In all reality it is probably Photoshop and something to do with OS X but god forbid two companies work together to solve an issue. Meanwhile we the users deal with the pain.

Chris Cox

Legend

>> the typical, in my experience at least, Adobe stance of it is never our products that are causing the problem.

That is a common answer because that is most often the case after we fix the major bugs in our products. (ie: after fixing our bugs, what's left are other people's bugs that we can't work around) Whenever a problem is ours, we admit it and try to get it fixed as soon as possible. And as noted above, we've been working with Apple on this, and other companies.

Anyway, we are continuing to work with Apple to figure this out, and adding more safety code on our side to prevent file loss when unexpected file system errors occur.

Nate_Berggren

Participant

Chris Cox wrote:
Anyway, we are continuing to work with Apple to figure this out, and adding more safety code on our side to prevent file loss when unexpected file system errors occur.

Let me ammend my comment to say that if this is an Apple bug that can't be worked around, Photoshop/Lightroom is the only software combination in my experience that has hit it. Is there a bug report with Apple that I could follow?

Nate

jrtbloke-2011

Participant

Just to add my voice to those of others. I am an apple ACN in the UK and I support just over 40 companies. This error has cropped up in two separate sites. One with a user running CS5 on a 10.6.x machine working off SMB (I say 10.6.x as this problem persisted for this user from 10.6.4 up through 10.6.8 and persists now as an intermittent fault in CS5). I now also have a second user afflicted running CS5.5 on a 10.7 client accessing a 10.6.8 based AFP share. Although I didn't see it in person, the CS5.5 user has also reported this as an issue with local files as well as network based files. Both users have so far nullified the issue by reverting to CS3 or 4 where there's no problem.

I have to agree with others, the common thread is Photoshop CS5. This happens with nothing else. No other CS5 app. No other version of CS, no other app outside of CS. this only happens in Photoshop CS5. As much as Chris tries to bat this away - theres an old saying, that "if it looks like a horse, smells like a horse and sounds like a horse.... chances are, its a horse". I expect to see this issue more often as companies buy new machines and end up buying CS5 for those new machines. It would be nice to see this resolved before CS 6.

Chris you have been doing a great job batting this away and defending the company line. I'd expect nothing else. but at the end of the day this feels like ford making a car with dreadful handling that shakes all over the place and blaming the road. if CS5 is meant to play nice on OS X 10.x, y or z then it's adobe's job to make it roadworthy, and right now it feels distinctly rickety.

ATB to all

John

PeterK__

Participating Frequently

Just wanted to add, in case nobody has mentioned it, that one way I've been able to easily reproduce the issue is by trying to save a large file and cancelling it mid-save by hitting the Escape key. The file on the server disappears at that point and a "save as" must be done to save the file you still have open in memory back to it's original location again.

mccolo

Participating Frequently

brunerd

We are still on FullPress 16.05 without the database turned on our WIP. The strange thing is, it appears from your screen shot, as from the ones I have seen in terminal, it isn't a perms issue, because they have access. So I dont understand where Photoshop is getting the error message and why it thinks it is a write issue if all the settings are open. Perms was one of the main reasons we went to Linux instead of Apple.

More tech info to rule out io errors due to speed.

The machine is an 8core Mac Pro with 16GB of RAM, a 1TB scratch and 512GB hard drive, with dual ethernet aggregated to a layer 3 switch with a 10gig backbone. The Server has 4 10 gig uplinks to an IBM server with 96 processors, 256GB of RAM and 15K drives on a fiber channel raid through a SAN. This is our only user TESTING Photoshop CS5, which is why no other users are having this issues. Perhaps it is related to the ACL issue apple has worsened in SnowLeopard with duplicate ACLs appearing all over the place depending on how nested the folder is = the number of ACLs on the file. Supposedly that is fixed in Lion, but I think its just another ploy to buy new hardware. Perhaps we will just have to stop buying Photoshop, move to Linux and start using open source software and the old school retouching techniques that always seemed to work.

Chris Cox

Legend

So I dont understand where Photoshop is getting the error message and why it thinks it is a write issue if all the settings are open.

Because the OS is returning an error during the save operation.

We don't know the specifics (but Xinet seems to be the only AFP client with problems, and SMB problems appear to have a different cause).

mccolo

Participating Frequently

Chris Cox wrote:
So I dont understand where Photoshop is getting the error message and why it thinks it is a write issue if all the settings are open.
Because the OS is returning an error during the save operation.
We don't know the specifics (but Xinet seems to be the only AFP client with problems, and SMB problems appear to have a different cause).

Can you please clarfiy by what you mean that Xinet seems to be the only AFP client? I thought earlier we were reading about posts of regular OSX running afp, and also that extremeZ IP was also another one having issues. Xinet is a server not a client, the client is the mac connecting regular ol afp. Xinet is lik Extreme Z IP but with more than file sharing, hence the reason for having it, otherwise I would just use a different sharing method.

I just want to understand your thought on why you think Xinet is the only one with problems.

Thnx!

Anonymous

So we recentrly upgraded Xinet to 16.06, I'll check with our Xinet admin (out today) what the "dot filename" treatment setting is.

It would be interesting if it was Xinet causing this by trying to apply the invisible setting to the file while other operations in PS were trying to access it. Although why would you call a temp file .afpDeleted is beyond me...

Anyway, so we are on FullPress 16.06, running Photoshop CS5 12.0.4, on a new iMac 27" with 10.6.8 v1.1 (yes, it shipped with Snow Leopard thank god) and we are now graced with a new .afpDeleted error message! The user started using PS CS5 yesterday on his MacPro and had this happen, then today on his new iMac 27" - the following is a screen shot of the error with the Terminal in the target directory, showing the .afpDeleted file

Dialog text:

Error 8800: General Photoshop error occured. This functionality may not be available in this version of Photoshop.

- Could not save ".afpDeletedxxxxxxxxx" because write access was not granted.

Line: 54

When our Xinet admin gets back, we might try altering the "Filenames that start with period (.)" to "No special treatment (may crash ancient Mac clients)"

Since every client we have here is now 10.6 there are no ancient Macs...

Anyway funny, I was just about to revive this thread just this morning before the new post, nice one mccolo

Chris Cox

Legend

Although why would you call a temp file .afpDeleted is beyond me...

You'll have to ask Apple about that. That's an OS and file server thing, not related to Photoshop.

mccolo

Participating Frequently

Has anyone tried playing with the following AFP settings in Xinet to see if that has an impact? I wonder what the option for "No special treatment" would do for the newer versions of OSX if anything.

We recently have run into this with one user on 10.6.5 runing CS5 using Xinet on IBM servers with RedHat Enterprise installed. Client machines have dual port aggregated ethernet running to a switch that has a 10 GIG uplink to the server.

If I do a terminal to the share, the .afpdeletedXXXXXX file is created and as mentioned before a mv command to a new file name brings the file back "from its "disappearance" according to the user. Only part that Apple is involved in is the client.

jackjojoj

Participating Frequently

Done some more testing. If 2 people have the same file open in photoshop CS 5, mac computers, mac server, the last person to save wins. A little worrisom, it would be nice to know the file is open by another.If one person has the file open in Prieview, and the other has it open in CS 5 and tries to save, the user gets the could not save error, and the file is deleted from the server. So it appears to be an issue if another app has use of the file, but it still DELETES it!!! CS4 does not do this, in the same senario of photoshop and prieview, it says it cant save because the file is in use or left open. Why cant CS5 do this?

Dana

Chris Cox

Legend

it would be nice to know the file is open by another

There is no way to know that short of using an asset management system that forces checkouts to modify the file.

When a file is opened into Photoshop -- the file on disk/server is closed after reading. It would break many applications and workflows to hold the file open unless you are actively reading or writing it. After reading or writing, there is nothing to indicate that someone else has the document open.

Photoshop already checks the file for changes and ask if you want to update, and warns you if the file has been modified before you save.

PLEASE read the existing thread. You are asking things that have been answered several times already.

jackjojoj

Participating Frequently

My whole issue is the file gets deleted from the server if it cant save

jackjojoj

Participating Frequently

Aside from your complete denial that photoshop deletes the original file, when it clearly does and have the server logs to prove it, why cant you add a dialog that says something like someone already has this file open, do you want to open it as read only.

Chris Cox

Legend

Please read the thread before adding comments.

(also, this toipic has nothing to do with opening files, so the suggestion about an error message makes zero sense)

We've tested this, many times. Previously, the problems have been traced to the server or (once) a bug in an OS API.

The current problems appear to be due to an OS API that fails to return an error correctly, and fails to do it's function correctly.

We do test the files before saving, which is why we put up the warning about files being in use or the user not having access.

We test the files while saving, and after saving to make sure the sizes are correct, the permissions are right, etc.

But after all those tests are done, after we've written out the file, we call an OS routine to do the final step - and it is failing.

Photoshop is not deleting the original file. Photoshop calls an OS API to replace the original file with the file we just wrote. But that API fails.

Now, why does it fail for some people and not for most others, and why does it not fail for us unless we force the situation? We don't know. Some of that has to do with the server, and some might have to do with OS versions, timing, or the phase of the moon.

Now, we're trying to get this solved - but we can't solve it.

We have to use the OS API, and the OS API is broken. We could reimplement the OS API, but it would take a lot of work and not be guaranteed to always work. All we can reasonably do is work with Apple to fix the OS API.

If you want a fix sooner, talk to Apple.

Anonymous

Chris, I think people are saying "the same thing" because despite offering up what seems to be a variety of situations in which we are having problems, the response we are getting is also "the same thing": 'Yes we've looked, it's hard to know, but we use "safe" methods'

So we'll keep offering up evidence to the contrary that PS is _actually_ using safe saving methods, because I honestly haven't ever seen this in any other Adobe app and I've been in IT since 2000, supporting CS, CS2, CS3, CS4, CS5, and soon CS 5.5 and from my experience Photoshop has problems with network saves, maybe not as often as some others here, but I've seen my share of truncations, corrupted layers, corrupted files, and deletions.

Speaking of reading the whole thread...

Back in Octobober 15 and I offer a video of a file being deleted during a save:

http://www.youtube.com/watch?v=ybXFybcATFA

Depicted is me saving to a file that was being thumbnailed by Finder on another computer It took split second timing to do this but I could recreate it.

The point is not that Finder may or may not have a lock on the resource fork when Photoshop tried to save but the FACT THAT THE FILE DISSAPEARS! Luckily (in that case) it could be resaved without throwing an error, other instances would not allow a resave.

Bottom line: A USER WOULD ASSUME THE FILE IS SAVED AND QUIT! WORK LOST.

DISSAPEARING FILES DURING A SAVE ISN'T SAFE!

That's why we keeping repeating this because it doesn't seem to be acknowledged: It's not SAFE ENOUGH!

Ensure the file is written, if not, prompt us to try again?

Can these silo'd product team have a meeting come to a consensus on file saving routines, invent the wheel once and not repeatedly in each product? Although if the PS team thinks ID and Ai are using "usafe" methods then that's a problem, I doubt those engineers on Ai and ID think their methods are substanadard, it seems a bit hubristic for the PS team to say that?

So in the spirit of humility and enlightenment: can this issue be looked at by all the Creative Suite product teams without bias and a truly genuine collaboration take place? Can the various methods used by all the engineers who maintain file routine code be distilled into 'best practices' or heck a common framework for file saving that will ultimately benefit the customer? Will egos and politics amongst the engineers allow? I truly hope so.

Thanks,

Joel Bruner

Creative Technology Specialist

Y&R Brands

jackjojoj

Participating Frequently

Having the exact same problem, UNACCEPTABLE adobe!!! If photo shop doesn't delete the file and is "safe" why does the file disapper, and say it was deleted in the servers access logs. Figure it out, and stop trying to blame the problem on users servers. Copying the file to your desktop to work on it is a big load of crap!

Holger Netterby

Participant

I´m sorry to play the devils advocate but I still find it strange that the only applications that have ever failed a server save for my customers are the three listed below.

I support around about 75 companies with between 2 - 150 users each, most of them in graphic production. I have during 20 years only ever heard of 3 applications causing a save failure (to a server or locally) on a regular basis. Two of them fatal (IE the files is gone after save attempt) and the third just gives an error.

Microsoft Power Point 2004 - Working on large files sometimes caused the file to vanish from the server (or the local disc) when saved. Was fixed by Microsoft after some updates. Not completely shure but I think this only happend on non-US versions of Office. (sometime between 2004 SP2 - SP3 if I remember right)

Adobe Photoshop - I (my customers) have only encountered this error with CS5 and Helios EtherShare up until now.

Apple Final Cut Pro - Saving gives error -50 unknown file. Workaround - save file locally and then transfer the file to the server. This does not ever cause the file on the server to vanish! (Most FCP versions)

What I want to point out with this is that I can guarantee that I would have heard about files getting corrupted during save. If files is un-openable after a save customers tend to throw themselves on the phone to get support and demand that a backup get retrived. This is just natural behavior. The point being that when I heard this CS5 save error I assume an error in Photoshop CS5 because all other applications work as expected.

Who do you think I should report this error to? Apple or Helios or both?

Chris Cox

Legend

I´m sorry to play the devils advocate but I still find it strange that the only applications that have ever failed a server save for my customers are the three listed below.

They're not the only ones to fail.

They are the only ones that TOLD you that they failed.

Again, many applications fail to complete the save and don't do enough error checking to tell you about it.

And we do hear about files being corrupted or lost when saving to a server, all the time. (and I don't mean just from Photoshop)

We've investigated the problem many times. In the past, it was mostly server bugs, bad networks, and once a bad OS API (that got fixed).

This time, it looks like another bad OS API that can fail in a way that it is not supposed to ever fail (losing documents). Since the whole point of that API is to do a safe save and not lose documents, that is particularly bad. But we can't do much about that. If we use other APIs, we have other problems. If we use this API, it is supposed to work, but may require an OS update before it works correctly.

This is one of many reasons why we say to save and open files locally and not off the server -- there's too many things involved that are outside of our control, and that we know go wrong in some situations.

Show more replies

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded