Photoshop CC: Cannot save anywhere but a local drive

  • 7
  • Problem
  • Updated 4 days ago
  • (Edited)
First let me start by saying, please don't tell me Photoshop and other Adobe apps don't officially support writing to a server. In our small business, and in those I worked for where they had lots of prepress technicians, working off of a server has been the norm for over 30 years.

I don't know if this affects Windows users, but I'm guessing not, given the results of hours of testing here.

There is a problem in Mojave. Or more specifically, Mojave and Adobe's apps.
No matter how you connect to any remote device, the Adobe apps will randomly (and often) say you can't save the file, or, write access was not granted. Doesn't matter if it's a server, or even just a shared folder on another Mac.

I had rather recently made Mojave my everyday OS on a 2010 Mac Pro. Saving files open in Photoshop back to the server was hit and miss. Mostly miss. I booted into High Sierra to see if that was the difference, rather than the server. Yes! The exact same, up-to-date version of Photoshop CC 2019 can save a file you're working on over and over without a single error message. But as soon as someone else logs into the server from a Mac running Mojave and opens a file with Photoshop or other Adobe app, the files of the folder that person is in get locked (or something). We cannot be in the same folder. Not even the Mac running High Sierra. As soon as the user with Mojave disconnects, all error messages go away for the High Sierra user.

Locked files (or whatever Adobe's apps, or Mojave are doing), don't just affect the other user, the problem also affects yourself. You can be the only person connected the server, and as long as you're booted to Mojave, you cannot work from the Adobe apps without getting messages that you can't save a file.

When these write errors occur, you end up with hidden junk files that get left behind in the folder. Depending on how you connected to the server, either .afp.deletedxxxx or .smb.deletedxxxx files. The xxxx being a number. These can accumulate by the dozens rather quickly, eating up lots of server space as they're the same size as the image you were working on. Some will be removed by the server when you dismount. Others you have to get rid of manually.

I don't know who's really to blame here, but since it seems to be only the Adobe apps that cause this issue while in Mojave, then I would say it's Adobe that has to figure out what their apps are doing wrong. From the messages you get, it would appear the Adobe apps aren't releasing files after completing a write. So the next time you try and do a save of your progress, it won't let you. Photoshop hasn't released the file, so neither can the server. Bingo, bango, bongo, you get write error messages. That's my guess, anyway.

Apple will also be getting this bug report. Mainly because testing points both ways. It could just as easily be Photoshop is releasing files after a write, but Mojave isn't. But from Mojave, I can be in Quark XPress, and literally any other non-Adobe app and write back to server all day long. It's only the Adobe apps that fail, and lock other users out of an entire folder. But at the same time, the exact same version of Photoshop CC has zero problems writing to the server in High Sierra or older OS. So then it appears Mojave is the problem.

One way or the other, the combination of Mojave and Photoshop CC makes it impossible to work directly off the server. You haver to copy files you're going to work on the desktop, then copy them back to the server when you're done. This is time consuming and almost makes having a server pointless.

Our new 2018 Mac Mini can of course only run Mojave, which makes it nearly impossible for us to work off the server together.

We've tried having the Mac running High Sierra connect to the server via AFP, and the mini as SMB, but that makes no difference. The main issue is if you're using the Adobe apps in Mojave, you literally cannot reliably save a file from within the app anywhere but to a local drive. Doesn't matter if anyone else is using the server. If you're in Mojave, you cannot write to any server or shared drive without experiencing write errors. Worse, just being connected affects everyone else whether the other Macs are using Mojave or not.

For the time being, I've gone back to High Sierra on the older Mac so at least I can write to the server without issue (when I'm the only one on it).
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes

Posted 10 months ago

  • 7
Photo of Cristen Gillespie

Cristen Gillespie

  • 1736 Posts
  • 584 Reply Likes
Okay, let me run this past you. You may have given me a clue to what's been happening here, but only from time to time, and I AM on High Sierra. But it only started with 2019.

I'm solo here. I have two computers, and they're connected over WiFi, so I can access the various drives as needed. Sometimes, though, and only on my laptop running 2019 (I have 2018 on my Mac Pro), I get the message after saving a file that I don't have permission to save it. But if I go look in Bridge, it has been saved, but minus a thumbnail so I only see the generic icon.

So whenever I get this permission denied popup, I can merely save it again and I'll get the message that the file already exists (which it does), and I overwrite it. Now I'm golden and I get a proper thumbnail generated.

