Máy chủ: RHEL 5.9 / smbd 3.0.33 - Khách hàng: khác nhau, mặc dù tất cả đều đang sử dụng mount.cifs hiện tại (5.2)
Tôi đã giải quyết vấn đề này, nhưng thật là một cơn ác mộng khi săn lùng các mã lỗi này, tôi cảm thấy như nó cần tài liệu phổ quát.
Các triệu chứng : Không thể đoán trước, lỗi gắn kết không liên tục từ một máy khách cifs cụ thể đến máy chủ samba linux. Tất cả các máy khách linux của tôi pam_mount nhà người dùng khi đăng nhập. Một cách ngẫu nhiên, và thỉnh thoảng các bộ gắn kết dir nhà bắt đầu thất bại trên một máy. Đăng nhập và gắn kết tiếp tục hoạt động hoàn hảo trên tất cả các khách hàng khác. Ban đầu tôi nghĩ rằng một lượng hoạt động bất thường trên máy khách bị hỏng đã khiến smbd trở nên kỳ dị, nhưng những thất bại không liên tục kéo dài ngay cả sau khi sử dụng đã hết.
Cố gắng gắn kết bằng tay thất bại và báo cáo:
Errors from underlying mount program
mount error(12): Cannot allocate memory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Đặt <debug enable="1"/>trong /etc/security/pam_mount.conf.xml để có thêm thông tin từ pam_mount:
command: 'mount' '-t' 'cifs' '//my_server/watdo' '/home/watdo' '-o' 'user=watdo,uid=666,gid=666'
pam_mount(misc.c:38): set_myuid<pre>: (ruid/rgid=0/0, e=0/0)
pam_mount(misc.c:38): set_myuid<post>: (ruid/rgid=0/0, e=0/0)
pam_mount(mount.c:64): Errors from underlying mount program:
pam_mount(mount.c:68): mount error(12): Cannot allocate memory
pam_mount(mount.c:68): Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)`
/var/log/kern.log cũng đã báo cáo về sự kiện này:
kernel: [4316790.256149] CIFS VFS: cifs_mount failed w/return code = -12
'echo 1> / Proc / fs / cifs / cifsFYI' chỉnh sửa gỡ lỗi mount.cifs (ghi vào / var / log / debug). Đây là phần tốt (nhìn quen thuộc?):
CIFS Session Established successfully
For smb_command 117
Sending smb: total_len 88
cifs_sync_mid_result: cmd=117 mid=54307 state=4
Mapping smb error code 0xc0000205 to POSIX err -12
Tại thời điểm này, theo nghĩa đen không có thông tin nào khác có sẵn ở phía khách hàng. yêu cầu gắn kết cifs đi ra ngoài và khách hàng chết gần như ngay lập tức. mount.cifs lỗi (12) là không chính xác (trang man không giúp được gì, các bạn). Tìm kiếm trên internet mở rộng cho thấy đây là một mã lỗi phổ biến, cũng xác nhận nó là không chính xác.
Thời gian để kiểm tra trên máy chủ! Đặt log level = 3cho smbd trong /etc/samba/smb.conf (từ sách Sử dụng Samba: "Cấp trên 3 được các nhà phát triển sử dụng và đổ một lượng lớn thông tin mật mã." Lol!). Đây là dòng có liên quan:
[2013/02/08 10:18:03, 3] smbd/error.c:error_packet_set(106)
error packet at smbd/reply.c(514) cmd=117 (SMBtconX) NT_STATUS_INSUFF_SERVER_RESOURCES
Hầu như ở đó ... từ kho lưu trữ danh sách gửi thư smb tôi đã tìm thấy ai đó báo cáo một loại vấn đề tương tự, được xác định là giới hạn chia sẻ được chốt trong một kết nối smb cá nhân. Liệt kê các cổ phiếu mở trên máy chủ:
smbstatus -S | grep <serverIP> | wc -ltrả lại năm 2048 . Rất dễ thấy.
Trên thực tế kiểm tra đầu ra của smbstatus -Stiết lộ hàng ngàn các mục cho 'IPC $'. Các tài liệu Samba trên IPC $ tiết lộ nó có liên quan đến việc duyệt chia sẻ ẩn danh và truy cập vào "một số tài nguyên khác". Tôi đặt từ chối máy chủ trên máy chủ trong /etc/samba/smb.conf:
[IPC$]
hosts deny = 0.0.0.0/0
Hoạt động tuyệt vời bây giờ. OK, hy vọng một cái gì đó ở đây sẽ giúp một số linh hồn nghèo một thời gian trong tương lai.
Tôi đoán theo tinh thần của trang web, tôi sẽ hỏi một câu hỏi: Tại sao smbd không làm sạch cổ phiếu IPC $? Tại sao phải thiết lập một IPC $ cho mỗi kết nối người dùng thành một chia sẻ thay vì một kết nối cho mỗi khách hàng? Bạn có thể vô hiệu hóa việc tạo chia sẻ IPC $ từ phía khách hàng không? Có cách nào để tăng kết nối # tối đa trên mỗi chia sẻ (không phải điều này sẽ giúp ích trong trường hợp này)? Tôi đã không nhìn thấy nó trong các tài liệu.