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.

[bretperry]

Pauline,

You can use Disk Utility in Utilities folder of Applications folder to see how your drive is formatted. (look don't format

Open the Disk Utility program and select your hard drive on the left.

Your (formatted) drive will be the one that has it's usual name and is indented from the raw drive.

With your drive (name) selected, at the bottom it will say "Format:"

If it is NTFS, how odd. You must have had special software installed on your old Macs to write to that format.

If it is a Mac format, Mac Extended (journelled or not) it could be many things but likely permissions. Try repairing permissions then in Disk utility, but probably you will need to reset them further.

Try File… Get info on the drive or a folder on it and see if you have read/write permissions under "Sharing and Permissions" (click triangle to see if needed). If you have permissions, then it I something else.

If you don't have permissions, You can change permissions to yourself with Get Info or get an app for changing permissions to make it easier.

[Kurt Lang]

To expand/add to bretperry's notes:

You don't need to launch Disk Utility to check a drive's format, though that does certainly work. Simpler is to just highlight the drive's icon on the desktop and press Command+I, or choose Get Info from the menu bar. It's format will be listed in the Get Info dialogue box, as show next:

In relation to that, I've never seen any need to have permissions on for either internal or external drives which are not the startup disk. At the bottom of the same Get Info box, click on the icon of the lock. Enter your admin password to allow changes to be made to permissions settings. Turn on the checkbox for, "Ignore ownership on this volume". Close the Get Info box. You'll never have a read/write problem again on that drive since nothing is treated as "owned".

[OneCustomerIT]

Hi all.

We have been hit by the same kind of issue while saving Photoshop or Indesign files onto NFS shares, NFS shares being stored on a NetApp storage bay. Both software throw an error saying there are insufficient privileges to save files. We've been able to nail down the issue.

The basic security model of UNIX boxes only allows the sole owner of a file to change it. Since only 3-4 people need to work on each other's files in our case, we didn't use ACL but used NFS sharing property all_squash (see http://www.troubleshooters.com/linux/nfs.htm ) so that the owner of files placed on the share are owned by the NFS anonymous user, access is restricted to the IP addresses of the relevant machines.

The "insufficient privileges" issue while saving files occurs systematically when NFS uid squashing is enabled on the NFS server. Without squashing Photoshop and Indesign both save their stuff without moaning. This issue hence boils down to either how these programs manage the save function or how the corresponding MacOS API works. This certainly has to do with either checking or forcing the owner of files while saving. The Preview mode has little to no influence.

We're currently trying ACLs on NFS shares to temporarily work around this major annoyance.

Hope this helps.

[Chris Cox]

That does sound like an OS bug, where it is incorrectly reporting the permissions in that case.

Hmm, I bet it's one of the known OS bugs. Try turning off all thumbnails/icons in preferences (to eliminate resource fork writing) and try saving to the NFS volume.

[Guest]

(Sorry for replying with a new account, the other one doesn't seem to work anymore.)

@Chris:

Fact is:

• without all_squash Photoshop actually saves files *even* with preview/icon/thumbnail enabled,
• with all_squash Photoshop throws this error message *even* with preview/icon/thumbnail disabled.

That's what I meant «the preview mode has little to no influence». Besides only Photoshop (and eventually InDesign) throw these errors (when saving onto NFS shares with UID squashing enabled). We've used a few other applications (like TextEdit or Finder, for instance) and no error occurs regardless of whether UID squashing is enabled or not.

[Chris Cox]

Hmm, the known permissions bugs were mostly resource related -- but there is another outstanding bug that fails to map ACLs to Carbon/Cocoa permissions correctly for all file forks, and I think it is NFS specific (at least according to what we've heard from Apple so far).

Photoshop does more error checking when saving - because we've seen so many problems in the past, and seen other apps fail to save correctly in the same situations.  So we tend to catch these errors when other apps don't (and they will sometimes silently lose your file).  We've been trying to work with Apple on these issues, but it has been difficult.

[Guest]

Chris Cox wrote:

Photoshop does more error checking when saving - because we've seen so many problems in the past, and seen other apps fail to save correctly in the same situations.  So we tend to catch these errors when other apps don't (and they will sometimes silently lose your file).  We've been trying to work with Apple on these issues, but it has been difficult.

I think I understand the motivations just that in this case, our issue with UID squashing also results in losing the file. With UID squashing enabled, the program actually has write access to the resource, which is why it's so frustrating. It then zeroes the file and throws the error. This is as annoying as corrupting the file in the cases you referred to, I guess.

[KG_Wong]

Hi all,

being following this thread since beginning and tried all suggested possible solutions but non of these solve this problem in my environment (see my environment below)

But my latest testing may have solve my problem of psd file open from network drive (being mounted using afp or smb) disappear after save action. All iMacs in my studio are installed with PS 5.1 and all of these iMacs have are showing the same if open psd from network drive, so all my testing are performed using PS 5.1 and all failed as expected. But recently i install one of the iMac with Photoshop 5 Extended, and suprisingly this problem solved (psd still there in network drive after saved). And i have been using the same psd in same network drive location for previous testings all failed but it is ok with PS 5 Extended. The very same psd if save using PS 5.1 standard, same problem happening again. Now i am trying to install PS 5 Extended into another iMac just to confirm.

This information might be useful for you guys too. As i understand the only different of PS standard and PS Extended is Extended support 3D creation and editing. Anyone can provide more in-depth explanation will be good.

Environment:

Client Machine

OS: OS X 10.7.5

Photoshop version: CS5 Extended

Network Drive

Type: Synology Diskstation DSM 3.1

Protocol: tried afp and sbm, all works if psd open using CS5 Extended

thanks

[Chris Cox]

Extended and Standard are the same app, and don't change the file save behavior in any way.

The only difference is that the extended serial number enables some additional features.

I think that we now have a good handle on the causes of these MacOS filesystem problems, and are testing workarounds to avoid those problems.

[KG_Wong]

Hi Chris,

thanks for replying. but strangely by using Extended version did solve my problem. will be great finally know that we got some workaround for this problem. hope the solution also applicable for PS 5 or 5.1.

[Guest]

Further investigations, we've switched from NFS to CIFS and we're experiencing other issues. All boil down to using Adobe products on Mountain Lion. To summarize:

1. NFS yields access and permissions errors.
2. CIFS yields errors such as «Cannot save xxxxx.psd because of an unexpected end of file.» Worse: the file is truncated to zero byte length. If you exit Photoshop, the file is lost. The user must have the reflex to save *twice* to not lose her work!

All these issues occur when the following conditions are all met on remote shares:

1. Adobe products (Photoshop, Indesign...)
2. running on Mountain Lion (10.8.x)
3. ownership on the remote share is forced (e.g. either with NFS id squashing or SAMBA server configuration options "force user" or "force group").

We have fallen back to using the above mentionned Adobe products on MacOS Lion (10.7.x) but not Mountain Lion (10.8.x).

I personally believe that is enough to qualify this annoyance "serious", right ?

[Chris Cox]

That does sound like you're hitting a couple of the known MacOS bugs with file servers.

We're still trying to work around them, and Apple is still trying to get some of their bugs fixed.

[maw2013]

I've started having this issue, too, with a new NFS export from a Linux server. My end users are in a mix of 10.6.8 and 10.7.5, and all are using CS5.

Here's what I've learned:

1. We are exporting the share via NFS with ID squashing (UID 65534, GID 12 --aka Everyone on Macs).
2. All other CS5 apps (including InDesign) do not exhibit this problem.
3. Every other Mac app I've tried can write to the folder without a problem.
4. Save for Web & Devices does not exhibit this problem, it can write to the same folder that the normal Save function cannot.
5. It is entirely a problem with group permissions to the folder, or a specific file if Photoshop is trying to overwrite an existing file.
   1. Photoshop will not save a file if the user has read/write permissions, but the group only has read permissions.
   2. Photoshop will save to a file if the user and the group have read/write permissions.
6. When Photoshop cannot write to the file, it will create a new 0-byte empty file with an April 8, 2037 6:53pm timestamp in its place, or delete the existing file.
7. If I create (in Terminal) an empty filename.psd file (via touch) and then chmod that file to 664 (rw-rw-r--), Photoshop will overwrite that file, as it should. If that file has 644 permissions, Photoshop will not save over that file.
8. Turning icon previews off in Finder preferences makes no difference.
9. I have also tried this with CS5.5 (Photoshop 12.1) and CS6 (Photoshop 13.0) with the same results.

From reading this thread (from the start!), I've learned that Photoshop farms off the saving of the file to OS X, and that leads me to think that the OS X user that runs that saving process doesn't belong to the "everyone" group (GID: 12) on the Mac that the user using Photoshop belongs to.

Message was edited by: maw2013

[Chris Cox]

We've been talking to Apple about this, and especially about the NFS issues -- they've found some of the causes (yay!), but we don't have any estimate for when a fix will be available.

Meantime we're continuing to investigate and test various workarounds.

[captain1944]

IN SUMMARY, if that is posible, what is the workaround fix? Is it to re-install mountain lion? If so, will this delete all of my files and applications or will it simply provide a new mountain lion? I have used cocktail to help, but now this fix has a short life so I would like a more permanent fix without having to rebuild my entire desktop. Thanks

[Chris Cox]

As a programmer imagining all the ways the file system bugs could occur, I highly doubt that reinstalling the OS would change their behavior.  But I don't know the exact nature of all the OS bugs, so I can't say for sure.

[captain1944]

thank you but is the the fix thathas been suggested?

[Chris Cox]

The only OS reinstall advice I can find in this thread is for an unrelated problem (OS bug with thumbnails).

[captain1944]

so there is no other fix at this time?

[Chris Cox]

Please read the thread.  We're working on workarounds for Apple's bugs, and Apple is slowing identifying the cause of their filesystem bugs but we don't have an ETA for their fixes.

[PmgRWB]

We are seeing similar issues, is there  a bug ID number that we can link to on this with either Adobe/Apple support?

[Chris Cox]

No, there is no single bug ID for this.

[Simon_Joh4nsson]

Hi there,

we have isolated a scenario that can result in dataloss or error messages mentioned in this thread.

Issue: Saving from Adobe Photoshop to Xsan 3.0 Volume or AFP re-share of Xsan volume causes error messages and dataloss.

Configuration:

Xsan 3.0 on servers running 10.8.3

Xsan volume with Native Extended Attributes enabled.

Clients running 10.8.3, Adobe CS6 Photoshop 13.0.4

Troubleshooting / steps to reproduce:

On Xsan clients (with Xsan 3 volume mounted):

- Save of new file from Photoshop results in error:

"Could not save “filename.psd” because of a disk error."

- Save of existing file results in no error dialog but file is removed from Xsan volume. (Ie. dataloss!)

On Clients connecting to AFP re-share of Xsan volume.

Creating new file works.

Modifying and saving the created file results in error:

"Could not save “filename.psd” because write access was not granted."

Clients can mount AFP share-points that are pointing to HFS+ volumes without any issues (which is great of course).

Workarounds:

On AFP clients:

1. Save as and rename each file you modify. (if modifying texture files or similar this is not viable due to re-linking hassle afterwards).

2. Save locally and copy file over to storage. (in this day and age this is not an acceptable workflow to suggest to clients, especially since all other Adobe apps does not experience this issue).

On Xsan clients:

1. Save locally and copy file over to storage. (in this day and age this is not an acceptable workflow to suggest to clients, especially since all other Adobe apps does not experience this issue).

Solution:

n/a?

Possibly downgrade OS on clients to 10.6 (but that leaves out newer Apple hardware)

Any ideas, suggestions, confirmation of being able to reproduce above would be greatly appreciated, this is a BIG issue for us.

Comments:

I do not really care about if this issue is Adobe's or Apple's. But since all the other CS6 applications works without any issues and this only happens with Photoshop it sure feels like it should be possible for Adobe to address this one way or another.

Since this is resulting in dataloss I also hope this will get the attention it deserves in regards to getting a fix.

Based on the history of Adobe releases it is reasonable to expect a new version of CS within the coming months. But even if it would be fixed in the next version of Photoshop it would be great to address this in Photoshop 13 as well.

[Simon_Joh4nsson]

Other sites referring to same issue as I outlined above:

http://feedback.photoshop.com/photoshop_family/topics/photoshop_cs6_can_not_overwrite_files_on_xsan_...

http://forums.creativecow.net/thread/71/863120

[Chris Cox]

Again, we are attempting to work around all the Apple filesystem bugs that we know about (and that's a disturbingly long list).  But many of the workarounds are much more extensive than would be allowed in a dot release.

Apple is also working on fixes to some of those bugs, for future OS versions.