Linux Azure Dosyalar (SMB) ile ilgili sorunları giderme

Bu makalede, Linux istemcilerinden bağlanıyorken Azure Dosyalar ilgili yaygın sorunlar listelemektedir. Ayrıca bu sorunların olası nedenlerini ve çözümlerini de sağlar.

Bu makaledeki sorun giderme adımlarına ek olarak, Linux istemcisinin doğru önkoşullara sahip olduğundan emin olmak için AzFileDiagnostics'i kullanabilirsiniz. AzFileDiagnostics, bu makalede bahsedilen belirtilerin çoğunun algılanmasına otomatik olarak yardımcı olur. En iyi performansı elde etmek için ortamınızı ayarlamaya yardımcı olur. Bu bilgileri paylaşım paylaşımları sorun gidericisinde Azure Dosyalar bulabilirsiniz. Sorun giderici, paylaşımları bağlama, eşleme ve bağlama sorunlarını gidermenize yardımcı Azure Dosyalar sağlar.

Şunlara uygulanır

Dosya paylaşımı türü	SMB	NFS
Standart dosya paylaşımları (GPv2), LRS/ZRS
Standart dosya paylaşımları (GPv2), GRS/GZRS
Premium paylaşımları (FileStorage), LRS/ZRS

Azure dosya paylaşımına bağlanamıyor veya bağlanamıyor

Nedeni

Bu sorunun yaygın nedenleri:

• Eski bir SMB istemcisiyle Linux dağıtımı kullanıyorsanız, uyumlu istemcilere sahip Azure'da kullanılabilen yaygın Linux dağıtımları hakkında daha fazla bilgi için bkz. Linux ile Azure Dosyalar'i kullanma.
• SMB yardımcı programları (cifs-utils) istemciye yüklenmez.
• En düşük SMB sürümü (2.1) istemcide kullanılamaz.
• SMB 3.x şifrelemesi istemcide desteklenmiyor. Yukarıdaki tabloda, şifreleme kullanılarak şirket içi ve bölgeler arası bağlamayı destekleyen Linux dağıtımlarının bir listesi yer almaktadır. Diğer dağıtımlar için çekirdek 4.11 ve üstü sürümler gerekir.
• Azure VM'lerinden bir Azure dosya paylaşımına bağlanmaya çalışıyorsanız ve VM depolama hesabıyla aynı bölgede değil.
• Depolama hesabında Güvenli aktarım gerekli ayarı etkinleştirildiyse, Azure Dosyalar yalnızca şifreleme ile SMB 3.x kullanan bağlantılara izin verecek.

Çözüm

Sorunu çözmek için Linux'ta bağlama hatalarını gidermek Azure Dosyalar sorun giderme aracını kullanın. Bu araç:

• çalışan istemci ortamını doğrulamanıza yardımcı olur.
• İstemciler için erişim hatasına neden olacak uyumsuz istemci yapılandırmasını Azure Dosyalar.
• Kendi kendini düzeltmeye yönelik önsertif rehberlik sağlar.
• Tanılama izlemelerini toplar.

Bir Azure dosya paylaşımını bağlarken "Bağlama hatası (13): İzin reddedildi" hatası

Neden 1: Şifrelenmemiş iletişim kanalı

Güvenlik nedeniyle, iletişim kanalı şifrelenmemişse ve bağlantı girişimi Azure dosya paylaşımlarının bulunduğu veri merkezinden yapılmıyorsa Azure dosya paylaşımlarına bağlantılar engellenir. Depolama hesabında Güvenli aktarım gerekli ayarı etkinleştirildiyse aynı veri merkezi içinde şifrelenmemiş bağlantılar da engellenebilir. Şifrelenmiş bir iletişim kanalının sağlanabilmesi için kullanıcının istemcisi SMB şifrelemesini desteklemelidir.

