Just upgraded to Synology SMB Package 4.15.13-4209 to fight Lightroom 15.4 "Broken Pipe" crashes.

Hardware & Storage Environment

• Workstations: MacBook Pro Max (M1, macOS) & Windows 11 Pro Desktop

• NAS Model: Synology DS920+

• DSM Version: DSM 7.3.2-86009 Update 3

• Lightroom Version: Lightroom Classic v15.4 / v15.4.1 (Currently parked back on v15.3.1 for data safety)

The Workflow & The Breaking Point

1. My core catalog runs locally on a high-speed internal SSD. All original RAW files, heavy Linear DNGs (HDR/Panos), and asset folders live on an SMB-mounted network share mapped via a Synology Drive Team Folder.

2. The moment I updated to Lightroom Classic v15.4 / v15.4.1, heavy transactional network writes—specifically bulk metadata flushes (Cmd+S / Ctrl+S) and file saving operations—began dropping out. This resulted in truncated file sizes, corrupted DNG headers ("file appears unsupported or damaged"), and failed catalog backups directly to network paths.

Crucial Note: Completely rolling back to Lightroom Classic v15.3.1 and restoring a catalog backup completely resolves the issue. The exact same bulk metadata actions execute perfectly on the exact same network shares under v15.3.1, proving a distinct application-level regression in how 15.4 handles network streams.

The Smoking Gun Log Telemetry?

Pulling the system logs from /var/log/messages and /var/log/samba/ on the DiskStation revealed a low-level kernel write failure at the exact timestamp Lightroom threw its error:

2026-06-19T08:36:26-05:00 DiskStation smbd[9162]: ../../source3/lib/recvfile.c:234 syno_recv_file failed(-1): Broken pipe, count=[524288] total tx/tx=[107036/107036] rwbytes=[41500/41500]

1. The Routine (recvfile.c): Samba was attempting to use zero-copy kernel optimization to stream an incoming 512KB payload directly onto the Btrfs array.

2. The Failure (Broken pipe): The client workstation running Lightroom abruptly severed the active network socket mid-transmission while the NAS was still actively listening for data.

3. Because the pipe snapped, trailing blocks were lost, resulting in truncated and unreadable file headers.

Update: Manual SMB Package Upgrade Applied

• To eliminate server-side protocol handling as a variable, I bypassed the standard, slow-staged DSM update notification and manually upgraded our SMB Service package from v4.15.13-3047 to the latest v4.15.13-4209.

• Looking through Synology's official release notes for this specific version string, three entries stand out as highly relevant to high-velocity database/asset operations:

1. The Concurrency & Rename Fix: "Fixed an issue where renaming folders from an SMB client could fail if files within the folder were modified concurrently." (Lightroom constantly flips temporary files and renames them during metadata writes).

2. Immediate Data Sync Toggling: "Added support in Advanced Settings for synchronizing data to the drive immediately upon receiving SMB client requests." (Allows forcing strict synchronization, bypassing volatile RAM caching variables).

3. Daemon Memory Integrity: "Fixed an issue where SMB Service could consume excessive memory under high-velocity streaming, leading to connection termination."

Seeking Community Opinions & Technical Insights

Now that I have updated the NAS SMB Package to v4.15.13-4209, I am testing the waters before moving back off Lightroom 15.3.1. I’d love to get the community's take on a few things:

1. Is this SMB package upgrade likely to resolve the root issue? Even though the log says Broken pipe (implying the computer dropped the connection), applications usually kill threads because they encounter an unexpected state, timeout, or lock response from the server. Do you think Synology's concurrent-write fixes will prevent Lightroom from panicking?

2. Has anyone else running a heavy photo/video workflow (specifically Adobe cataloging or high-frequency XMP flushing) seen stability improvements after moving to the 4209 build?

3. For the network engineers here: Should I explicitly toggle the new "Synchronize data to drive immediately" advanced setting to stabilize Adobe's chaotic I/O thread drops, or will the performance penalty hit bulk photo metadata flushes too hard?

Looking forward to hearing your thoughts and experiences with this specific package version!