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

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 .

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.)

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.

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.

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.

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