Daha fazla bilgi edinmek için bkz. Linux ve cifs-utils paketiyle Azure dosya paylaşımını bağlamak için önkoşullar.

Neden 1 için çözüm

1. Bağlan SMB şifrelemesini destekleyen bir istemciden veya Azure dosya paylaşımı için kullanılan Azure depolama hesabıyla aynı veri merkezinde yer alan bir sanal makineden bağlanmayı destekler.
2. İstemci SMB şifrelemesini desteklemiyorsa depolama hesabında Güvenli aktarım gerekli ayarının devre dışı bırakılmıştır.

Neden 2: Depolama hesabında sanal ağ veya güvenlik duvarı kuralları etkinleştirildi

Depolama hesabında sanal ağ (VNET) ve güvenlik duvarı kuralları yapılandırıldıysa, istemci IP adresine veya sanal ağa erişim izni verilmediği sürece ağ trafiğinin erişimi reddedilir.

Neden 2 için çözüm

Depolama hesabında sanal ağ ve güvenlik duvarı kurallarının düzgün yapılandırıldığını doğrulayın. Sanal ağ veya güvenlik duvarı kurallarının soruna neden olup olmadığını test etmek için depolama hesabında Tüm ağlardan erişime izin ver ayarını geçici olarak değiştirin. Daha fazla bilgi edinmek için bkz. Azure Depolama güvenlik duvarlarını ve sanal ağları yapılandırma.

Bir dosyayı açmaya çalışsanız "[izin reddedildi] Disk kotası aşıldı"

Linux'ta aşağıdakine benzer bir hata iletisi alırsınız:

<filename> [izin reddedildi] Disk kotası aşıldı

Nedeni

Bir dosya veya dizin için izin verilen eş zamanlı açık tanıtıcıların üst sınırına ulaştınız.

Tek bir dosya veya dizinde 2.000 açık tanıtıcı kotası vardır. 2.000 açık tanıtıcınız olduğunda, kotaya ulaşıldı hata iletisi görüntülenir.

Çözüm

Bazı tanıtıcıları kapatarak eşzamanlı açık tanıtıcı sayısını azaltarak işlemi yeniden deneyin.

Bir dosya paylaşımı, dizin veya dosyanın açık tanıtıcılarını görüntülemek için Get-AzStorageFileHandle PowerShell cmdlet'ini kullanın.

Bir dosya paylaşımı, dizin veya dosyanın açık tanıtıcılarını kapatmak için Close-AzStorageFileHandle PowerShell cmdlet'ini kullanın.

Linux'ta dosya kopyalama ve Azure Dosyalar yavaş

• Belirli bir en düşük O/Ç boyutu gereksiniminiz yoksa, en iyi performans için 1 MiB'i I/O boyutu olarak kullanmanizi öneririz.
• Doğru kopyalama yöntemini kullanın:
  • İki dosya paylaşımı arasında herhangi bir aktarım için AzCopy kullanın.
  • Cp veya dd'nin paralel olarak kullanımı kopyalama hızını geliştirebilir, iş parçacığı sayısı kullanım durumuna ve iş yükünüze bağlıdır. Aşağıdaki örneklerde altı örnek verilmiştir:
  • cp örneği (cp öbek boyutu olarak dosya sisteminin varsayılan blok boyutunu kullanır): find * -type f | parallel --will-cite -j 6 cp {} /mntpremium/ & .
  • dd örneği (bu komut öbek boyutunu açıkça 1 MiB olarak ayarlar): find * -type f | parallel --will-cite-j 6 dd if={} of=/mnt/share/{} bs=1M
  • Açık kaynak üçüncü taraf araçlar, örneğin:
    • GNU Paralel.
    • Fpart - Dosyaları sıralar ve bölümlere paketler.
    • Fpsync - Verileri src_dir'tan sunucuya geçirmek için birden çok örnek dst_url.
    • Çoklu - GNU coreutil'leri temel alan çok iş parçacıklı cp ve md5sum.