So maybe because I'm also working between shared drives I get this? But only sometimes? And it never comes up if I'm working on El Cap in 2018, and saving between shared drives.  I should also say, it's pretty rare to pop up, but once it does, I can get the same message for the next files I try to save in the same session, if I have next files.

It could just be my computer flaking out on me, which is sort of what I was thinking, but what you're saying sounds about right for the kind of circumstances where I'm saving to a drive on a shared computer.
Photo of eartho

eartho, Champion

  • 1199 Posts
  • 365 Reply Likes
"I had rather recently made Mojave my everyday OS on a 2010 Mac Pro."

Why did you do this? 
Photo of Cristen Gillespie

Cristen Gillespie

  • 1736 Posts
  • 584 Reply Likes
> "I had rather recently made Mojave my everyday OS on a 2010 Mac Pro."

Why did you do this? >

Because he could? <G> I know a couple of other people who decided to upgrade the firmware on their 2009 Mac Pros and are at least up to Sierra/High Sierra, but thinking about Mojave—because the latest Pro line of Macs is super expensive, so they're trying to eke out the very last ounce of usefulness from what they've got. They've already upgraded everything on it they could reasonably upgrade, so. . .

Of course, imo, anyone upgrading to Mojave just yet is taking their life into their hands. But that's just my outlook on it. LOL
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
But it only started with 2019.
I wondered that, too. When I tried from High Sierra, I kind of expected to get the same errors and would then use the Creative Suite tool in install CC 2018 and test that. Didn't need to as 2019 has zero issue for us from High Sierra.
Why did you do this? 
Haha! Well, partly to try and keep up on my font article. That and at first, 10.14.2 seemed to have most of its issues ironed out - until we ran into this major problem. But I've also decided Mojave is just a bit too much for this older Mac. Everything happens a bit slower. I'll keep up on the Mojave updates for purposes of the article, and testing in general, but it looks like High Sierra is really the newest OS that runs well on this hardware.
So whenever I get this permission denied popup, I can merely save it again and I'll get the message that the file already exists (which it does), and I overwrite it.
Hate Bridge. Won't use it - ever. Other than that, if either of us are in Mojave and you get an error message about writing your file, you can sometimes just hit Command+S again and it will save. Most of time, it won't. You get scolded again. The only option is to do a Save As to your desktop, unless losing your edits can be considered another choice.
Photo of Warren Heaton

Warren Heaton

  • 232 Posts
  • 95 Reply Likes
I strongly recommend against working directly from SMB and or AFP servers.  Same goes for NAS storage.  You're just asking for your files to get corrupted.

Ideally, you'd configure a SAN.  Of course, there is a significant cost involved for the hardware, the setup and the maintenance.

LumaForge now offers a very easy to configure option, but it's still a little pricey: https://lumaforge.com/jellyfish



Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
You're just asking for your files to get corrupted.
We've been using our Synology NAS for two and a half years, saving and working on thousands of images with absolutely no problems. Until Mojave, that is.

And it's not just to the NAS. The Adobe apps in Mojave can't write a file anywhere other than directly to your own computer, or an attached standard removable drive.
(Edited)
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
Well, who knows what happened? As suddenly as the issue appeared, it seems to have resolved itself.

You could say the NAS had a bad block on the drive it kept trying to write to (creating the various write error messages). Except, that wouldn't at all explain getting the same errors trying to write to a shared folder on another Mac.

You could say it must have been Mojave since the same version of Photoshop worked fine from High Sierra. But that theory is out the Window since the 2018 Mini is now having zero issues writing to the NAS. We can also be working in the same folder, like we have since we bought the NAS.

The only thing that changed at the same time these errors disappeared was the network. We had sold our Epson 4900. Disconnected from the 8-port Netgear switch, the errors stopped. And no, it's not the switch itself because the NAS is still connected to that same switch.

I don't know how (bad Ethernet cable from the switch to the 4900?), but just getting the Epson off the network seems to have been the solution. Or, the port the Epson was plugged into on the switch is indeed bad.

Whatever the case, the problem is gone.
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
#$*!@% Wrong. All seemed fine for about a week. As soon as our other person logged into the server from the 2018 Mac Mini, and opened an image in the same folder I was in, I instantly got messages I couldn't save my file.
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
Alright, we have it completely narrowed down. You can be on the server or shared drive at the same time and no one will have any problems working on and saving their files - as long as you're not in the same folder.

The trigger is always Mojave. If that is the OS in use on any Mac, simply opening a folder someone else is already in locks everyone out, including yourself. You can sometimes save your file, and other times you're told it's in use by another application. Which is wrong since you're the only one with a file open in that folder.

