Hi folks, I’ve been stung by the inability of Adobe Lightroom Classic to import files directly onto a TrueNAS-backed Samba share.
While I’m still not sure what blocks imports (it appears Lightroom keeps trying to create a folder named TempParent despite having already created it!), I did notice that I cannot even create a new directory on the share, through Lightroom, unless I enable ea support = True on the share by manually editing smb4.conf and SIGHUP.
Is there any particular reason why EA support is disabled and not available to be enabled through the UI? The default was turned on in Samba 4.9 because of compatibility issues (here I would put a link to samba-technical, November 2020, from Ralph Boehme, in the thread «about “ea support” parameter» — since I can’t provide a link, the description should do) so I’m surprised this is forced-off.
Thanks!
Diego
Yes. It’s disabled because it has a profound negative impact on directory listing speed. Historically, MacOS will write this info to alternate data streams (and never wrote to OS/2 EAs). What version of MacOS is this? If it’s a new version, then it sounds like apple introduced a bug into their SMB client (this happens).
Not macOS, it’s Lightroom (and only Lightroom as far as I can tell) on Windows 11.
Any chance to get an advanced, breakglass, here-be-dragons option in the future? I’m not sure what else Lightroom is doing to make this not work (or how it even does seem to misuse the filesystem APIs to corner itself in this position!), but at the very least, without EA it just fails to recognize directory creation succeeded, and throw an error.
Ah. I mixed up products. Apologies. Sounds like either an adobe bug or a Windows configuration issue. I haven’t heard this reported before. SMB servers and filesystems in general on Windows advertise whether they support OS/2 EAs, and the kernel should respect this / handle gracefully.
Do you have WSL and such enabled on your client? IIRC in modern windows this is only subsystem that actively tries to write EAs. Maybe also look at what EAs are written server-side. It would be useful to know what the client wants to put there.
Nope that Windows install has no WSL installed.
I have a feeling that Adobe is bypassing the kernel and attempting to implement the protocol itself.
I haven’t had a chance to set up a lab and figure out what the actual requests it sends are, I’ll try to get to it some time later this month.
But the likeliness of me getting Adobe to fix their client side behaviour is… nil 
Hmm… I’ve seen a lot of these sorts of issues that are related to client-side configuration on Windows. If you want to you can use attr -l to see what was written to the file on the SMB share:
root@bobnas[/mnt/dozer/SHARE]# attr -l '[MS-GPFR].pdf'
Attribute "DosStream.com.apple.quarantine:$DATA" has a 58 byte value for [MS-GPFR].pdf
Attribute "DosStream.com.apple.lastuseddate#PS:$DATA" has a 17 byte value for [MS-GPFR].pdf
Attribute "DosStream.com.apple.metadatakMDItemDownloadedDate:$DATA" has a 54 byte value for [MS-GPFR].pdf
Attribute "DosStream.com.apple.metadatakMDItemWhereFroms:$DATA" has a 154 byte value for [MS-GPFR].pdf
Attribute "DOSATTRIB" has a 24 byte value for [MS-GPFR].pdf
^^^ example of output locally on TrueNAS SCALE.
This should give an idea of what’s happening regarding SMB EAs. EAs will be written without the DosStream prefix. (note DOSATTRIB is not an EA here).
NOTE: this is not TrueNAS specific. There are many SMB server implementations that disable EA support by default (for example Solaris / Illumos did this).
Maybe I don’t understand the issue here, but do you mean that LR Classic won’t import new camera images to its database of pictures that are currently stored on a letter-mapped drive connected via Samba to a TrueNas server?
I have had this working for several years, through Windows 10 and now 11, with the server on Core 13.3-U1. This includes LR doing its expected behaviour of creating new date-labelled directories on the server to accomodate the new imported images. I have also been able to do this manually from time to time.
In LR setup terms, the only thing I read that it’s not a good idea to do, is store the image catalogue and metadata files on the server; these should remain on the PC in LR-defined filepaths on the local drive. Could this be part of the problem you’re experiencing?
Unfortunately I don’t have time to put this into “laboratory conditions” to play more with it until this coming weekend at the earliest. I’ll try to get a full trace of what calls get through when creating a new folder with Lightroom specifically.
NOTE: this is not TrueNAS specific. There are many SMB server implementations that disable EA support by default (for example Solaris / Illumos did this).
I’m sure that is the case — but I’m just surprised by the diametrically opposite point of view on this between TrueNAS and Samba, without a break-glass option. I totally get the reason why this is disabled by default, but I would have expected an advanced setting to enable this (“High Compatibility” preset, maybe?)
do you mean that LR Classic won’t import new camera images to its database of pictures that are currently stored on a letter-mapped drive connected via Samba to a TrueNas server?
Letter-mapped, or provided with UNC address, both fail the same way. So appears to be the case when using MountainDuck 5.
I have had this working for several years, through Windows 10 and now 11, with the server on Core 13.3-U1.
Fair, I should point out that I’m on SCALE 25.10.0.
In LR setup terms, the only thing I read that it’s not a good idea to do, is store the image catalogue and metadata files on the server; these should remain on the PC in LR-defined filepaths on the local drive. Could this be part of the problem you’re experiencing?
No, catalog is still local.
This has been the default in TrueNAS for about 7 years if I recall correctly and is the first time I’ve heard someone report an issue related to the parameter. This is generally not a problem because SMB servers advertise what features they support and which ones they don’t support. We don’t advertise supporting OS/2 xattrs and so generally clients and applications will not error out on this because it’s not surprising. There are many filesystems presented over the SMB protocol that do not support OS/2 xattrs.
2 Likes
I’d be surprised (but not so much) if I’m the first person with the combination of Lightroom, stubborness, and experience with Samba
I can’t link to the post, but there’s a post on Adobe’s Community titled «Lightroom won’t move folders to network drive» from 7 years ago where someone says
Lightroom has always had trouble manipulating files on networked servers on both platforms even when it works just fine in Finder/Explorer. This is nothing new and you’ll find many threads here with people having major problems with NAS storage.
And given even the reaction on Threads when I was “what the heck is going on?” was “Oh LrC is not compatible with most NAS, you may need a new one”, I wonder how many people just never had the ability to put this into lab condition to fully debug it.
Well, let me come back after I have had a chance to get a full trace, and let’s see if I can find what is stopping it from working.
1 Like
If you can PM me a PCAP of the failure condition that would probably be helpful from my side. Regardless, if adobe requires OS/2 EAs for their application they should be checking whether the filesystem actually supports them and raising an error rather than erroring out like this. This is something that’s trivial to do on the Windows side, and quite ridiculous if it’s the actual issue.
2 Likes
Ah ok - good re the local catalogue files.
I’d make a broad statement saying there are quite a few threads reporting SMB issues with SCALE 25.10.0, but you have the attention and offer of support from awalkerix. If anyone can help sort this out, it‘s them!
1 Like
So, fun, I can’t repro right now, which I can only expect to be because I updated to 25.10.0.1 (that was a silly thing to do of me, I just thought I would do it since I had to reboot my NAS to change a setting in BIOS 
)
I would assume that what was breaking me was mostly NAS-138259 — but that doesn’t explain why enabling EA got it to at least create directories — unless enabling EA disables some optimization that interacted with SMB_REOPEN?
I’ll try setting up a VM with TrueNAS 25.10.0 just to see if I can easily repro and capture a trace…