• Her yazma için bir genişletme yazması yapmak yerine dosya boyutunu önceden ayarlama, dosya boyutunun bilindiği senaryolarda kopyalama hızının iyileştirilmesine yardımcı olur. Yazmaların genişletılmasından kaçınmak gerekirse, komutuyla bir hedef dosya boyutu truncate - size <size><file> ayarlayabilirsiniz. Bundan sonra dd if=<source> of=<target> bs=1M conv=notrunc komut, hedef dosyanın boyutunu tekrar tekrar güncelleştirmek zorunda kalmadan bir kaynak dosyayı kopyalar. Örneğin, kopyalamak istediğiniz her dosya için hedef dosya boyutunu ayarlayabilirsiniz (/mnt/share altında bir paylaşımın bağlı olduğunu varsayalım):
  • $ for i in `` find * -type f``; do truncate --size ``stat -c%s $i`` /mnt/share/$i; done
  • ve ardından - yazmaları paralel olarak genişletmeden dosyaları kopyalayın: $find * -type f | parallel -j6 dd if={} of =/mnt/share/{} bs=1M conv=notrunc

SMB 3.x kullanarak bağlamayı Azure Dosyalar "Bağlama hatası (115): İşlem devam ediyor"

Nedeni

Bazı Linux dağıtımları henüz SMB 3.x'te şifreleme özelliklerini desteklememektedir. Kullanıcılar, eksik bir özellik nedeniyle SMB 3.x kullanarak Azure Dosyalar bağlamayı denerse "115" hata iletisi alabilirsiniz. Tam şifrelemeye sahip SMB 3.x yalnızca Ubuntu 16.04 veya sonraki bir sürümleri kullanırken de kullanılabilir.

Çözüm

Linux için SMB 3.x şifreleme özelliği 4.11 çekirdeğinde tanıtıldı. Bu özellik Azure dosya paylaşımını şirket içinden veya farklı bir Azure bölgesinden bağlamaya olanak tanır. Bazı Linux dağıtımlarında, 4.11 çekirdeğinden linux çekirdeğinin bakımlarının daha eski sürümlerine kadar geri alan değişiklikler olabilir. Linux sürümünüz şifreleme ile SMB 3.x'i destekleyip desteklemediğni belirlemeye yardımcı olmak için Linux ile Azure Dosyalar ile birlikte kullanın.

Linux SMB istemciniz şifrelemeyi desteklemiyorsa, Azure Dosyalar'ı bağlamak için dosya paylaşımıyla aynı veri merkezinde bulunan bir Azure Linux VM'sinden SMB 2.1'i kullanın. Depolama hesabında Güvenli aktarım gerekli ayarının devre dışı bırakıldığını doğrulayın.

Azure Dosya Paylaşımına erişmeye veya silmeye çalışsanız "Erişim yok" hatası

Portalda bir Azure dosya paylaşımına erişmeye veya bu paylaşımı silebilirken aşağıdaki hatayı alabilirsiniz:

Erişim yok
Hata kodu: 403

Neden 1: Depolama hesabında sanal ağ veya güvenlik duvarı kuralları etkinleştirildi

Neden 1 için çözüm

Depolama hesabında sanal ağ ve güvenlik duvarı kurallarının düzgün yapılandırıldığını doğrulayın. Sanal ağ veya güvenlik duvarı kurallarının soruna neden olup olmadığını test etmek için depolama hesabında Tüm ağlardan erişime izin ver ayarını geçici olarak değiştirin. Daha fazla bilgi edinmek için bkz. Azure Depolama güvenlik duvarlarını ve sanal ağları yapılandırma.

Neden 2: Kullanıcı hesabınız depolama hesabına erişe değil

Neden 2 için çözüm

