İstemcinin bağlantısı kesildikten sonra samba'nın dosya kilidini tutmasını nasıl önleyebilirim?


11

Burada bir Samba sunucusu (Debian 5.0) var Windows XP profillerini barındırmak için yapılandırılmış.

İstemciler bu sunucuya bağlanır ve doğrudan samba paylaşımında profillerinde çalışır (profil yerel olarak kopyalanmaz).

Arada sırada, istemci düzgün kapanmayabilir ve bu nedenle Windows dosya kilitlerini serbest bırakmaz. Samba kilitleme tablosuna bakarken, istemci artık bağlı olmasa bile birçok dosyanın hala kilitli olduğunu görebiliriz. Bizim durumumuzda, bu Mozilla Thunderbird ve Firefox tarafından oluşturulan kilit dosyalarında gerçekleşiyor gibi görünüyor. İşte samba kilitleme tablosuna bir örnek:

# 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

Dosyaların Windows tarafından açıldığını ve bir DENY_ALL kilidi uyguladığını görebiliriz.

Artık bir istemci bu paylaşıma yeniden bağlandığında ve bu dosyaları açmaya çalıştığında samba kilitlendiğini ve erişimi reddettiğini söylüyor.

Bu durumu geçici olarak çözmenin bir yolu var mı yoksa bir şey mi kaçırıyorum?

Düzenleme: Bu özelliklerin etkinleştirilmesi için iyi nedenler olduğundan samba sunucusundaki dosya kilitlerinin devre dışı bırakılmasını önlemek istiyoruz .

Yanıtlar:


11

