วิธีป้องกันแซมบ้าไม่ให้ถือล็อคไฟล์หลังจากที่ลูกค้ายกเลิกการเชื่อมต่อ?

11

ที่นี่ฉันมีเซิร์ฟเวอร์ Samba (Debian 5.0) ที่มีการกำหนดค่าให้โฮสต์โปรไฟล์ Windows XP

ลูกค้าเชื่อมต่อกับเซิร์ฟเวอร์นี้และทำงานกับโปรไฟล์ของพวกเขาโดยตรงในการแบ่งปันแซมบ้า (โปรไฟล์จะไม่ถูกคัดลอกในเครื่อง)

ทุก ๆ ครั้งที่ไคลเอนต์อาจปิดไม่ถูกต้องและทำให้ Windows ไม่ปล่อยล็อกไฟล์ เมื่อดูที่ตารางล็อคแซมบ้าเราจะเห็นว่าหลายไฟล์ยังคงถูกล็อคแม้ว่าลูกค้าจะไม่ได้เชื่อมต่ออีกต่อไป ในกรณีของเราดูเหมือนว่าจะเกิดขึ้นกับล็อคไฟล์ที่สร้างขึ้นโดย Mozilla Thunderbird และ Firefox นี่คือตัวอย่างของตารางล็อค samba:

# smbstatus -L | grep DENY_ALL | head -n5
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
15494        10345      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user1   app.profile/user1.thunderbird/parent.lock   Mon Nov 22 07:12:45 2010
18040        10454      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user2   app.profile/user2.thunderbird/parent.lock   Mon Nov 22 11:20:45 2010
26466        10056      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user3   app.profile/user3.firefox/parent.lock   Mon Nov 22 08:48:23 2010

เราจะเห็นว่าไฟล์ถูกเปิดโดย Windows และกำหนดให้ล็อค DENY_ALL

ตอนนี้เมื่อลูกค้าเชื่อมต่อกับส่วนแบ่งนี้อีกครั้งและพยายามที่จะเปิดไฟล์เหล่านั้นแซมบ้าบอกว่าพวกเขาถูกล็อคและปฏิเสธการเข้าถึง

มีวิธีแก้ไขสถานการณ์นี้หรือไม่

แก้ไข:เราอยากจะหลีกเลี่ยงการปิดใช้งานการล็อกไฟล์บนเซิร์ฟเวอร์แซมบ้าเพราะมีมีเหตุผลที่ดีที่จะมีผู้ที่เปิดใช้งาน

linux samba server-message-block

— Jean-Francois Chevrette
แหล่งที่มา

11

ขั้นตอนด้านล่างช่วยให้ฉันแก้ไขปัญหาที่แน่นอนนี้ได้หลายครั้ง:

เข้าสู่ระบบเซิร์ฟเวอร์ samba
เรียกใช้ "smbstatus"
ค้นหา pid ของกระบวนการที่มีการล็อกไฟล์ในส่วนที่สามของเอาต์พุต
ตรวจสอบว่าตรงกับผู้ใช้และชื่อโฮสต์ที่คาดหวังในส่วนแรกและส่วนที่สองของผลลัพธ์ smbstatus
เรียกใช้ "ps -ef" และดูว่า smbd กับ pid นั้นทำงานนานเท่าใด
ถ้ามันถูกเรียกใช้ตั้งแต่ก่อนที่คอมพิวเตอร์จะรีบูทครั้งสุดท้ายมันจะเหลือ smbd ฆ่าเพียงแค่หนึ่ง smbd (และตรวจสอบให้แน่ใจว่าคุณได้รับสิ่งที่ถูกต้อง - ควรเป็นอันที่มี pid พาเรนต์ไม่เท่ากับ 1)

— Socceroos
แหล่งที่มา

นอกจากนี้คุณอาจพบว่าไฟล์ smbd บางตัวทำงานมาแล้วสองสามชั่วโมงและไฟล์ที่พวกเขาล็อคนั้นเป็นไฟล์ที่คุณต้องการ ดังกล่าวข้างต้นเพียงแค่ฆ่ากระบวนการเหล่านี้และคุณควรจะดี หากคุณฆ่ากระบวนการหลัก smbd โดยไม่ตั้งใจคุณสามารถเริ่มต้นใหม่ได้ด้วยคำสั่งนี้: sudo /etc/init.d/smbd restart

