Editing Picture Metadata or File Name Not Working Properly

When working with jpeg files if I do simple things like rename them or edit metadata, an error dialogue box comes up that looks like this:

photo error.JPG

It will not show the renamed file unless I leave the folder and return. It is as if explorer loses connection with the WD drive for a moment.

Other files like word docs etc do not exhibit this issue.

This issue will prevent me from using any photo editing software so this is a go/no go proposition as to whether or not I keep this drive.

Well, check if your photo editing software supports working off network locations using the EXT4 file system. If it doesn’t, then you won’t ever get this fixed with that software.

Hi. Thanks for your response. Unfortunately, this happens right in explorer if I right click and rename the file. In fact the image in my post came from that exact scenario. No editing software involved.

Just FYI, I can reproduce this as well.

I am oddly glad to hear that as this means it may not be unique to something in my network. This is my first time posting on this forum…so what happens from here? Is there a way to get this escalated for review?

Your best bet is to open a tech support case with WD.

I did some research on this overnight, and I suspect that we’re hitting a SAMBA bug:


Looking at the Samba logs on the Cloud, the appearance is the same – Samba panics and restarts.

Even though the bug was “fixed” in January, the Cloud is using Samba 4.0.0rc5 (which means “release candidate.”)  So the Samba library the Cloud is running a version over a year old  (rc5 was released November 13, 2012.)   That was a surprise to me…

Thank you for your help.

I know this is an old thread, but I wanted to add a little documentation if people find this in a search.

If you log into the Cloud via SSH and examine the Samba logs, you might see this:

[2013/12/02 17:21:28.401135, 0] (dbwrap_check_lock_order)
  Lock order violation: Trying /var/run/samba/smbXsrv_open_global.tdb at 1 while /var/run/samba/locking.tdb at 1 is locked
[2013/12/02 17:21:28.401776, 0] (debug_lock_order)
  lock order: 1:/var/run/samba/locking.tdb 2:<none> 3:<none>
[2013/12/02 17:21:28.402267, 0] (smb_panic_s3)
  PANIC (pid 19326): invalid lock_order
[2013/12/02 17:21:28.403141, 0] (log_stack_trace)
  BACKTRACE: 0 stack frames:
[2013/12/02 17:21:28.403782, 0] (dump_core)
  Exiting on internal error (core file administratively disabled)

 If you do, then we’re very likely seeing that same bug.

A PANIC is a no-no in Linux, but core-dumps are disabled on the Cloud so it’s not possible to get a full stack trace to compare.