Azure dosya paylaşımının bulunduğu depolama hesabına gidin, Erişim denetimi (IAM) 'e tıklayın ve kullanıcı hesabının depolama hesabına erişimi olduğunu doğrulayın. Daha fazla bilgi edinmek için bkz. Azure rol tabanlı erişim denetimi (Azure RBAC)ile depolama hesabınız için güvenlik sağlama.

Azure dosya paylaşımında dosya veya dizin silinemiyor

Nedeni

Bu sorun genellikle dosyanın veya dizinin açık tanıtıcısı varsa oluşur.

Çözüm

SMB istemcileri tüm açık tanıtıcıları kapattı ve sorun devam ederse, aşağıdaki işlemleri gerçekleştirin:

• Açık tanıtıcıları görüntülemek için Get-AzStorageFileHandle PowerShell cmdlet'ini kullanın.

• Açık tanıtıcıları kapatmak için Close-AzStorageFileHandle PowerShell cmdlet'ini kullanın.

Linux sanal makinesine bağlanmış Azure dosya paylaşımında yavaş performans

Neden 1: Önbelleğe Alma

Yavaş performansın olası nedenlerinden biri önbelleğe alma devre dışıdır. Önbelleğe Alma bir dosyaya tekrar tekrar erişirken yararlı olabilir, aksi takdirde bu bir ek yük olabilir. Önbelleği devre dışı bırakmadan önce kullanıyorsanız bunu kontrol edin.

Neden 1 için çözüm

Önbelleğe alma özelliğinin devre dışı olup olmadığını kontrol etmek için cache= girdisini kontrol edin.

Cache=none, önbelleğe alma işleminin devre dışı bırakılmıştır. Varsayılan bağlama komutunu kullanarak veya varsayılan önbelleğe alma veya "katı" önbelleğe alma modunun etkinleştirildiğinden emin olmak için bağlama komutuna cache=strict seçeneğini açıkça ekleyerek paylaşımı yeniden bağlama.

Bazı senaryolarda serverino bağlama seçeneği ls komutunun her dizin girdisinde stat çalıştırmalarına neden olabilir. Bu davranış, büyük bir dizini listelerken performans düşüşüne neden olur. /etc/fstab girişindeki bağlama seçeneklerini kontrol edin:

//azureuser.file.core.windows.net/cifs /cifs cifs vers=2.1,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777

Ayrıca grep cifs komutuyla sudo bağlamasını çalıştırarak ve çıkışını | doğru seçeneklerin kullanıp kullanılmay olmadığını da kontrol edin. Örnek çıktı aşağıdaki gibidir:

//azureuser.file.core.windows.net/cifs on /cifs type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=xxx,domain=X,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.10.1,file_mode=0777, dir_mode=0777,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,actimeo=1)

cache=strict veya serverino seçeneği yoksa, belgelerden bağlama komutunu çalıştırarak Azure Dosyalar ve bağlamayı yeniden deneyin. Ardından /etc/fstab girişinin doğru seçeneklere sahip olduğunu yeniden denetleyin.

Neden 2: Azaltma

Azaltmayla karşılaşıyor ve istekleriniz bir kuyruğa gönder ediliyor olabilir. bunu doğrulamak için azure Depolama ölçümlerini Azure İzleyici.

Neden 2 için çözüm

Uygulamanın ölçek hedeflerine Azure Dosyalar emin olmak.

Dosyaları Linux'a kopyalamada zaman damgaları Windows kayboldu

Linux/Unix platformlarında, farklı kullanıcılar dosya 1 ve dosya 2'ye sahipse cp -p komutu başarısız olur.

Nedeni

COPYFILE içinde f zorlama bayrağı, Unix üzerinde cp -p -f dosyasının yürütülmesiyle sonuçlanır. Bu komut, sahip olmadığınız dosyanın zaman damgasını da koruyamaz.

Geçici çözüm

Dosyaları kopyalamak için depolama hesabı kullanıcısını kullanın:

• Useadd : [storage account name]
• Passwd [storage account name]
• Su [storage account name]
• Cp -p filename.txt /share

ls: ' yoluna < erişemedi > ': Giriş/çıkış hatası

Bir Azure dosya paylaşımında ls komutunu kullanarak dosyaları listelemeyi dene deneerek dosyaları listelerken komut askıda olur. Aşağıdaki hatayı alırsınız:

ls: < > ': Giriş/çıkış hatası' yoluna erişemedi

Çözüm

Linux çekirdeğini, bu sorun için düzeltmesi olan aşağıdaki sürümlere yükseltin:

• 4.4.87+
• 4.9.48+
• 4.12.11+
• 4.13'e eşit veya daha büyük tüm sürümler

Sembolik bağlantılar oluşturulamadı - ln: sembolik bağlantı oluşturulamadı 't': İşlem desteklenmiyor

Nedeni

Varsayılan olarak, CIFS kullanarak Azure dosya paylaşımlarını Linux'a bağlama, sembolik bağlantılar (sembolik bağlantılar) için desteği etkinleştirmez. Şöyle bir hata görüyorsunuz:

ln -s linked -n t
ln: failed to create symbolic link 't': Operation not supported

Çözüm

Linux CIFS istemcisi, SMB 2 veya 3 protokolü Windows sembolik bağlantılar oluşturulmasını desteklemez. Şu anda Linux istemcisi, oluşturma ve izleme işlemleri için Minshall+French symlinks adlı başka bir simgesel bağlantı stilini desteklemektedir. Sembolik bağlantılara ihtiyacı olan müşteriler "mfsymlinks" bağlama seçeneğini kullanabilir. Mac'ler de bu biçime sahip olduğundan "mfsymlinks" önerilir.

Symlink'leri kullanmak için CIFS bağlama komutunun sonuna aşağıdakini ekleyin:

,mfsymlinks

Bu nedenle komut aşağıdakine benzer:

sudo mount -t cifs //<storage-account-name>.file.core.windows.net/<share-name> <mount-point> -o vers=<smb-version>,username=<storage-account-name>,password=<storage-account-key>,dir_mode=0777,file_mode=0777,serverino,mfsymlinks

Daha sonra wiki'de önerilen symlink'ler oluşturabilirsiniz.

Tarayıcıdan Azure dosyaları kullanan bir Web uygulamasından hata ConditionHeadersNotSupported

Azure dosyalarında barındırılan içeriğe, Web tarayıcısı gibi koşullu üstbilgiler kullanan bir uygulama aracılığıyla erişim başarısız olduğunda ConditionHeadersNotSupported hatası oluşur. Hata, koşul başlıklarının desteklenmediğini belirtir.

Nedeni

Koşullu üstbilgiler henüz desteklenmiyor. Dosyaya her erişildiğinde uygulamanın tam dosyayı istemesi gerekecektir.

Geçici çözüm