A message that you can't save the file is almost always accompanied by a hidden file that gets orphaned. Such as .afpDeletedxxxx.psd . The xxxx being a seemingly random number.

I say Mojave is specific here because that's when this issue appeared. We've been working off of our NAS for over 2 years with zero issues of users working out of the same folder. Nothing else has changed.

The only remaining question is - is this an Adobe issue, or Apple?
Photo of Jeffrey Tranberry

Jeffrey Tranberry, Sr. Product Manager, Digital Imaging

  • 15632 Posts
  • 2368 Reply Likes
Hi Kurt, Let me see if I can find someone on the team that help with this.
Photo of David Converse

David Converse

  • 747 Posts
  • 220 Reply Likes
Have you updated the firmware on all of your network devices? I've been in IT for a long time (including supporting graphics departments) and always advised against working off a server. And I've heard every argument about it. What it means is adding another big layer of things that can go wrong.

You need to do some network logging and see what errors pop up. But I've seen companies run into a combination of hardware that just plain won't work no matter what.
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
Yes, anything that has a firmware update has been.

Having been in electronic prepress for 38 + years, I've heard the arguments about not working off of a server many, many times. Every shop I've ever been in, and in our home business of the past 18 years, this is the way everyone has worked without any problems.

As noted above, we've been working off a small server in our home office for years. First with Snow Leopard Server on an older iMac. Then Lion Server updated on that machine, and finally the Synology NAS purchased two and a half years ago. In all this time, we have never had a single issue working directly off of any of these servers. This is over 10 years of server use with no problems working off of it at the same time.

At least, not until Mojave. We were working off this same NAS with a 2010 Mac Pro (High Sierra) and a 2008 Mac Pro (El Capitan), also with zero issues. We replaced the older Mac Pro with a 2018 Mac Mini. As Apple has always done, you cannot install an older OS than what a Mac shipped with.

Given all of the testing, it points almost 100% to Mojave, I'm certain I could resolve the issue completely by eliminating Mojave from the equation, but it isn't possible to downgrade the OS on the Mini.

Mind you, this isn't just the server. It's any device where you're sharing the same folder. We narrowed it down yesterday to specifically being in the same folder, and one of the Macs with that folder open is running Mojave. That person doesn't even have to have a file open. Simply opening the folder and having it be the active forefront folder on their desktop causes the lockup.

We were able to prove that by having the person copy some files we were both working from to a dummy folder on the server. As long as she was in that folder, and I in another, we could work on and save files all day without a single write error.

Given the other person didn't even have a file open suggests (to me) that the Adobe apps aren't directly the issue, but rather something Mojave is doing.
(Edited)
Photo of David Converse

David Converse

  • 747 Posts
  • 220 Reply Likes
So what happens if its a change that Apple made that they decide not to fix?
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
Then the obvious. You either can't work off the server (if the files everyone needs to work on are in the same folder), or you work in separate folders.

We were doing the latter all morning on our server. One person working on files in a folder from the Mac running Mojave, and myself in a different folder. We can do that all day without a single write error.

We also tested if both of us working in Mojave would stop the problem. Nope, it doesn't.

You can be in the same folder, but only if you're copying files out to your desktop or other folder to work on, then copy the completed files back and overwrite. What you can never do is open a file from any type of shared folder and try to work on it from there if anyone running Mojave so much as even just opens that same folder. That, plain and simple, should never happen.
(Edited)
Photo of Eric

Eric

  • 1 Post
  • 0 Reply Likes
I have been having the same issue ever since I've updated to PS CC2019 and Mojave 10.14.3. I can't save over a modified Photoshop file without me doing a Save As and giving it a new name while on the server.

What I also noticed that is very strange is that our server space had decreased by about 100GB within the past week between our small team. Normally, it takes us a long time to go through that much space. Do you know how to find and delete those .afp.deletedxxxx or .smb.deletedxxxx files from the server that you were talking about? I'm suspecting that is the culprit of the drastic decrease in space and speed after the Mojave update this past week.
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
Virtually every time you get the message you can't save a file, one of those orphaned .afp or .smb files gets left behind.

One way is to find them is to use the built in Mac keystroke of Command+Shift+. (period). That shows hidden files/folders everywhere but your desktop. Repeat the keystroke to stop showing hidden files/folders.

This is the slow way if you have to traverse multiple folders to find all of these. Instead, download the free utility, EasyFind. Launch the app. I prefer to have the settings in the left column like this for most purposes:



At the top right drop down menu, choose your server. In this case, you can search for both at once by changing the left radio button to Any Word. For the search phrase, enter:

.afp .smb

Press enter, or click the search icon at the upper right. It should list all files containing either string, which will be all of the ones you want to remove.

When the search is done, everything listed is live. You can highlight all of them and click the Delete button.
(Edited)
Photo of Janick Panic

Janick Panic

  • 1 Post
  • 0 Reply Likes
Is there any solution for this? We are working on a netwerk server here and everytime I open a document from the network server (which is an windows server) I cant save it because i dont have access.... its very annoying! 
Photo of James Hope

James Hope

  • 1 Post
  • 0 Reply Likes
Hi all. This sounds like a Finder issue that Photoshop doesn't like. I tried closing the Finder window and the file saved fine. I believe it is to do with the icon previews and the preview pane in the Finder window. I found this would happen on earlier versions of macOS (going back at least to Lion) with QuickTime files. If you turn off icon previews and the preview pane, the problem should go away.
Photo of Kurt Lang

Kurt Lang

  • 24 Posts
  • 0 Reply Likes
Yes, it's likely a Finder issue in Mojave.

We've tried all of the simple tricks like turning off icon previews. None of them help. The instant a Mojave user opens a folder, everyone else, including others using Mojave, get write errors.

We've also tested having the Mojave user close the folder. This helps sometimes, but not often. Usually, the person running Mojave has to completely logoff from the server. The instant they do, the write errors stop for the other users (assuming no other Macs running Mojave).

Also agreed, it's Photoshop for sure with Mojave. Doesn't matter what version of macOS is in use if you're writing files from Quark XPress, MS Office, etc.

The question though is still, is the issue Photoshop, or Mojave? You can be running the latest version of PS CC on all of your Macs and have zero write errors to your server or other shared folders as long as no one is running Mojave. That says to me, Mojave introduced the problem. But why is Photoshop affected and not other apps?
Photo of Pierre Lepeer

Pierre Lepeer

  • 1 Post
  • 0 Reply Likes
Have you tested ?In PS, go to Preferences, File Handling and in the dropdown menu Image Previews choose Never save.On our Macs (mojave), it solved the problem
Photo of Kurt Lang

Kurt Lang

  • 26 Posts
  • 0 Reply Likes
Hi Pierre,

Nope, that doesn't help. We made sure to set previews off in PS CC on both Macs (Mojave and High Sierra) and quit the app since you have to relaunch for those changes to take effect.

No difference at all. All the Mojave user has to do is open the same folder the High Sierra user is in - with no apps on the Mojave computer running at all - and we immediately get save errors on the other Macs.
Once the Mojave user has opened a folder other non-Mojave users are in, that person has to not just close the folder, but log out of the server entirely before the folder will be released to the other Macs. They can then log back in to server and everything behaves normally, as long as the Mojave user does not open a folder someone else is in.
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
Sheesh! It gets even more ridiculous with Mojave. We found yesterday that being in different folders isn't enough. I was working in a subfolder that was in the same parent folder the Mojave user was in. Every so often, we would each get write errors.

The Mojave user had to logout out of the server to break the locked file issue. I move the subfolder out to a different location, the Mojave user logged back in, and there were no further write issues.

And still more! The Mojave user has yet another problem only created while using Photoshop - that we can tell.

When you save changes, a .afpdeletedxxx file is created by Photoshop as a temporary image of the previous file while it writes the new version. Assuming no write issues, the .afp file is then supposed to be deleted.

Well, guess what? The .afp file is not always deleted because in Mojave and the server can't remove it! Only when the Mojave user logs out of the server can they be removed. The server then instantly deletes these files once Photoshop in Mojave is no longer holding them open.
(Edited)
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
Updated info. I applied the 10.4.4 update to our 2018 Mac Mini in the hopes that, maybe, Apple had fixed the issue. No dice.

I also retested many apps to see if they still behaved the same. All Adobe apps listed, other than Encore, are the most recent CC 2019 versions. Tested were:

Office 365 - Word, PowerPoint, Excel
Photoshop
Illustrator
Acrobat DC Pro
InDesign
Quark XPress 2018
Premiere Pro
Audition
After Effects
Media Encoder
Encore CS6
QuickBooks 2019
and a handful of third party apps

Any of these, except Photoshop, can write files over and over while a Mac running Mojave has the same folder open. You might get one or two saves in from Photoshop without an error message, but you will always eventually be erroneously told the file was left open by another app, despite the fact you are the only user with that file open, and the only person even running Photoshop.