— Socceroos

5

มองไปที่:

reset on zero vc = yes / no

และดูว่าจะแก้ไขปัญหาของคุณหรือไม่

จากsmb.confหน้าคน:

ตัวเลือกบูลีนนี้ควบคุมว่าการตั้งค่าเซสชันที่เข้ามาควรจะหยุดการเชื่อมต่ออื่น ๆ ที่มาจาก IP เดียวกันหรือไม่ สิ่งนี้ตรงกับพฤติกรรมเริ่มต้นของ Windows 2003 การตั้งค่าพารามิเตอร์นี้เป็นใช่จำเป็นเมื่อคุณมีเครือข่ายที่ไม่สม่ำเสมอและหน้าต่างตัดสินใจเชื่อมต่อใหม่ในขณะที่การเชื่อมต่อเก่ายังคงมีไฟล์ที่เปิดโหมดแชร์ไว้ ไฟล์เหล่านี้ไม่สามารถเข้าถึงได้ผ่านการเชื่อมต่อใหม่ ไคลเอนต์ส่งศูนย์ VC บนการเชื่อมต่อใหม่และ Windows 2003 ฆ่าการเชื่อมต่ออื่น ๆ ทั้งหมดที่มาจาก IP เดียวกัน วิธีนี้สามารถเข้าถึงไฟล์ที่ล็อคได้อีกครั้ง โปรดทราบว่าการเปิดใช้งานตัวเลือกนี้จะฆ่าการเชื่อมต่อที่อยู่เบื้องหลังเราเตอร์ที่ปลอมแปลง

แก้ไข :
ฉันแค่คิดถึงโซลูชันอื่นที่เป็นไปได้ คุณสามารถทำอะไรแบบนี้กับคำถามที่แชร์ได้

