MB

7 Messages

 • 

180 Points

Wed, Jan 20, 2021 8:05 PM

Closed

Lightroom Classic: breaking images on NAS during import into catalog

I have been successfully using LrC to manage my photos collection since the times of the beta and storing them on network shares for countless years. Everything worked perfectly until December 2020 but now the RAW files from my Sony A7RIV are broken when I attempt to add them to the catalog (regardless if they are on the NAS already or copied during the process). This is a major issue, both because the ORIGINALS are compromised and because I have no way to store my images safely.

The issue is affecting regular images with lines and completely breaking the pixel shift ones. By the way, I combine pixel shift images with PixelShift2DNG.

You can find a picture I imported last year and one broken by the current version of LrC at this link (public Dropbox folder).

Thanks

Accepted Solution

7 Messages

 • 

180 Points

1 y ago

Today I experimented a bit with my NAS configuration and the conclusion is that by limiting the SMB compatibility to SMB3 and allowing symlinks (this one may not be the reason, but you never know and I did not test it) the import resumed working flawlessly.

The question, however, remains and it would be fantastic if anyone could explain why the files were (or still are) tampered with during the import into the catalogue.

I hope this will be useful to anybody else experiencing this problem.

203 Messages

 • 

1.9K Points

1 y ago

All the DNG in your dropbox folder seems very big 500Mo when the uncompressed RAW for this camera should be 120Mo. Have you try to import but not on the NAS ? Why do you think that the problem is Lightroom ?

7 Messages

 • 

180 Points

These are pixel shift images, hence the size. LrC does something to the originals during import. If they are on the Mac SSD they work fine, while on the NAS the result is what you see from the shared files. The files are corrupted even for DxO PL not only LrC or CameraRaw

Champion

 • 

1K Messages

 • 

15.9K Points

Sounds more like a NAS issue.

7 Messages

 • 

180 Points

Why should it be? The real question is WHY does LrC TAMPER the original files while adding them to the catalog? I hope somebody from Adobe notes this BUG, because as of today it is impossible to file a Bug report, which is incredibly frustrating. Working with Topaz and DxO is completely another story.

7 Messages

 • 

180 Points

In the rush of my frustration (I am not able to work as I would like) I forgot to mention that I am running the latest versions of LrC and MacOS and my shares are on a Synology NAS (SMB).

Champion

 • 

1K Messages

 • 

15.9K Points

1 y ago

You said the following

If they import and don't corrupt when using the SSD but corrupt when using the NAS then that seems to indicate a NAS issue.

Adobe Administrator

 • 

563 Messages

 • 

10.2K Points

1 y ago

I imported the sample images you provided from a NAS without issues? What happens when you import? Does it throw any error messages?

thanks,
Sunil

7 Messages

 • 

180 Points

Thanks, Sunil, much appreciated. Try importing them to a NAS share. If they are successfully imported, could you please share the protocol you are using? Moreover, is anybody able to tell me the difference between the corrupted image and the fine one? Why does LrC modify my originals while adding them to the catalog? The error message pops up after the import, when LrC fails to build the smart previews.

Champion

 • 

1K Messages

 • 

15.9K Points

1 y ago

Beings you are using DNG files, if you have an Import Preset for Metadata and/or Develop Settings and have "Automatically write changes to XMP" CHECKED in Catalog Preferences than the DNG file will be "Tampered" with.  

RAW files are never written to except the condition where you change the Capture Date and allow the change to be written to the RAW file.  

7 Messages

 • 

180 Points

Thanks, Robert, this is interesting. However, both options are inactive and my files are tampered with despite I did not change anything.