Also to reiterate. This is not an issue specific to our Synology server. You can recreate this problem in any shared folder. Doesn't matter if it's a different brand or type of server, or even just a shared folder on another Mac. If a Mojave user accesses that folder, forget about using Photoshop in it from any other Mac, no matter what OS it's running.
Photo of KIRK FETZER

KIRK FETZER

  • 5 Posts
  • 0 Reply Likes
Kurt, may have found a solution.

I just discovered the same issue with Photoshop files saving to a QNAP TS 128A NAS. I bought this NAS to escape the same problem I was having for years with Apple Server software on every version of it since Snow Leopard or Mountain Lion (can't recall for sure). After opening and editing a Photoshop file from the server, Photoshop will say you don't have access when you go to save changes to the file. I have to save to another folder, then drag to replace the original.

I was experiencing the same problem when running High Sierra on the client computer and after upgrading to Mohave.

OPlocks was also disabled on NAS and made no difference.

I just found a possible solution to the issue. AFP seems to resolve the issue.

In testing the QNAP NAS I decided to enable AFP networking, even though all users are on High Sierra or Mohave, and Mohave dropped support for networking with AFP — though retained the ability to connect to other devices still using AFP (as I've been told in my reading anyway).

When I enabled AFP (I left the SMB enabled) and connected to the NAS via AFP, I was able to save over Photoshop files flawlessly. To test, I disabled it again and the problem returned. Enabled it again and problem went away. I'm able to open, edit and save Photoshop files again directly on the NAS.

Crazy. Seems that Photoshop requires AFP to properly register the locking and unlocking of files in use? 

Please let me know if this works for you or if you have found other solutions.

RELATED ISSUE WITH ADOBE INDESIGN FILES
I am still trying to determine the cause of one computer on my network that seems to lock InDesign files, so that all other users can only open them in Read Only mode. I've logged into the NAS as several different users and all users are part of the same group, so all have the same file and folder permissions. Other users in this group do not have this issue working on InDesign files together, but once this one computer opens an InDesign file (and doesn't even save it before closing) other users can only open it in Read Only. Watching the shared folder, you can see the temp file that InDesign usually writes for open InDesign files (the one that starts with ~) appear and disappear as usual when the file is closed. Not sure if it's related to this temp file, but but it's a reminder that the locked state of InDesign files in use, does require this writing then deleting of this temp file. For some reason this one computer still seems to cause the main InDesign file to appear as open other users — so they get Read Only when opening it. Happened whether this computer was running High Sierra or Mohave, though I didn't have time to do a clean install of Mohave. Happens whether this computer was logged into NAS via SMB or AFP too.

The only solution to the InDesign issue I can find with this one computer is to log off the shared folder on the NAS. Once I do that with this one computer, others can open the InDesign files normally. Even logging off and right back on to the shared folder will resolve the issue with files.
(Edited)
Photo of KIRK FETZER

KIRK FETZER

  • 5 Posts
  • 0 Reply Likes
additional testing with success:

Turing off Preview in Finder (as someone mentioned for Photoshop issue) on the specific computer that's generating InDesign files that are locked to all other users, resolved the issue.

This problem computer is running Mohave and causing InDesign files to be locked to all other users, once the file is opened, edited and saved OR even just opened and closed immediately without any changes or saves.

Turning off Preview (View > Hide Preview) in the Finder solves the issue. Turn back on and issue returns. Turn back off and issue resolved again after opening and saving any edit to the file.

FIX 2: If the problem computer edits the file name in the Finder, it seems to refresh the file's lock status on the server others can then open the file normally without being in Read Only. So just adding a space in the file name by the problem computer, solves the issue with the file for other users. I think this makes sense if the theory is that the file's status needs to be refreshed by the computer that is still holding on to access to the file even after it has been closed. Given that I only have one out of four Macs causing this issue with files and all are working out of the same NAS folder, I think it points to the OS on the one computer.

I was having the same problem when running High Sierra on this one computer and users were getting Read Only InDesign files on their High Sierra and Mohave computers.

Will try a clean install of the OS on this one computer.
(Edited)
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
Hi Kirk,

Thank you for the time you took testing and posting here. Unfortunately, it doesn't help. AFP is already what we use.

We've tried both AFP and SMB. Neither works if more than one user is in the same folder, and one of those users is running Mojave.

For a single user, it makes no difference what connection or OS you're using. It always works. At least for us it has. For multiple users, we've had various mixes of OS X and macOS accessing the NAS, and there was never an issue until Mojave.
Photo of Giuliano Drago

Giuliano Drago

  • 9 Posts
  • 1 Reply Like
Hi there,

also trying to debug this issue using samba running on Univention UCS 4.4:

path = /mnt/share
vfs objects = acl_xattr recycle catia fruit streams_xattr
msdfs root = no
writeable = yes
browseable = yes
public = no
dos filemode = yes
hide unreadable = no
create mode = 0774
directory mode = 0774
force create mode = 00
force directory mode = 00
locking = 1
blocking locks = 1
strict locking = Auto
oplocks = 1
level2 oplocks = 1
fake oplocks = 1
csc policy = manual
valid users = ...
nt acl support = 1
inherit acls = 1
inherit owner = yes
inherit permissions = yes
recycle:versions = yes
recycle:touch_mtime = no
recycle:touch = no
recycle:keeptree = yes
veto files = /._*/.DS_Store/.AppleDB/
delete veto files = yes
map acl inherit = yes

will see if issue disappears using veto files.
I've already tried disabling all locking / oplocks etc... no luck

(Edited)
Photo of Darren J

Darren J

  • 3 Posts
  • 1 Reply Like
We encountered a similar issue using a Windows DFS path and NTFS permissions. Ownership of the file/folder was an issue, we're using Active Directory, so I set the AD Group to have ownership of all files/folders in the share. 

I disabled the Save Previews option which then allowed users, all Mojave, to save to the DFS path without problems. We created files, had someone else open them, edit them, save them, had the original users re-open, edit, save, etc. 

Ensure your ownership permissions are not tied to the owner/creator, but a group. Perhaps it'll help your issue as well?
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
@ Giuliano

Not sure how many of your listed options the Synology has, but I'll take a look when I have time to see if any of these may help.

@ Darren

We tried all of the preview saving tricks. None of those helped. BUT!, I went back in to check the permissions, and while I don't know how it got changed, the group read/write permissions were off! Instead, all of the individual read/write permissions were on.

I'll change those around and test later. Thanks for jogging my brain on that one! Weird that having them backwards didn't affect anything but Photoshop.
Photo of Darren J

Darren J

  • 3 Posts
  • 1 Reply Like
Prior to modifying my own permissions, I noticed that only the local DFS server had write access. Creator/Owner had Full and Local Admin/Users had full, but there wasn't a single domain permission configured. This was odd because domain users could still write files, likely due to the share permissions being set to "everyone full", though the NTFS permissions were missing domain groups.

Once I corrected it, things have been stable. 
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
Nuts! Same thing. All individual user permissions to the server off, and only the group on with read/write access. Same, instant issue if anyone from a Mac running Mojave opens the same folder.

The person I had testing with me hadn't even opened the dummy file I had in it to see if we could work out of the same folder. I had done just a couple of 2 second changes to a separate image and tried to write it back. Same nonsense about not being able to save, or was left open by another user.
Photo of Giuliano Drago

Giuliano Drago

  • 9 Posts
  • 1 Reply Like
can you list all the dot files created when the file is opened?
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
They're always (as noted above), .afpdeletedxxxx files. The x's being a number. If you're connecting as SMB, then they're .smbdeletedxxxx files.

If accessing the server (or a shared folder) from any Mac not running Mojave, these temporary write files immediately disappear after the write of the new data has been verified.

If you're using Mojave, these can stack up to quite a few copies, all with no errors generated to the Mojave user - as long as no one else opens that folder. They'll sit there until the Mojave user logs out, then are immediately deleted by the server. Something the server has likely been trying to do all along, but can't until either Photoshop, Mojave itself, or a combination of both are no longer holding them open.

I'm leaning toward the last since this literally only occurs when Mojave is the OS in use. Why it affects only Photoshop, I don't know.
Photo of Darren J

Darren J

  • 3 Posts
  • 1 Reply Like
We used to use this middleware software that is now owned by Acronis. The old name was "Extreme Z" and now it's called "Acronis Files Connect"

The software allows you to present AFP shares off of Windows (or other) SMB servers. It also handles and tracks all file locks handled by the user. 

They offer a 30 day trial, you could potentially use this to determine where the lock is coming from.

(Edited)
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
Thanks for the lead, Darren. Definitely not something this small business is going to purchase with a minimum $800 fee for three years of usage.

But as you note, the free trial could at least be used to see what is specifically causing the lock.
Photo of Giuliano Drago

Giuliano Drago

  • 9 Posts
  • 1 Reply Like
Hi,

I've added the .smbdelete_* files to the veto files:

[graphics]
path = /mnt/share
vfs objects = acl_xattr recycle
msdfs root = no
writeable = yes
browseable = yes
public = no
dos filemode = yes
hide unreadable = no
create mode = 0774
directory mode = 0774
force create mode = 00
force directory mode = 00
locking = 1
blocking locks = 1
strict locking = Auto
oplocks = 1
level2 oplocks = 1
fake oplocks = 1
csc policy = manual
valid users = ...
nt acl support = 1
inherit acls = 1
inherit owner = yes
inherit permissions = yes
recycle:versions = yes
recycle:touch_mtime = no
recycle:touch = no
recycle:keeptree = yes
veto files = /._*/.DS_Store/.AppleDB/.smbdelete*/
delete veto files = yes
map acl inherit = yes

see here: https://www.samba.org/samba/docs/using_samba/ch08.html 

regarding the AFP middleware thing I don't understand how this would fix the issue, as AFP seems deprecated, see here: https://apple.stackexchange.com/questions/285417/is-afp-slated-to-be-removed-from-future-versions-of-macos

open implementation of AFP is still mantained http://netatalk.sourceforge.net/ so if needed, it's possible to have native afp shares (we where using it till last year).

I'll keep you updated on the issue.

(Edited)
Photo of Giuliano Drago

Giuliano Drago

  • 9 Posts
  • 1 Reply Like
I've opened a case to Univention support, let's see. We are on UCS 4.4 and samba 4.10.1
Photo of Giuliano Drago

Giuliano Drago

  • 9 Posts
  • 1 Reply Like
So we managed to replicate the issue and it seems related to the preview (with Office 365 the bug was even worse, leading to data-loss). 
See here:
https://apple.stackexchange.com/questions/173784/photoshop-on-mac-could-not-save-file-because-write-access-was-not-granted
Photo of Giuliano Drago

Giuliano Drago

  • 9 Posts
  • 1 Reply Like
FINALLY SOLVED: trick is to mount with cifs:// instead of smb:// when you click on go > connect to server. This forces the connection to SMB v1 (this setting can also be adjusted via terminal in /etc/nsmb.conf:

protocol_vers_map=2 >> sets SMB Protocol 2
protocol_vers_map=1 >> sets SMB Protocol 1
Photo of Jerry Horn

Jerry Horn

  • 4 Posts
  • 0 Reply Likes
I have tried that and was getting same result. Not if server allows SMB1 though. It might default to SMB2 or 3. I have to check. I perform a lot of testing, though, on a NAS as well. It appears the first save always works but any additional save shows the permissions error.
Photo of Kurt Lang

Kurt Lang

  • 28 Posts
  • 0 Reply Likes
For us, while we do occasionally see a write permissions error message, most of the time it's that the server thinks someone else has the file open, even though no one does.
Photo of Jerry Horn

Jerry Horn

  • 4 Posts
  • 0 Reply Likes
Exactly right. This does not happen in Windows. The Mac will somehow keep the file open, when it is selected in the Finder or possibly in Adobe Bridge as well. Since Bridge tends to create a preview also.
Photo of Kurt Lang

Kurt Lang

  • 28 Posts
  • 0 Reply Likes
And not even selected. All a Mojave user has to do is open the folder someone else is working in and everyone else instantly gets messages the files are in use.
Photo of Cristen Gillespie

Cristen Gillespie

  • 1661 Posts
  • 546 Reply Likes
> The Mac will somehow keep the file open, when it is selected in the Finder or possibly in Adobe Bridge as well. Since Bridge tends to create a preview also.>

That sounds like the problem I have with Finderland thinking an external drive is being used by one of my computers and refusing to let me take it offline, even though that's not true. But it was—earlier. If I remember to shut down Bridge on both computers, there's no sharing, apparently, and I can take a drive was in use offline.

I didn't have this issue until I upgraded one of my computers to High Sierra. Before that, no problem. After that, it's a frequent  annoyance when I don't notice Bridge is still running on either one of the machines. Shutting Bridge down after the fact doesn't get the Finder to release the drive, either. Only after a restart can I take the drive offline.

And here I thought my computers had just gotten too old and deaf to hear each other.<G>
Photo of Giuliano Drago

Giuliano Drago

  • 9 Posts
  • 1 Reply Like
looks like Apple really doesn't give a *** about all this issues... afp is not mantained anymore, samba compatibility is broken (you can find samba everywhere, even on expensive nases) and their server has almost no features and 1 star reviews. One way that i didn't test is to mount something like iscsi or use webdav (owncloud for example). For the moment is mitigated, at least for us... till the next messy update ;)
Photo of Kurt Lang

