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.
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.
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?
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’.
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.
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.
There is no fix at this time. See workaround
We have looked into it, repeatedly.
And we should not write a file that is in use by another app (even if we could).
There is nothing that Adobe can do about the fact that some other application has the file in use.
We're already doing what we should by not making a mess of your file and telling you about the problem.
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.
That is incorrect. Photoshop does not delete the current file first.
Photoshop creates a new file with a unique name, writes to that temporary file, then only when the save is completed successfully does it replace the older file. That is known as a "safe save", and even has some OS support for the action.
Finally, it writes the image being saved to the new file. If any part of this process fails, the original file is lost.
Again, incorrect. If the save fails, the original file is left intact. If an original file is destroyed by a safe save, then there is a problem at the file system or operating system level.
So what you are are actualy saying is that Grouplogic made an error in their analysis?
I doubt it... but if they are; please confirm.
For the first time i read something that closely described this odd behaviour.
I lose a lot of files this way. Mostly on SMB-shares, since the locks tend to last a little longer. So I can confirm they really are being purged. And overall files are deleted in the Photoshop file saving process.(!)
Servers don't lose files by accident, but by a sequence of commands which leads to file loss.
If it is a mismatch in architechture between OSX/SMB/Adobe that cannot be solved, please tell us, but don't make things more complicated.
Yes, they made multiple errors in their analysis.
And we haven't found anyone here who has heard from them about the issue.
Files can't be lost in the Photoshop save process without an OS or server level bug.
We don't care about the protocol, we use OS standard APIs for file reading and writing. Beyond that, it is up to the OS and server to work correctly.
Also, grouplogic's "was this helpful" reply system is broken -- it fails the image verification test no matter how many times you enter the correct code.
Clear aswer, but it leaves me with my problem.
Fact is (in my case), files that should be overwritten are only deleted and never get replaced.
Let's assume it is only an OS and Server issue.
Besides normal File lock behaviour cause of Clients opening files simultaniously (which is clearly visisble in Win2003)
it is hard to determine obsolete OS behaviour.
Grouplogic's Extreme-Zip tries to bridge all the gaps Apple and Microsoft have left.
(Eg. Microsoft didn't upgrade apple protocols since WinNT4 and Mac SMB clients aren't trouble free either)
I don't use extremeZip, since OSX 10.5 Apple has upgraded their SMB client to a level which seems to work for most software.
So i only use Aplles native smb client connected to Win2003 server.
Having these Purged files experiences in Photoshop it might be due to:
- Server settings which i can adjust myself if i know what setting or key to modify. (several options in www.macwindows.com)
- A Microsoft/Apple bug (wait for updates?)
If even Extreme-Zip mentions this behaviour, their software bypassed most of the Microsoft architecture.
Even if their analysis of the problem is wrong, mentioning the same behaviour in Extremezip,
made me conclude the above scenario isn't the case, but it might be "by Design" somewhere...
If Photoshop makes the right API calls......
Whats left is the OSX/Finder design or an incompatibilty between MAC/PC that can't be bridged by Apple somehow.
Macs cant sa(f/v)e on windows networks. That would be a pretty bold conclusion.
Thanx for your answer so far,
It could be an OS file system issue, an OS network protocol issue, or a ExtremeZIP server implementation issue.
Photoshop seems to work fine with normal SMB and AFP servers, but ExtremeZIP has been problematic for some people.
However, our own testing with ExtremeZIP servers (and we use them extensively) hasn't found any problems. It could be specific ExZIP versions, or running with specific host OS versions that introduces the errors.
And, of course, we've had to code around a lot of Apple file system and networking issues over the years.
Depends on what you consider a normal SMB server.
Strangely I am the only idiot here having this behaviour on genuine Microsoft SMB server (Win2003) and Genuine Apple Clients (OS10.5.8)
I cant't think of a more standard scenario.
I am not convinced, it's a Grouplogic issue only.
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.
Actually we are using IBM servers running Linux for Xinet and before that SGI Irix
Do you have this problem with servers that aren't running Xinet?
If you are using a Seagate drive-go to their site and download Paragon NTFS driver for Mac OS. I had the same problem, and this solved it instantly.
My seagate portable drive functioned perfectly with my IMac - when I tried using it with my MacbookPro, I received the same "write access was not granted" message. Seagate support really wanted me to re-format the drive for Mac (but since they couldn't explain why it worked on one Mac but not another-I told them I wouldn't do it) they finally came up with the answer I wrote above.
Hope it works for others
You could have saved yourself $20 by reformatting the drive for the Mac. You couldn't write to it because most new drives come preformatted as NTFS, which is for Windows. It is also a drive/file format the Mac OS cannot write to without a third party driver, such as Paragon. The other Mac must have already had Paragon or NTFS-3G installed, or it wouldn't have been able to write to the drive, either.
I don't understand the saving $20. Can a reformatted drive be used on both Mac and PC?
Paragon NTFS for Mac is $20. Since you mentioned it, I presume you paid for it? I did find a few references on Seagate's site for Paragon, but none where you could download it for free. Doesn't mean it isn't there somewhere, and Seagate has some sort of deal between them and Paragon that allows users who purchased a Seagate drive to get the software for no cost. I just couldn't find it.
If you want to reformat the drive so it is read/write on both the Mac and Windows without the need for any third party software on either side, format the drive as ExFAT on a Windows computer. OS X has the ability to format a drive as ExFAT, but there is a known bug where Disk Utility will use a legal, but larger block size than it should, which sometimes causes Windows to be unable to access the drive. Done from Windows, there normally isn't a problem.
Hi Kurt and everyone
There is a free download on the Seagate site.
If anyone needs it, they can find it on the Seagate.com site under support>by product>portable external>(choose your device) and then NTFS Driver for Mac OS will be listed on the right.
It doesn't mention Paragon, but the Seagate tech support guy said it was.
Ah! Thanks for the update, billip. That's a nice deal for Seagate owners. Though if it were me, I'd still reformat the drive as ExFAT and eliminate the need for a third party driver.
I agree-going forward I'll reformat the drive
I have this problem with save as - I have updated my operating system and cannot save my new file with amendments. I am the only one working on the file?
I use external drives on a mid 2012 Macbook Pro 15" 500g with 8g RAM. I never save locally, so, I format my externals as exFAT and the issue disappears. Not a guess, a solution. I use five externals and all of them save in Photoshop CS5 Ext. (Windows 7) and CS6 Ext. (Yosemite).
Format as exFAT. Worked for me.
(Reposted from an earlier reply.)
Had a look this morning - the issue was that the driver on the external hard drive wasn't installed after I had had the MacBook restored recently. Having just re-installed the driver I can now save to it. thanks for the tip off about formatting the drive - that's what alerted me to the driver!
I am now experiencing this issue. I know this thread is old, but I'm seeing the exact same thing.
imac running 11.10.5 El Capitan
Map Pro running 10.10.5 with attached USB 3 HD, permissions set to read write execute for everyone and "ignore permissions on volume".
imac is running PS CS5 - open a file on any volume on the mac pro, edit and save. File can't be saved because "you don't have permission". Save as also doesn't work. Close file and it disappears from the drive and needs to be restored.
Apple support has tried to tell me that it's "because you're running different OS versions". I told them this is absolute nonsense, because if the answer really is that accessing files across macs running a different OS causes data loss then they have a seriously flawed OS. Well, they apparently do anyway, but I don't think that's the answer.
I have another Mac pro running 10.11.5 and I can open and edit files on the 10.10.5 mac across the network without issue. However, this mac is running PS Cloud version 2015.5.
Is this an issue between OS versions? Or is this a combination of CS5 and El Capitan?
If anyone in the Adobe world knows the answer to this question it would be Mr. Chris Cox.
upgrading the mac pro from 10.10.5 to 10.11.6 fixed this issue. This is a pretty bad bug in the Mac OS. This old thread was a life saver.
Saving started working after I upgraded to 10.11.6, but now the problem is still happening. Both machines running 10.11.6. This seems a very serious bug in the Mac OS.
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
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.
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:
And a movie of a Save action stuck attempting to save to .afpDeleted file while the source file is not on the server:
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:
"Could not save "name" because write access was not granted" with the correct name used and the files remains.
"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
"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.
The .afp deleted files are not Photoshop's.
Those are from the AFP protocol, or the ExtremeZIP server code (most likely the latter).
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.
I just scanned one of our file servers and found 179 .afpDeleted files. Many come from Photoshop, but I also see Keynote, Excel and Powerpoint files. I wonder if this gave the users any trouble... or if they noticed missing data. This tends to back up Chris's point that other programs can emit silent errors.
I'm pretty sure that if 179 files were lost, the users would have noticed and you would know. These errors were probably "auto-fixed" by the app that generated it or didn't cause a file to be lost (which is what bothers me most with CS5)
In our setup (Mac OS X 10.10.5 connecting with AFP to various different netatalk server implementions), the issue crops up reliably (among other times) when our anti-virus software (currently ESET Cyber Security 6.0.14) is configured with Preferences -> Real-time Protection -> Scan On -> File Creation -> checked (enabled). I would like to continue to enable Real-time Protection on File Creation.
I wanted to inquire whether the "Unique Filename" Adobe PhotoShop creates during the Safe Save can be used to configure ESET to *not* scan, say, a certain file extension (though clearly not JPG or TIFF) or something.
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
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.