Enhance function gives batch error (sometimes) on NFS drive

[Stein99]

I store my photos on an NFS drive. The LrC catalogue is local on my Mac Studio. This works perfectly in Lightroom when importing and editing pictures, but there seems to an issue with the Enchance function (denoise).

Sometimes when I run Enhance (from Develop module in LrC), it gives me an error at the end of the processing - typically when it is about to write the new DNG file to disk. It says that it "cannot write" and then gives the filename of the file I am currently editing. It does not state the filename of the DNG but the name of the actual original that I am enhancing. So it seems that it is somehow trying to update(?) the original file as well.

When this happens, it creates a temporary collection with a name similar to "Batch error" (can't remember exact name) and adds the image I was trying to enhance to this collection. No DNG file was created.  There are no issues with this when I have photos locally - just when I have them on the NFS drive.

I suspect LrC will try to obtain some lock on the original file, and it cannot do this properly and then fails. It seems that the Enchance function is running as a separate (batch) process, so there might be issues when both main LrC thread and Enhance thread tries to access same picture file - e.g. if LrC main thread has lock on this file, and then Enchance batch job tries to lock/update it.

This issue is very troublesome, because I wish to store my photos at my network server, but I have troubles using Enhance function on these photos. Sometimes it works, but when it fails I need to unmount network share and remount it for it to work again. No other Lightroom functions or other applications on my Mac has this issue.

Lightroom Classic 12.5

Mac Studio - latest OS.

[Jao vdL]

NFS support in Mac OS hasn't been updated in many many years. I would very much hesitate using it and I doubt that even if you find what causes the bug, APple would update their support. You are far better off using smb on your server than nfs. 

[Stein99]

NFS is working far better than SMB on Mac. I started with SMB, but that was really bad on Mac. It is much much slower when eg browsing folders with lot of files. It was really a nightmare when e.g. syncing folders, because listing of files took long time. NFS has been working really well except for this issue with enhance. I think it should be fixable from LR - I do not expect Apple to fix it. 

[Jao vdL]

This really is an Apple issue. They haven't really supported and updated NFS in a very long time and the code they use is ancient. It is surprising they still include the deamons as the nfs security model is not compatible with Mac OS X anymore and so very hard to get to work reliably and it really isn't officially supported anymore. Apple's SMB support is not extremely good either (not as good as what windows has built in obviously) but it is very fast on my machines and very reliable including file listings. It easily saturates my 2.5 GbE connection to my NAS and probably will a 10 gbit connection but I don't have the hardware for that. It is also the only still fully supported local filesharing protocol that they have after they deprecated Apple Filing Protocol. If you have problems with it, it is usually a samba setting on the server. 

[Stein99]

I can promise you that I've tried and explored SMB a lot on my setup. Google Mac, SMB and Unraid server and you will see the issues people are having. NFS is behaving much better when working with lot of files in a subfolder structure. And it is not related to network speed. 

[Stein99]

I can also mention that when I used SMB instead of NFS, the import process in Lightroom would suddenly just stop. I imported e.g. 700-800 images, and then the whole import process just halted and never finished. NFS has been serving me well - except this issue with Enhance - which I suspect is some locking issue.

[Stein99]

The issues are similar to this:
https://discussions.apple.com/thread/254805549

[johnrellis]

"It says that it "cannot write" and then gives the filename of the file I am currently editing. It does not state the filename of the DNG but the name of the actual original that I am enhancing. So it seems that it is somehow trying to update(?) the original file as well."

I think that's a buglet in the error message -- it meant to say the name of the DNG, not the original file.  There have been other reports about this, where it was clear that it was the DNG that couldn't be written.

[Stein99]

Ok thanks. But why can't it write the file? There are no issues with writing files e.g. when I do "Edit in..." and it makes a copy of the original file. Just this Enhance writing...

[johnrellis]

"But why can't it write the file?"

I don't know -- LR is very bad at not giving the details about file errors.  

Ensure LR is granted Full Disk Access (not Files And Folders) permission:
https://community.adobe.com/t5/lightroom-classic-discussions/quick-tips-how-to-give-full-disk-access...

Without Full Disk Access, LR can do all sorts of screwy, intermittent things. 

Others have reported getting the same error message from Enhance and not being able to solve it:

https://community.adobe.com/t5/lightroom-classic-discussions/enhance-errors-denoise-ai/m-p/13932788

[Stein99]

This is network share - so full disk access would not apply. Permissions are OK - everything else works fine.

The bug is also "random" - sometimes it works, sometimes it doesn't. 

[johnrellis]

Is Full Disk Access set? It can affect LR's access to any type of file volume. As the Adobe article says,

"Since macOS 10.14 (Mojave), Apple introduced a new privacy structure to help ensure that all applications obtain user consent before accessing documents, downloads, desktop, iCloud Drive, and network volumes."

When it's not set, all sorts of screwy, intermittent problems have been reported.

[Stein99]

Yes, it is set OK.

[Stein99]

I have tried now to set NFS v3 instead of v4, and set the option of "locallocks" to see if there are any difference. The locking scheme was totally rewritten in NFS v4, so there might be something there.