Kurt Lang

  • 28 Posts
  • 0 Reply Likes
I reported this issue with Mojave early on as a severe bug. Two point releases later, and no fix. The report is still open. That can either mean they're still working on it, or haven't started yet. What I have noticed in at least the last three reports I've posted, they get fixed in the next major OS release, but not the one you reported it under.

Yes, I agree that Apple doesn't give a hoot about AFP anymore, and we figured switching the connection to the NAS as SMB would likely solve the issue, but the only thing that changes is the name of the locked, hidden files. So we went back to AFP because that supports file name characters SMB doesn't. Characters our main client likes to use a lot.
Photo of Giuliano Drago

Giuliano Drago

  • 9 Posts
  • 1 Reply Like
As I am running on Univention 4.4 (based on debian 9) I have such an old version of netatalk in the repos that it's not even supported anymore from the clients... if you tell me that you have the same issue also with afp, then even trying with netatalk would be pointless. Let's hope they fix this... fileshare with smb is a thing for at least 20 years now 
Photo of Douglas Powell

Douglas Powell

  • 1 Post
  • 1 Reply Like

I’m experiencing almost the same problem that Kurt Lang is experiencing. Just having the folder open does not cause the problem saving on my servers, if Icon preview is turned off. But, if a user has icon preview or column preview or gallery open from a Mojave Finder, the server declares the file as open. The strange thing that when the user closes Mojave Finder it takes 2 and half minutes for the server to release the open files. If the user has all previews turned off and double clicks on the image, it opens in Preview but as soon as Preview is closed the server releases the open file.

 