Yeni bir dosya yüklendiğinde, Cache-Control özelliği varsayılan olarak "No-Cache" olur. Uygulamayı her seferinde dosyayı isteyecek şekilde zorlamak için, dosyanın Cache-Control özelliğinin "No-Cache" (No-Cache, No-Store,-yeniden Validate "olarak güncelleştirilmesi gerekir. Bu, Azure Depolama Gezginikullanılarak elde edilebilir.

"Bağlama hatası (112): Yeniden bağlantı zaman dildi" hatası nedeniyle konak kapatıldı

Linux istemcisi uzun süre boşta kaldığında istemcide "112" bağlama hatası oluşur. Uzun bir boşta kalma süresinden sonra istemcinin bağlantısı kesilir ve bağlantı zaman aşımına uğrar.

Nedeni

Bağlantı aşağıdaki nedenlerle boşta kalabilir:

• Varsayılan "yazılım yoluyla" bağlama seçeneği kullanıldığında sunucuyla yeniden TCP bağlantısı kurulmasını engelleyen ağ iletişim hataları
• Eski çekirdeklerde bulunmayan son yeniden bağlantı düzeltmeleri

Çözüm

Linux çekirdeğindeki bu yeniden bağlantı sorunu artık aşağıdaki değişikliklerin bir parçası olarak düzeltildi:

• Yuva yeniden bağlantısından sonra smb3 oturumunun yeniden bağlantısını geciktirmemek için yeniden bağlantı düzeltildi
• Yuva yeniden bağlantısından hemen sonra yankı hizmeti çağrısı
• CIFS: Yeniden bağlantı sırasındaki olası bellek bozulması düzeltildi
• CIFS: Yeniden bağlantı sırasında karşılıklı dışlamanın olası çift kilitlenmesi düzeltildi (çekirdek v4.9 ve üzerinde)

Öte yandan bu değişiklikler henüz tüm Linux dağıtımlarına taşınmamış olabilir. Popüler bir Linux dağıtımı kullanıyorsanız, dağıtımınızı hangi sürümünün gerekli çekirdek değişikliklerine sahip olduğunu görmek için Linux ile Azure Dosyalar'i kullanma'ya bakabilirsiniz.

Geçici çözüm

Bu soruna geçici bir çözüm olarak donanım yoluyla bağlamayı belirtebilirsiniz. Donanım yoluyla bağlama istemciyi bağlantı kurulana kadar veya açıkça kesilene kadar beklemeye zorlar. Ağ zaman aşımlarından kaynaklanan hataları önlemek için bunu kullanabilirsiniz. Öte yandan bu geçici çözüm belirsiz bekleme sürelerine neden olabilir. Gerektiğinde bağlantıları durdurmaya hazırlıklı olun.

En son çekirdek sürümlerine yükseltemiyorsanız Azure dosya paylaşımında bir dosya tutup her 30 saniyede bir (veya daha sık) bu dosyaya yazarak bu soruna geçici bir çözüm getirebilirsiniz. Bunun, dosyaya oluşturma veya değiştirme tarihini yeniden yazma gibi bir yazma işlemi olması gerekir. Aksi takdirde önbelleğe alınan sonuçlar elde edebilirsiniz ve işleminiz yeniden bağlantıyı tetiklemeyebilir.

SMB 3.x kullanarak Bir Azure dosya paylaşımını bağlarken "CIFS VFS: ioctl üzerinde -22 hatası arabirim listesi alıca" hatası

Nedeni

Bu hata günlüğe kaydedilir çünkü Azure Dosyalar şu anda çok kanallı SMB'i desteklemez.

Çözüm

Bu hata yoksayılabilir.

Sonunda boşluk veya nokta bulunan klasörlere veya dosyalara erişemiyor

Linux'a bağlıyken Azure dosya paylaşımından klasörlere veya dosyalara erişemiyorsanız, du ve ls ve/veya üçüncü taraf uygulamalar gibi komutlar paylaşıma erişirken "Böyle bir dosya veya dizin yok" hatasıyla başarısız olabilir, ancak dosyaları portal aracılığıyla söz konusu klasörlere yükleyebilirsiniz.

Nedeni

Klasör veya dosyalar, adın sonundaki karakterleri farklı bir karaktere kodlayan bir sistemden karşıya yüklendi. Bir Upload computer'dan yüklenen dosyalar, 0x20 (boşluk) veya 0X2E (nokta) yerine "0xF028" veya "0xF029" karakterine sahip olabilir.

Çözüm

Paylaşımı Linux'ta bağlama sırasında paylaşımda mapchars seçeneğini kullanın:

Onun yerine:

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino

şunu kullanın:

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino,mapchars

Yardıma mı ihtiyacınız var? Desteğe başvurun.

Yine de yardıma ihtiyacınız varsa sorunlarınızı hızla çözmek için de destekle iletişime geçin.