veto oplock files = /*.lock/

นี่จะป้องกัน oplocks ในไฟล์. lock

— 3dinfluence
แหล่งที่มา

0

ผู้คนที่ฉลาดมากที่แซมบ้าตัดสินใจที่จะลบตัวเลือกนี้และไม่มีการแทนที่

จนถึงขณะนี้สำหรับความเข้ากันได้ของ SMB เนื่องจากนี่เป็นพฤติกรรมการชนะที่เป็นค่าเริ่มต้น

หากผู้ใช้ไม่ชำนาญในบรรทัดคำสั่ง linux และวิธีฆ่าไฟล์ / กระบวนการที่เปิดอยู่คุณต้องรีสตาร์ท SMBD หรือเซิร์ฟเวอร์เองเพื่อล้างข้อมูล

ทำได้อย่างยอดเยี่ยม Samba.org

— ไมเคิล
แหล่งที่มา

คุณมีหนังเรื่องนี้ไหม?

— BE77Y

คุณจะต้องดูที่การเดินทาง แต่: list.samba.org/archive/samba-technical/2011-July/078621.html (แสดงกระบวนการคิดและการแย่งชิงเพื่อไม่ให้ลบ) รายการ .samba.org / เก็บถาวร / samba-technical / 2008-October / … (แสดงพารามิเตอร์ที่ถูกลบใน 4.0)

— Michael

ในฐานะของ 2019 ใน Debian 9 - แซมบ้า 4.5.12 ที่reset on zero vcตัวเลือกที่เป็น บริษัท testparmจดทะเบียนยังคงอยู่ในคู่มือการใช้งานและยังแสดงโดย ดังนั้นไม่ว่ามันจะกลับมาหรือไม่ได้ถูกลบออกจริงๆ

— mivk

0

ฉันพบปัญหาที่คล้ายกันไคลเอนต์ขัดข้องขณะคัดลอกไฟล์ขนาดใหญ่และไฟล์ถูกล็อคหลังจากรีบูต โชคดีที่สิ่งนี้ไม่ได้เกิดขึ้นบ่อยนัก แต่ก็ยังค่อนข้างน่ารำคาญที่ต้องฆ่ากระบวนการแซมบ้า reset on zero vcดูเหมือนจะเป็นเพียงวิธีแก้ปัญหา แต่มันควรจะถูกลบออกจาก Samba4 แม้ว่าเวอร์ชั่น 4.7.6 บน Fedora (27) ยังคงมีอยู่ (อาจได้รับการแก้ไขโดย RH) มันไม่ได้ช่วยอะไรมากเท่าที่หน้า man บอกว่ามันใช้ได้กับ SMB1 เท่านั้น (ซึ่งไม่ควรใช้อีกต่อไป) และไม่ทำอะไรเลยในการเชื่อมต่อ SMB2 และ SMB3 วิธีเดียวที่เหลือในการจัดการสิ่งนี้ถูกกล่าวถึงใน ด้ายเชื่อมโยงโดยไมเคิล ฉันไม่ทราบเหตุผลเบื้องหลังการย้ายและสิ่งที่ไม่ดีเกี่ยวกับreset on zero vcฉันจะพิจารณาใช้การหมดเวลา tcp เพื่อจุดประสงค์นี้มากกว่าแฮ็ค อย่างไรก็ตามสิ่งที่สมเหตุสมผลอาจเป็นเช่น

socket options = TCP_NODELAY SO_KEEPALIVE TCP_KEEPIDLE=30 TCP_KEEPCNT=3 TCP_KEEPINTVL=3

สิ่งนี้จะฆ่าการเชื่อมต่อประมาณ 40 วินาที (30 + 3 * 3) หลังจากการสื่อสารครั้งล่าสุดซึ่งมักจะเกินพอสำหรับการสังเกตเห็นความผิดพลาดและการรีบูตเครื่อง (เนื่องจากว่าสแต็ก tcp ของเซิร์ฟเวอร์นั้นฉลาดพอที่จะปิดการเชื่อมต่อเมื่อไคลเอนต์ ปฏิเสธแพ็กเก็ต keepalive หลังจากรีบูต)

โปรดทราบว่านี่จะเป็นการเพิ่มภาระให้กับเครือข่ายของคุณ แต่ฉันสงสัยว่ามันจะสังเกตเห็นได้แม้จะมีลูกค้าจำนวนมาก

— จาคอบ
แหล่งที่มา

คุณทราบหรือไม่ว่าสิ่งนี้จะช่วยให้มีปัญหาเธรด zombie "nothing nogroup" ของไคลเอนต์ Windows10 หรือไม่? ไคลเอนต์ Windows10 ของฉันหลายคนในหลาย ๆ ไซต์เริ่มทิ้งเธรดซอมบี้หลายร้อย (หลายพันครั้ง) ซึ่งได้รับมอบหมายให้ "ไม่มีใครเข้าร่วมกลุ่ม" จนกว่ากระบวนการจัดการของพวกเขาจะถูกฆ่า / เกษียณอายุ โดยทั่วไปการตั้งค่าdeadtime = 10หรือดังนั้นจะล้าง แต่ด้วยการล็อคไฟล์ที่เอ้อระเหยในการเชื่อมต่อ SMB3_11 ตลอดไปมันจะไม่มีผลกระทบเนื่องจากเวลาจะไม่ถูกตรวจสอบในขณะที่ filelocks สำหรับ PID ยังคงมีอยู่ น่าผิดหวังอย่างมาก

— zxq9

ฉันไม่เคยได้ยินหรือเคยประสบปัญหาที่คุณอธิบาย deadtimeไม่ทำอะไรเลยหากลูกค้าของคุณเปิดไฟล์ดังนั้นคำถามก็คือไฟล์ใดที่พวกเขาเปิดไว้ แต่นั่นอาจเป็นปัญหาที่แตกต่างจากที่กล่าวไว้ที่นี่ดังนั้นคุณควรเปิดคำถามใหม่สำหรับเรื่องนี้ ฉันsocket optionsข้อเสนอแนะเพียง แต่ช่วยให้มีการเชื่อมต่อที่ไม่ได้ปิดอย่างถูกต้อง (เพราะเกิดปัญหาลูกค้าดับเครือข่าย ฯลฯ ) แต่อาจจะไม่ได้ถ้าลูกค้า WX ของคุณเพียงแค่เชื่อมต่อกับเซิร์ฟเวอร์ได้โดยไม่ต้องดำเนินการใด ๆ หรือใช้ชนิดของเซสชั่นที่ไม่ระบุชื่อบางส่วน (ซึ่งnobody.nogroupแสดงให้เห็น )

— Jakob

ดูเหมือนจะมีคำถามหนึ่งข้อเกี่ยวกับปัญหานี้ แต่ไม่มีวิธีแก้ปัญหาจริง ดูเหมือนว่าจะเป็นปัญหาของ samba ที่สามารถแก้ไขได้ในรุ่นที่ใหม่กว่า

— Jakob

มีการพูดถึงเรื่องนี้ค่อนข้างน้อยในรายการส่งเมลไม่มีวิธีแก้ปัญหาที่แท้จริงที่นำเสนอทุกที่และไม่มีรุ่นที่ฉันได้ลอง (ทุกสาขาปัจจุบัน แต่ 4.9) แก้ไขปัญหาได้ มันเป็นกับไคลเอนต์ Windows10 เท่านั้น ไม่มีใคร: สิ่งที่ nogroup ทำให้งงงวยเนื่องจากแขกถูกปิดการใช้งานทั่วโลกไม่มีการใช้ร่วมกันยอมรับและ PID ของรายการที่ไม่มีใครเหมือนกันเสมอกับรายการที่ถูกต้องเพียงครั้งเดียวด้วยชื่อผู้ใช้ที่ถูกต้อง ดังนั้นคุณจะเห็น12345 someuser somegroup...หนึ่งรายการจากนั้น 800 12345 nobody nogroup ...รายการ แต่มีเพียงไม่กี่ไฟล์เท่านั้นที่ล็อค (ไม่ใช่ 800) แปลกมาก. ส่งผลกระทบ 3 เว็บไซต์ลูกค้าของฉันในตอนนี้

— zxq9

สิ่งนี้กลายเป็นข้อ จำกัด ของทรัพยากรในไซต์กิจกรรมระดับสูงซึ่งเป็นสาเหตุที่ฉันคิดว่ามันได้รับความสนใจน้อยมาก เวลาส่วนใหญ่ไม่มีปัญหาดังนั้นผู้คนก็ไม่ได้สังเกตและมันจะล้างข้อมูลเมื่อใดก็ตามที่ลูกค้าปิดการเชื่อมต่อ

— zxq9

0

คุณสามารถปิดการใช้งาน oplocks บนพื้นฐานการแบ่งปันต่อไปนี้:

[acctdata]
oplocks = False
level2 oplocks = False

ประเภท oplock เริ่มต้นคือระดับ 1 ระดับ oplocks ถูกเปิดใช้งานบนพื้นฐานต่อหุ้นในไฟล์ smb.conf อีกวิธีหนึ่งคุณสามารถปิดการใช้งาน oplocks แบบต่อไฟล์ภายในการแชร์:

veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/

หากคุณกำลังประสบปัญหากับ oplocks ดังที่เห็นได้จากรายการบันทึกของ Samba คุณอาจต้องการเล่นมันอย่างปลอดภัยและปิดการใช้งาน oplocks และ oplocks ระดับ 2

การปิดใช้งาน Kernel Oplocks Kernel oplocks เป็นพารามิเตอร์ smb.conf ที่แจ้ง Samba (หากเคอร์เนล UNIX มีความสามารถในการส่งไคลเอ็นต์ Windows หยุดพัก oplock) เมื่อกระบวนการ UNIX พยายามเปิดไฟล์ที่ถูกแคช พารามิเตอร์นี้ระบุถึงการแชร์ไฟล์ระหว่าง UNIX และ Windows ด้วย oplocks ที่เปิดใช้งานบนเซิร์ฟเวอร์ Samba: กระบวนการ UNIX สามารถเปิดไฟล์ที่ถูก Oplocked (แคช) โดยไคลเอนต์ Windows และกระบวนการ smbd จะไม่ส่งตัวแบ่ง oplock ซึ่งทำให้ไฟล์แตก ความเสี่ยงของข้อมูลเสียหาย หากเคอร์เนล UNIX มีความสามารถในการส่งตัวแบ่ง oplock พารามิเตอร์ของเคอร์เนล oplocks จะทำให้ Samba สามารถส่งตัวแบ่ง oplock ได้ เคอร์เนล oplocks ถูกเปิดใช้งานบนพื้นฐานต่อเซิร์ฟเวอร์ในไฟล์ smb.conf

kernel oplocks = yes

ค่าเริ่มต้นคือไม่มี

แหล่ง

— ajcg
แหล่งที่มา