aşağıdaki adımlar bu sorunu birkaç kez çözmeme yardımcı oldu:

  1. Samba sunucusuna giriş yapın.
  2. Bir "smbstatus" çalıştırın.
  3. Çıktının üçüncü bölümünde dosyada kilit bulunan işlemin pid'ini bulun.
  4. Smbstatus çıktısının ilk ve ikinci bölümlerinde beklenen kullanıcı ve ana bilgisayar adıyla eşleştiğini doğrulayın.
  5. "Ps -ef" çalıştırın ve bu pid ile smbd ne kadar süredir çalışıyor bakın.
  6. Bilgisayar en son yeniden başlatılmasından bu yana çalışıyorsa, smbd üzerinde bırakılır. SADECE BİR smbd öldür. (Ve doğru olanı aldığınızdan emin olun - ebeveyn pidine 1'e eşit olmayan bir tane olmalıdır.)

Ayrıca, bazı smbd pidelerinin birkaç saattir çalıştığını ve kilitledikleri dosyaların ihtiyacınız olduğunu görebilirsiniz. Yukarıdaki gibi, sadece bu süreçleri öldürün ve iyi olmalısınız. Ana smbd işlemini istemeden öldürürseniz, bu komutla yeniden başlatabilirsiniz: sudo /etc/init.d/smbd restart
Socceroos

5

Bir bak bakalım:

reset on zero vc = yes / no

ve sorunun çözülüp çözülmeyeceğini görün.

Gönderen smb.confadam sayfası:

Bu boole seçeneği, gelen bir oturum kurulumunun aynı IP'den gelen diğer bağlantıları öldürüp öldürmeyeceğini denetler. Bu, varsayılan Windows 2003 davranışıyla eşleşir. Kesintili bir ağınız varsa ve eski bağlantıda hala paylaşım modları açık olan dosyalar varken pencereler yeniden bağlanmaya karar verdiğinde bu parametrenin evet olarak ayarlanması gerekir. Bu dosyalara yeni bağlantı üzerinden erişilemez. İstemci yeni bağlantıya sıfır VC gönderir ve Windows 2003 aynı IP'den gelen diğer tüm bağlantıları öldürür. Bu şekilde kilitli dosyalara tekrar erişilebilir. Bu seçeneğin etkinleştirilmesinin maskeli bir yönlendiricinin arkasındaki bağlantıları öldüreceğini lütfen unutmayın.

Edit :
Ben sadece başka bir olası çözüm üzerinde düşündüm. Söz konusu paylaşımda böyle bir şey yapabilirsiniz.

veto oplock files = /*.lock/

Bu sadece .lock dosyalarındaki oplokları önleyecektir.


0

Samba'daki bazı çok zeki insanlar bu seçeneği kaldırmaya karar verdiler ve bunun yerine bir şey kalmadı.

Şimdiye kadar KOBİ uyumluluğu için, bu aslında varsayılan kazanma davranışıdır.

Bir kullanıcı linux komut satırında ve açık dosyaları / işlemleri nasıl öldüreceğini bilmiyorsa, bunu temizlemek için SMBD'yi veya sunucunun kendisini yeniden başlatmanız gerekir.

Harika oldu, Samba.org.


Bunun için bir alıntı var mı?
BE77Y

Oraya ulaşmak için birkaçına bakmanız gerekecek, ancak: lists.samba.org/archive/samba-technical/2011-July/078621.html (kaldırılmaması için yalvaran düşünce sürecini ve ahbapları göster) listeleri .samba.org / arşiv / samba-teknik / 2008-Ekim /… (parametrenin 4.0'da kaldırıldığını gösterir)
Michael

2019 itibariyle, Debian 9 - Samba 4.5.12'de, reset on zero vcseçenek hala kılavuzda listelenmiştir ve tarafından da görüntülenir testparm. Yani ya geri döndü ya da gerçekten kaldırılmamıştı.
mivk

0

Benzer bir sorunla karşılaşıyordum, bir istemci büyük bir dosyayı kopyalarken çöktü ve dosya yeniden başlatıldıktan sonra kilitlendi. Neyse ki bu çok sık olmaz, ancak samba sürecini öldürmek yine de oldukça can sıkıcıdır. reset on zero vcsadece çözüm gibi görünüyordu, ancak sözde Samba4'ten kaldırıldı, ancak Fedora (27) üzerinde Sürüm 4.7.6 hala var (muhtemelen RH tarafından yamalı). Adam sayfası artık söylediği gibi sadece (artık kullanılmamalıdır olan) ve SMB2 ve SMB3 bağlantılarında şey yapmaz SMB1 birlikte çalıştığını, çok zaten yardımcı olmaz, tek yol bu olduğu işlemek için sol belirtilen Micheal tarafından bağlanan iplik . Kaldırma işleminin ardındaki mantığı ve bunun neyin kötü olduğunu bilmiyorumreset on zero vc, Bu amaç için bir hack gibi tcp zaman aşımı kullanmayı düşünürüm. Her neyse, makul bir şey olabilir.

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

Bu, son iletişimden sonra yaklaşık 40 saniye (30 + 3 * 3) bağlantıyı öldürür, bu da genellikle bir çökme ve yeniden başlatma için yeterlidir (sunucunun tcp yığını istemci olduğunda bağlantıyı kapatacak kadar akıllıdır) yeniden başlatma işleminden sonra saklama paketlerini reddeder).

Bunun ağınızdaki yükü artırdığını unutmayın, ancak birçok istemcide bile fark edildiğinden şüpheliyim.


Bunun tuhaf Windows10 istemcisi "hiç kimse nogroup" zombi iplik sorunu ile yardımcı olup olmadığını biliyor musunuz? Birkaç sitedeki Windows10 istemcilerimin çoğu, işleyici işlemleri öldürülene / emekli oluncaya kadar "hiç kimse nogroup" a atanan yüzlerce (bazen binlerce) zombi iş parçacığını terk etmeye başladı. Normalde ayarlanması deadtime = 10veya temizlenmesi gerekir, ancak dosya kilitleri SMB3_11 bağlantılarında sonsuza kadar kalıcı olarak bir etki yaratmaz, çünkü bir PID için dosya kilitleri hala mevcutken ölü zaman kontrol edilmez. Son derece sinir bozucu.
zxq9

Açıkladığınız sorunu hiç duymadım veya deneyimlemedim. deadtimeistemcilerinizde dosyalar açıksa hiçbir şey yapmaz, bu nedenle soru, hangi dosyaları açık tuttuklarıdır. Ancak bu muhtemelen burada tartışılandan tamamen farklı bir konudur, bu yüzden bunun için yeni bir soru açmalısınız. Benim socket optionsönerim sadece uygun biçimde kapatılmadığı bağlantıları ile yardımcı olur, ancak (müşteriler çöker, bir ağ kesintisi vb nedeniyle) muhtemelen sizin WX müşteriler sadece hangi (başka bir işlem veya anonim oturumu çeşit kullanmadan sunucusuna bağlanmak eğer nobody.nogroupönerir ).
Jakob

Bu sorunla ilgili tek bir soru var gibi görünüyor , ancak gerçek bir çözüm yok. Daha yeni bir sürümde düzeltilebilecek bir samba sorunu olabileceği anlaşılıyor.
Jakob

Posta listesinde bununla ilgili birkaç söz var, hiçbir yerde gerçek bir çözüm sunulmadı ve denediğim sürüm yok (mevcut her şube ancak 4.9) sorunu çözüyor. Sadece Windows10 istemcileri ile. Hiç kimse: grup dışı bir şey şaşırtıcıdır, çünkü konuk küresel olarak devre dışı bırakılır, hiçbir paylaşım onları kabul etmez ve hiç kimse girişlerinin PID'si her zaman geçerli bir kullanıcı adına sahip tek bir geçerli girişle aynıdır. Yani 12345 someuser somegroup...bir girişte, sonra 800 girişte görürsünüz 12345 nobody nogroup ..., ama sadece bir avuç dosya kilidi (800 değil) Çok garip. Şu anda 3 müşteri sitemi etkiliyor.
zxq9

Bu sadece yüksek etkinlikli sitelerde bir kaynak kısıtı haline geliyor, bu yüzden çok az ilgi aldığını düşünüyorum. Çoğu zaman bir sorun yoktur, bu yüzden insanlar bunu fark etmez ve istemciler aslında bağlantılarını kapattıklarında kendini temizler.
zxq9

0

Aşağıdakileri kullanarak oplock'ları paylaşım başına devre dışı bırakabilirsiniz:

[acctdata]
oplocks = False
level2 oplocks = False

Varsayılan oplock türü Seviye1'dir. Seviye2 oplocks, smb.conf dosyasında paylaşım başına etkinleştirilir. Alternatif olarak, paylaşımları paylaşım başına dosya başına temelinde devre dışı bırakabilirsiniz:

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

Opba kilitleriyle ilgili sorunlar yaşıyorsanız, Samba'nın günlük girişlerinden de anlaşılacağı gibi, güvenli oynamak ve oplocks ve Level2 oplocks'u devre dışı bırakmak isteyebilirsiniz.

Çekirdek Oplocks'u Devre Dışı Bırakma Çekirdek oplocks, bir UNIX işlemi önbelleğe alınan dosyayı açmaya çalışırken Samba'yı (UNIX çekirdeğinde bir Windows istemcisine oplock sonu gönderme yeteneği varsa) bildiren bir smb.conf parametresidir. Bu parametre, Samba sunucusunda etkinleştirilmiş oplocks ile UNIX ve Windows arasında paylaşım dosyalarını ele alır: UNIX işlemi, Windows istemcisi tarafından Oplocked (önbelleğe alınmış) dosyayı açabilir ve smbd işlemi, dosyayı açığa çıkaran bir oplock sonu göndermez veri bozulması riski. UNIX çekirdeği bir oplock sonu gönderme yeteneğine sahipse, çekirdek oplocks parametresi Samba'nın oplock sonu göndermesini sağlar. Çekirdek oplocks, smb.conf dosyasında sunucu başına temelinde etkinleştirilir.

kernel oplocks = yes

Varsayılan değer no'dur.

Kaynak

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.