Alex Hooper wrote:
Scott Lovenberg uttered:
Alex Hooper wrote:
Scott Lovenberg uttered:
Alex Hooper wrote:
Hi,
We have an office-based Windows-locked publishing system whose only
delivery mechanism is to write to a local filesystem, and a
requirement for its output to be available to a collocated
production environment comprising Solaris and Linux boxes. The
'obvious' solution was to run a Samba server on one of the
collocated Linux boxes and mount the share it provides on the
relevant Windows machines in the office. And this is what I have
done. This works, but encounters the problem I am about to describe.
SCENARIO ONE:
Connecting to the server/share in Explorer (Windows XP) by typing
the path (\\dns.host.name\share) into the address bar is
accomplished without problem, as is receiving a directory listing.
But uploading a file to the remote share (by drag and dropping)
causes Explorer to freeze for anything between 10 and 30 seconds
after which the file transfers at good speed.
SCENARIO TWO:
Map the remote share, using same connection details. Now copy is
often fine, but sometimes will just fail with a "Cannot copy
<filename>: The specified network name is no longer available." and
leave a zero-length file at the remote end.
Not infrequently, smbd processes are being left in an
'uninterruptible sleep' state.
If I mount the remote share via smbmount onto a Linux server in the
office, I don't encounter any of these problems.
Packet-sniffing on scenario one shows that the pause is happening
before any set-up for the file transfer: it looks like the client
disconnects, then there's a pause, then it reconnects.
I'm using Samba version 3.0.25b-1.el4_6.4 on RHEL ES release 4.
Clients are Windows XP Pro. Our office has a fairly large and
complex LAN which is managed by a separate department. Access to
the Internet is, not surprisingly, via a NATting gateway.
Appropriate ports have been opened in the firewalls, though all
communication is in Direct-hosted mode (ie, I only see traffic on
port 445/tcp).
smb.conf looks like this:
[global]
workgroup = WG123
netbios name = n2323 # hostname of server
server string = FOO-BAR-Samba
#wins proxy = yes
#wins server = xxx.xx.xx.x
security = user
passdb backend = tdbsam
load printers = no
# idle time (mins) before client is disconnected
dead time = 15
keepalive = 10
socket options = IPTOS_THROUGHPUT SO_SNDBUF=8576
inherit permissions = yes
[test-xml]
path = /stuff/test-xml
writeable = Yes
public = no
Could anyone suggest what might be going on here?
Thanks,
Alex.
On scenario1, is it (Windows client) trying to connect to port 445
on the server, being dropped instead of rejected, timing out, and
then establishing a connection on port 139? I think by default
Windows tries to connect to both at the same time or something weird
like that.
No. There is no attempt to use port 139: only 445 is approached.
On scenario2, I've seen behavior something akin to this on a
corrupted e1000 kernel module. I've also seen bad cables (twice
where gigabit and mii are concerned, IIRC) that behave all kinds of
weird, at any given moment.
The server's using the bnx2 module and the NIC is at 100MB FD. I'm
not noting any other network weirdness, which would seem to suggest
cabling is probably OK, wouldn't it?
I once heard a quote (which I'd like to attribute to Jeremy Allison
for some reason) to the effect of "The Windows SMB network stack is
like a canary in a coal mine, when you have network troubles it's the
first thing to die." I could get everything else to work just fine
with this driver, but SMB/CIFS just kept flaking out. So, I always
try to trace a problem starting from the wall back.
Anyways, FWIW, how does your 'netstat -s' output look? Are you
getting a considerable number of connection resets being sent or
received?
No. All the "reset sent"s in the diff below belong to an unrelated
application. In the time between the two netstats compared below,
various stalling transfers were made and one "network name is no
longer available" was received:
# diff -Bub /root/netstat-20080213-0939 /root/netstat-20080213-1016
--- /root/netstat-20080213-0939 2008-02-13 09:39:24.000000000 +0000
+++ /root/netstat-20080213-1016 2008-02-13 10:16:34.000000000 +0000
@@ -1,43 +1,44 @@
Ip:
- 4336 total packets received
+ 21933 total packets received
0 forwarded
0 incoming packets discarded
- 4335 incoming packets delivered
- 4134 requests sent out
+ 20292 incoming packets delivered
+ 19069 requests sent out
Icmp:
- 26 ICMP messages received
+ 92 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
- echo requests: 26
- 26 ICMP messages sent
+ echo requests: 92
+ 92 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
- echo replies: 26
+ echo replies: 92
Tcp:
- 6 active connections openings
- 161 passive connection openings
+ 11 active connections openings
+ 169 passive connection openings
0 failed connection attempts
- 0 connection resets received
- 93 connections established
- 4176 segments received
- 3992 segments send out
+ 1 connection resets received
Hrm... the client reset. Do you have a wire sniff to see what is
going on right before the client sends a reset?
Hi,
I've put one at
http://www.oops.org.uk/misc/transfer-file-20080213-reset02.pcap
I'm unable to extract useful clue from it, though brain fog is building
up here. I'm starting to consider publishing to an internal machine and
syncing with SCP or rsync. Feels hacky, though.
Cheers,
OK, it looks like you're choking on an enumeration for your subversion
directory right before the first session close. Have you turned off
"hide dot files", which is on by default?
As far as rsync goes, it can be hacky, depending on how you do it.
Personally, I have a script that mounts another computers administrative
C$ share (as a domain admin - use a password file or it'll show up in
top!). It works just fine, although not the most elegant way to do
things... but that's why we're geeks, getting things done trumps
elegance every day of the week. You'll have problems with open files
though, unless you do an LVM snapshot or something. The nice thing
about it though is that you can save permissions with rsync, and you do
have hardlinking, client/server abilities, and stunnel support. Amanda
or Bacula may be more elegant, but the setup overhead to have the same
functionality that an easily modifiable shell script gives you, makes it
a zero sum game in the short term. Just my $0.02.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
