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.

[Andre Schneider]

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

[brunerd]

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

[Chris Cox]

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.

[olafbrand]

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.

[Chris Cox]

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.

[olafbrand]

Okay Chris,

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?)

but...

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,

Olaf

[Chris Cox]

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.

[olafbrand]

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.

[Chris Cox]

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.

[bellevue scott]

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.

[bellevue scott]

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.

[bellevue scott]

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.

[stevev79562377]

Still see this issue

[RBurgett57]

I have had this issue for years, and on several versions of Mac OS. Currently still having the issue running 10.12.5 on a Mac Pro.

Saving to a SAN.

I can save to my desktop, then copy over with no issues. I'm thinking this is more of an Adobe issue than a MacOS issue. I experience this with all Adobe apps that I use, and have not had this issue with any other applications.

[schneiderbr]

Connect via afp:// protocol and will be able to work directly

[wills439679]

Interesting...I haven't tried AFP yet (I only share out SMB and NFS exports on the cluster we use for the design team).

It's no longer an inconvenience....

My users don't have this issue in Pr, Ae, Ai, or Id RBurgett57​, but they're doing the same workaround you mention (save to desktop, then ultimately push to the NAS). Seems to be an Adobe issue for sure, and even if it's a MacOS-rooted problem, they need to work it out with Apple. This isn't the same File Preview issue that happened a few MacOS's ago.

We're seeing the issue still on MacOS 10.10, 10.11, and 10.12 to both SMB- and NFS-shares on multiple Isilon clusters.

No one from Isilon wants to help, they push back to Adobe...Adobe pushes to Apple...it's a never ending cycle.

[augur165]

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.

[brunerd]

Actually we are using IBM servers running Linux for Xinet and before that SGI Irix

[Chris Cox]

Do you have this problem with servers that aren't running Xinet?

[schneiderbr]

Resolution: Can't save to an OS X Server share point that allows write access - Apple Support

[billlp]

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

[Kurt Lang]

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.

[billlp]

I don't understand the saving $20. Can a reformatted drive be used on both Mac and PC?

[Kurt Lang]

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.