[plug] Fwd: Samba issues
info at sbts.com.au
Fri Mar 25 01:59:56 UTC 2016
Thanks for reporting back on your unhappy journey ;-)
Interesting that oplocks was the culprit.
It may be interesting to look at another option
"veto oplock files" which allows selective disabling of oplocks using a
"fake oplocks"may also be of interest
"level2 oplocks" may have bearing on your problem as well, what was it
set to on your system?
"oplock break wait time" may be of use, but it comes with big warnings
(it works around bugs in windows handling of oplocks)
I'm glad you have a solution, although I'm horrified that M$ have yet
again broken fundamental subsystems.
I'm also horrified that NFS is not working with modern Windows too.
On 24/03/16 11:37, Brad Campbell wrote:
> On 13/03/16 19:19, Brad Campbell wrote:
>> Spoke too soon. Windows NFS support is patchy at best, and unfortunately
>> only seems to work well with NFS v3. v4 seem to be a problem getting
>> permissions to work. I'll keep plugging away (see what I did there) and
>> if I actually make it work I'll try and document it. Thus far every
>> configuration permutation google has thrown up results in a dead end. I
>> don't even get far enough to get "mount" to show me a valid
>> configuration, it just says "Unavailable". It does get a valid auth on
>> the linux syslog though.
> So, I never got it to work.
> The windows nfs client for Windows 7 interferes with a load of windows
> remote networking stuff. I tried it on NFS 3 & 4 servers. I tried with
> all the registry hacks for Anonymous UID & GID settings. I installed 3
> of Microsofts "Hotfix" packs for the enterprise that were supposed to
> make things better. After a week of frustration and now broken SMB
> networking I gave up and uninstalled it.
> After the un-install I also had to search the registry and remove all
> references to 'nfs41' to get SMB networking working correctly as it
> interferes with network search orders.
> I then upgraded the Debian server to Samba 4 using the backports
> packages. That worked out of the box and didn't require any
> configuration changes, but it didn't solve the problem.
> A couple more 'hotfixes' and some registry tweaks later and no
> improvement. If I changed the file on the Linux Server, can ran 'type
> file.name' in a command window on the Windows client I could see the
> contents were still not updating for a minute or so.
> Fast forward another day or so and we arrive at oplocks. Disable
> oplocks in the share in question (in the smb.conf file) and the
> problem has gone away.
> It wasn't a problem for XP or Server 2003, and I tried restricting the
> protocol samba supported back to those versions, but there is
> something that has changed about the way Windows 7 manages oplocks
> that broke things.
> PLUG discussion list: plug at plug.org.au
> Committee e-mail: committee at plug.org.au
> PLUG Membership: http://www.plug.org.au/membership
More information about the plug