File move issues within share - Windows 7 client, Ubuntu 14 Server

Question

We've got a setup where files are shared from an Ubuntu 14.04 server to Win 7 clients.

We're struggling with an issue moving files around sometimes. It goes something like this:

• Create new sub-folder in share and give it a name
• Attempted to move existing file on the share to the new sub-folder, probably only a few seconds after creating and renaming the new folder
• Caused error "There is a problem accessing [file name].pdf - Make sure you are connected to the network and try again"
• Error box had try again, skip and cancel options. Try again did nothing, skip closed error with no visual change to directory (target file still appeared there).
• Entered newly created sub-folder and the file had in fact moved in successfully. On return to parent directory there was no sign on the target file, i.e. it had moved to the correct place.

Not aware of anyone else accessing the project folder at the time

Summary: moved correctly but with error message.

Anyone know what might cause this or how we could go about troubleshooting this? There doesn't appear to be anything obvious in the samba logs.

Samba Version 4.1.6-Ubuntu

This particular server is set up as a BDC. The domain is samba/ldap all the way (no Windows domain controllers)

Answer 1

Try adding this to your windows machine registry using regedit:

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters

Key: "DirectoryCacheLifetime"=dword:00000000

This fixed a problem specifically for Windows 7 (not Windows 8/8.1) machines which I found with files being saved to a Samba share by printer/scanners. A new file could take a very long time (10 minutes or more) to appear in a directory listing of the Samba share by a Windows 7 client, even though it was plainly present locally. The new file could be seen immediately in Windows 7 by creating a new link to the share by a different unc (e.g. \\mysambaserver\ourshare instead of \\192.168.110.104\ourshare).

It seems likely that it was caused by a fault with SMB2, particularly or perhaps only when the file was uploaded by SMB1 (as used by printer/scanners with comparatively old built-in software for 'scan to network location').

A Microsoft ‘hotfix’ for a similar-sounding problem did not help, but this registry fix solved the problem.

Although your problem has manifested slightly differently it might be solved by the same fix, it is worth a try anyway.