Komut satırından "Bu erişim denetim listesi standart biçimde değil" hatalarını düzeltme

Geliştirici iş istasyonlarımızın birçoğunda "Bu erişim kontrol listesi standart biçimde değil bu nedenle değiştirilemez." belirli klasörlerde izinleri ayarlamayı denediğimizde hata oluştu. Bu EKL'leri neyin bozduğunu bulamadık.

Şu anda, düzeltmeyi bildiğim tek yol bozuk klasörü / dosyayı sağ tıklamak, Özellikler'i seçmek ve Güvenlik sekmesini tıklamaktır. Windows daha sonra bozulmayı fark edecek ve düzeltmeyi teklif edecektir. Manuel ve kullanıcı hangi klasör / dosya bozuk olduğunu anlamak için bazı araştırmalar gerektirir çünkü bunu sevmiyorum.

Bir yerde bunu otomatik olarak yapacak bir komut dosyası veya program var mı? Bunun icaclsbir /verifyparametresi olduğunu görüyorum , ama sadece bir dosya / klasördeki ACL'lerin bozuk olduğunu gösteriyor. Hiçbir şeyi düzeltmeyi önermez.

Başka bir dosyanın acl ile currupt dosyaları acl geçersiz kılmak için basit bir PowerShell komut dosyası kullanmayı deneyebilirsiniz: get-acl path_to_file_with_known_good_acl | set-acl -path path_to_corrupt_file

Sonunda bunun için otomatik bir düzeltme anladım. PowerShell Set-Aclcmdlet'ini çağırdığınızda , ACL'leri doğru şekilde yeniden sıralar:

$path = C:\Path\To\Item\With\Borked\ACL
$acl = Get-Acl $path
Set-Acl $path $acl

Tabii ki, karışık olan dizinin bir ebeveyni olabilir, bu yüzden suçluyu bulmak için bazı traversler yapmalısınız. Bir icacls C:\Path\To\Item\With\Suspect\CL /verifyşeyin onarılması gerekip gerekmediğini anlamak için kullanın .

Ortamımızda, Cygwin olası suçludur: dizin oluşturduğunda, dosya sistemi güvenliğini yönetmek için Windows'a güvenmek yerine onlara POSIX tarzı izinler vermeyi sever.

Benim için çifte sorun vardı: NULL SID (WTH?) İçin kanonik olmayan ACL + hatalı kural bildirildi. Git'in cygwin versiyonundan kaynaklandığını düşünüyorum.

Her neyse, benim durumumda aynı ACL'nin yeniden uygulanması herhangi bir anlam ifade etmedi:

> Set-Acl $f.FullName (Get-Acl $f.FullName)
> (Get-Acl $f.FullName).AreAccessRulesCanonical
False
> (Get-Acl $f.FullName).GetAccessRules($True, $False, [System.Security.Principal.NTAccount]) | ? {$_.Identityeference.Value -eq "NULL SID" }
FileSystemRights  : WriteExtendedAttributes, ExecuteFile, DeleteSubdirectoriesAndFiles, ReadPermissions
AccessControlType : Deny
IdentityReference : NULL SID
IsInherited       : False
InheritanceFlags  : None
PropagationFlags  : None

Bu yüzden @mschneider tarafından belirtildiği gibi doğru olan dosyadan ACL'yi açıkça uygulamak zorunda kaldım

icacls da düzeltebilir:

c:\> accesschk -q FILE
Error: FILE has a non-canonical DACL:
   Explicit Deny after Explicit Allow

c:\> icacls FILE /t /q /c /reset
Successfully processed 1 files; Failed processing 0 files

c:\> accesschk -q FILE
.. OK

Diğer kullanışlı komutlar, chmod 0777 FILE eşdeğeri, chown root FILE

  icacls  FILE /t /q /c /grant    :r Everyone:F
  icacls  FILE /t /q /c /grant    :r Everyone:F /inheritance:r
  icacls  FILE /t /q /c /setowner Administrators

Cygwin kullanırken bu sorun ortaya çıkar. Windows ACL'lerinde POSIX dosya izinlerini taklit etmeye çalışır. Bu genellikle kanonik olmayan ACL'lere yol açar, bunlar yasaldır, ancak explorer.exe tarafından düzgün bir şekilde ele alınamaz .

Bu sorunlu emülasyonu "noacl" Seçeneği ile monte ederek kapatabilirsiniz, örneğin /etc/fstab:

none /cygdrive cygdrive binary,noacl,posix=0,user 0 0

1. IIS'de sorunu içeren klasörü sağ tıklayın
2. İzinleri Düzenle ...
3. Güvenlik sekmesini seçin
4. 'Düzenle' düğmesini tıklayın ve kaydedin (bu, acl'yi yeniden sıralıyor gibi görünüyor)
5. Tüm Pop-up'ları onayla