Skip to main content
Inspiring
May 15, 2019

P: Issues exporting photos to a Network Drive

  • May 15, 2019
  • 150 replies
  • 2980 views

Since I upgraded to V8.3 of Lightroom Classic I can no longer export my files to our Synology Network System, I get the following error message "The specified folder in not writable"

After contacting support they were not able to resolve my issue, they maintained that it is a network issue on my side. I could not find any answers here or anywhere on the internet and decided to report this issue.

Because I share my processed photos with the rest of the office, my only solution was to un-install V8.3 and go back to V8.2.1, by doing that it resolved my problem.

So yes Adobe you have network issues in V8.3 as version 8.2.1 works perfectly when saving files to a network drive.

This topic has been closed for replies.

150 replies

Inspiring
May 22, 2019
"Everyone using v8.3 with a NAS (seems like mostly Synology NAS) is seeing this problem, why don't you?"

I'm guessing the folks at Adobe would love it to be that simple.  Trouble is, that's not the case.  I'm using 8.3 on Win10 with a Synology NAS and can't replicate the issues.
Participant
May 22, 2019
This is obviously a regression caused by a change made between v 8.2.1 and v 8.3 and it's in the permission checking code that is bypassed by selecting the "choose folder later" option.
Everyone using v8.3 with a NAS (seems like mostly Synology NAS) is seeing this problem, why don't you? Obviously not the NAS since it works fine with v8.2.1!
Participant
May 22, 2019
Yes, when googling this problem I saw that in version 6 they had the same problem. Obviously no regression testing is being done...
GoldingD
Legend
May 22, 2019
Is it limited to NAS? in the various discussions at the customer forum, non NAS users are reporting the issue . Ok, supposedly not NAS users. incidentally, Not a NAS user, not having the issue.
One of the six or so threads: https://forums.adobe.com/thread/2621939
Participating Frequently
May 22, 2019
The reason why we're being asked a bunch of information is clearly that they're missing that key piece to identify why it works in their test environments and not ours.

I've seen bugs that we know exists, but we could not root-cause for months. In that example, it was code that was working on Linux with case-sensitive filesystems that did not play well with OSX's case-aware filesystem. Without that information, we can observe the misbehaviour but never quite know why it was misbehaving.

I have been just tracking down deadlocks at work for a few weeks, and initially I had a snowball's chance in hell in finding it. Without some critical information, again, we would only know that something is wrong but not where it might be.

Depending on how they structure their release, a minor version bump could have hundreds or thousands of commits between 8.2 and 8.3. You might say, oh why not just git bisect and it should be found with 10 tests with a binary search of the first defective commit. But that hinges on being able to actually reproduce the problem. *That* is what they really need to locate it. If they can't reproduce that issue themselves, just purely staring at the code won't help much. I had been staring at code for the deadlock I had been chasing for a week and all that gave me was eye strain.

It's easy to vent because it's frustrating and appears to be a simple issue. Heck, I had given a smart-aleck comment already. And frankly I myself do have lots of choice words about testing, it's my bread and butter afterall. But doing that alone won't help jack. We think it's easy, because it's a "network drive", but there are at least two major protocols (SMB, NFS), a handful of versions each, and different server providing the protocols. The number of combinations goes up fast, even if someone is quite dedicated in setting up all the test beds to cover as much as one can. There is no such thing as 100% coverage.

Believe you me, I'm not particularly happy about this bug, but the quickest way to solve it is to provide information. One of these would be the key to help RCA the bug and get it fixed.

@8510810 incidentally a casual glance suggests a lot of consumer grade NAS ran into issues. They're probably running some version of Samba. Mine is a hand-rolled server running Samba 4.1.22 (I know it's ancient...)
Inspiring
May 21, 2019
For me, I can export locally, but I cannot export to a Synology DiskStation (which has worked fine until LR 8.3).  On my wife's computer, which was still running 8.2, I exported to the DiskStation.  I upgraded LR to 8.3, and got the "folder is not writeable" message.  I wrote software for 25 years before retiring.  Something changed in 8.3 that broke exporting for many of us.
Inspiring
May 21, 2019

Same here. It is obvious there are no issues with permissions for drives or folders because even Lightroom can write to a folder as soon as so select the folder later.






yvondaigle
Inspiring
May 21, 2019
I received this from Adobe, this morning:
Hello Yvon,
Greetings from Adobe!
Thank you for your response, You can continue start working in the older version which
is 8.2, we will let you know on our next update if the issue get fixed in the 8.3 update.


Thanks&Regards
Adobe Support
Inspiring
May 21, 2019
Is there any update on this issue?
Victoria Bampton LR Queen
Community Expert
Community Expert
May 21, 2019
Hey Patrick. I really do understand the frustration, probably more than most, because I get to spend my days listening to people (understandably) complain about things I can't fix. 😞
Victoria - The Lightroom Queen