I’ve also seen the exact same problem of my servers saying that a user has a folder open when they don’t even have the Finder open. It only releases the folder after the user logs off the server. I’ve tested this with 2 different servers. One NAS that we connect SMB to and the other we connect AFP. They both have slow release times from the Finder preview. The AFP server (using ExtremeZip) does not show open folders, it only show open files. So I’m not sure if the AFP server holds the folders open until logout.

 

The testing I’ve done shows that it is a Mojave Finder problem and it exists across both SMB and AFP protocols.

 


Photo of Jerry Horn

Jerry Horn

  • 4 Posts
  • 0 Reply Likes
I've also experienced the same issue in Mojave 10.4.4 except I didn't have the slow release times. My release times were just a few seconds. I'm using a QNAP NAS and MS Server 2012. Mac's connect through SMB.

I did not experience this same issue in High Sierra 10.3.6.
Photo of Kurt Lang

Kurt Lang

  • 30 Posts
  • 0 Reply Likes
Ok, I get that it's easy to to "Like" a post that agrees with yourself, but everything Douglas Powell states is a mirror of what we see.
The testing I’ve done shows that it is a Mojave Finder problem and it exists across both SMB and AFP protocols.
Yes, High Sierra caused no issues here at all, or any mix or Mac OS releases as long as Mojave wasn't one of them.

