[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Strange Samba problem
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
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 , 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.
; part of the above is quoted from Konrad Heuer <kheuer2%gwdg.de@localhost>.
Main Index |
Thread Index |