Re: Strange Samba problem

Thanks Chuck,

         That is indeed an interesting concern.  Unfortunately (for 
the moment at least) we're stuck with the NFS -> SMB -> Win32_clients 
arrangement.  It appears, however, that there is something else going 
on.  I've got a couple of good leads.  The directory it is choking on 
has over 17000 files in it, and some of them have names upwards of 
100 chars, so I expect that it is some sort of a limit I'm running up 
against.

         If I find out anything useful, I'll post back to the list.

                 -lars

At 12:54 PM 1/9/2008, Chuck Swiger wrote:

(snip)


>An additional possible detail, all of the directories that are
>>served out by Samba are remote, and mounted as needed via nfs by amd.
>
>
>This same issue arose in another list just a day ago [1], so I'll
>excerpt the relevant part of the thread:
>
>>>>You really don't want to export a filesystem which itself is being
>>>>mounted remotely.  If you want to also provide SMB filesharing for
>>>>these files, run Samba on the [NFS server] and not on an NFS client.
>>>
>>>Knowing all the drawbacks including reduced bandwidth, there are
>>>some important organizational reasons, thus I want to do so.
>>>Moreover, Samba is just one application on the NFS clients,
>>>although an important one.
>>
>>While I certainly wish you the best of luck, previous experience
>>suggests that the drawbacks to this approach include not functioning
>>properly.
>>
>>NFS is a stateless protocol, except insofar as rpc.lockd in theory
>>provides lockf/flock style locking over the network-- yet Samba/CIFS
>>wants to allow extensive use of client side opportunistic locking,
>>which means that Samba really, really wants to run off of a local
>>filesystem.
>
>Konrad reported that using "fake oplocks = yes" in the Samba config
>does improve the stability of this sort of configuration significantly.
>
>Regards,
>--
>-Chuck
>
>[1]: 
>http://lists.freebsd.org/pipermail/freebsd-questions/2008-January/165869.html 
>; part of the above is quoted from Konrad Heuer <[email protected]>.