When you really get down to it, the problems are in this order:

1. Mojave is the root of the issue. None of this occurred under any previous OS release on any server or shared folder.

2. While Mojave is the main culprit, why is Photoshop the only app that has this problem? What is it doing differently with its file handling no other app does?
Photo of Giuliano Drago

Giuliano Drago

  • 9 Posts
  • 1 Reply Like
with office 365 + preview and Mojave you even have data-loss: the original file disappears after the creation of a bunch of tempfiles!!!  fixed with a script, see here https://help.univention.com/t/problem-data-loss-with-mac-os-x-and-office365-using-an-ucs-share/11914
Photo of Kurt Lang

Kurt Lang

  • 24 Posts
  • 0 Reply Likes
Yikes! That's bad.

We don't normally work off our server with any Office apps. We only did about 30 minutes of testing with Word, Excel and PowerPoint from a Mojave and High Sierra Mac out of the same folder to see if any type of file issues would show up. None did, but that was a limited amount of testing.
Photo of Jerry Horn

Jerry Horn

  • 4 Posts
  • 0 Reply Likes
I have even seen a similar issue with Office 2011 for Mac, particularly using Excel. You would open a spreadsheet from a server, make changes, and work on it for awhile, then when you go to save it you cannot. You would typically see the permission error or just cannot save error. Office 2016 for Mac seemed to clear this issue, though. But I wouldn't really trust using Excel and files off the server.

Photo of Ben Toms

Ben Toms

  • 1 Post
  • 0 Reply Likes