samba 로 공유시(service start 후 client에서 접근 할 때) 아래와 같은 오류가 많이 떴습니다.
(실제 복사등의 작업시 문제가 되지는 않았습니다)
May 9 21:46:33 search4 smbd[10776]: [2008/05/09 21:46:33, 0] lib/util_sock.c:get_peer_addr(1232) May 9 21:46:33 search4 smbd[10776]: getpeername failed. Error was 전송 종료지점이 연결되어 있지 않습니다 May 9 21:46:33 search4 smbd[10783]: [2008/05/09 21:46:33, 0] lib/util_sock.c:get_peer_addr(1232) May 9 21:46:33 search4 smbd[10783]: getpeername failed. Error was 전송 종료지점이 연결되어 있지 않습니다 May 9 21:46:33 search4 smbd[10783]: [2008/05/09 21:46:33, 0] lib/util_sock.c:read_data(534) May 9 21:46:33 search4 smbd[10783]: read_data: read failure for 4 bytes to client 0.0.0.0. Error = 연결이 상대편에 의해 끊어짐
해결방법은
/etc/samba/smb.conf 에서
[global]
smb ports = 139 를 추가 하는 겁니다.
## 또는 아래 내용과 같이 445 port를 iptables를 이용해 막는다.
About 10 days ago, I started looking at the “getpeername failed. Error was
Transport endpoint is not connected” message appearing on our logs. This
message was being produced very frequently during the day and somewhat
less frequently at night.
Our configuration is samba 3.0.2a as a PDC with WINS support. Our network
has about 60 XP Pro PC’s and 100 W98 PC’s. The signorseal registry patch
was applied to all the XP Pro PC’s last year while we were still running
samba 2.
It was quickly apparent that this message was only being issued for our XP
Pro PC’s. Also, at night when the network was pretty idle, the message
was being issued only on certain XP PRO PC’s, but the PC’s varied on a
nightly basis. Furthermore, at night, for a particular XP Pro PC, the
messages were occurring at intervals that were multiples of 15 minutes.
After doing some reading and taking some network traces, I inferred that
the XP PRO PC’s for which the message occurred at night were backup
browsers getting their 15 minute refresh. By disabling the Computer
Browsing service on a bunch of the XP Pro PC’s, the night time messages
were reduced.
In any event, I did some more reading and looked at some more network
traces, without a real understanding. However, one of the items I read
was that the XP Pro PC Client attempts to initially communicate with the
server over both ports 445 and 139 and that whichever port responds first
is used for further communication. So I decided to try disabling port 445
at the server by using iptables to force all session traffic across port
139.
“iptables -I INPUT 1 -p tcp --dport 445 -j DROP”
I did this last night and, since applying this iptables rule, there have
been no “getpeername failed. Error was Transport endpoint is not
connected” messages in the log. It is now midmorning with regular
network traffic. I regard this as a circumvention rather than a fix.
So I suspect that the production of this message is a software issue that
is somehow related to the initial communication over both ports 445 and
139 rather than being any type of network hardware issue. If the samba
group needs some network traces, I can supply them.