NetBSD-Help archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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.


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


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

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

Konrad reported that using "fake oplocks = yes" in the Samba config
does improve the stability of this sort of configuration significantly.


[1]: ; part of the above is quoted from Konrad Heuer <>.

Home | Main Index | Thread Index | Old Index