استكشاف مشكلات ملفات Azure وإصلاحها في Windows (SMB)

  • مقالة
  • قراءة خلال 23 دقائق

تسرد هذه المقالة المشكلات الشائعة المتعلقة بملفات Microsoft Azure عند الاتصال من عملاء Windows. كما أنه يوفر الأسباب والحلول المحتملة لهذه المشاكل. بالإضافة إلى خطوات استكشاف الأخطاء وإصلاحها في هذه المقالة، يمكنك أيضا استخدامها AzFileDiagnostics للتأكد من أن بيئة عميل Windows تحتوي على المتطلبات الأساسية الصحيحة. AzFileDiagnostics أتمتة الكشف عن معظم الأعراض المذكورة في هذه المقالة ويساعد على إعداد البيئة الخاصة بك للحصول على الأداء الأمثل.

هام

ينطبق محتوى هذه المقالة فقط على مشاركات SMB. للحصول على تفاصيل حول مشاركات NFS، راجع استكشاف أخطاء مشاركات ملفات Azure NFS وإصلاحها.

ينطبق على

نوع مشاركة الملف SMB NFS
مشاركات الملفات القياسية (GPv2)، LRS/ZRS Yes No
مشاركات الملفات القياسية (GPv2)، GRS/GZRS Yes No
مشاركات الملفات المتميزة (FileStorage)، LRS/ZRS Yes No

خطأ 5 عند تحميل مشاركة ملف Azure

عند محاولة تحميل مشاركة ملف، قد تتلقى الخطأ التالي:

  • حدث خطأ في النظام 5. تم رفض الوصول.

السبب 1: قناة اتصال غير مشفرة

لأسباب أمنية، يتم حظر الاتصالات بمشاركات ملفات Azure إذا لم تكن قناة الاتصال مشفرة وإذا لم تتم محاولة الاتصال من نفس مركز البيانات الذي توجد فيه مشاركات ملف Azure. إذا تم تمكين الإعداد المطلوب للنقل الآمن على حساب التخزين، أيضا حظر الاتصالات غير المشفرة داخل مركز البيانات نفسه. يتم توفير قناة اتصال مشفرة فقط إذا كان نظام التشغيل العميل للمستخدم النهائي يدعم تشفير SMB.

Windows 8 و Windows Server 2012 والإصدارات الأحدث من كل نظام التفاوض على الطلبات التي تتضمن SMB 3.x الذي يدعم التشفير.

الحل للسبب 1

  1. الاتصال من عميل يدعم تشفير SMB (Windows 8/Windows Server 2012 أو إصدار أحدث).
  2. الاتصال من جهاز ظاهري في نفس مركز البيانات مثل حساب تخزين Azure المستخدم لمشاركة ملف Azure.
  3. تحقق من تعطيل الإعداد المطلوب النقل الآمن على حساب التخزين إذا كان العميل لا يدعم تشفير SMB.

السبب 2: تمكين قواعد الشبكة الظاهرية أو جدار الحماية على حساب التخزين

يتم رفض حركة مرور الشبكة إذا تم تكوين قواعد الشبكة الظاهرية (VNET) وجدار الحماية على حساب التخزين، ما لم يتم السماح بإدراج عنوان IP الخاص بالعميل أو الشبكة الظاهرية.

الحل للسبب 2

تحقق من تكوين قواعد الشبكة الظاهرية وجدار الحماية بشكل صحيح على حساب التخزين. لاختبار ما إذا كانت قواعد الشبكة الظاهرية أو جدار الحماية هي السبب في حدوث المشكلة، قم بتغيير الإعداد الموجود على حساب التخزين مؤقتا للسماح بالوصول من جميع الشبكات. لمعرفة المزيد، راجع تكوين جدران الحماية Azure Storage والشبكات الظاهرية.

السبب 3: أذونات مستوى المشاركة غير صحيحة عند استخدام المصادقة المستندة إلى الهوية

إذا كان المستخدمون النهائيون يصلون إلى مشاركة ملف Azure باستخدام مصادقة Active Directory (AD) أو Azure Active Directory Domain Services (Azure AD DS)، يفشل الوصول إلى مشاركة الملف بسبب الخطأ "تم رفض الوصول" إذا كانت أذونات مستوى المشاركة غير صحيحة.

الحل للسبب 3

تحقق من تكوين الأذونات بشكل صحيح:

  • Active Directory (AD) راجع تعيين أذونات على مستوى المشاركة إلى هوية.

    يتم دعم تعيينات الأذونات على مستوى المشاركة للمجموعات والمستخدمين الذين تمت مزامنتهم من Active Directory (AD) إلى Azure Active Directory (Azure AD) باستخدام Azure AD الاتصال. تأكد من أن المجموعات والمستخدمين الذين يتم تعيينهم أذونات على مستوى المشاركة ليسوا مجموعات "سحابية فقط" غير مدعومة.

  • Azure Active Directory Domain Services (Azure AD DS) راجع تعيين أذونات الوصول إلى هوية.

الخطأ 53 أو الخطأ 67 أو الخطأ 87 عند تحميل مشاركة ملف Azure أو إلغاء تحميلها

عند محاولة تحميل مشاركة ملف من محلي أو من مركز بيانات مختلف، قد تتلقى الأخطاء التالية:

  • حدث خطأ في النظام 53. لم يتم العثور على مسار شبكة الاتصال.
  • حدث خطأ في النظام 67. لا يمكن العثور على اسم الشبكة.
  • حدث خطأ في النظام 87. المعلمة غير صحيحة.

السبب 1: تم حظر المنفذ 445

يمكن أن يحدث خطأ في النظام 53 أو خطأ في النظام 67 إذا تم حظر اتصال المنفذ 445 الصادر بمركز بيانات Azure Files. للاطلاع على ملخص مزودي خدمات الإنترنت الذين يسمحون بالوصول من المنفذ 445 أو لا يسمحون به، انتقل إلى TechNet.

للتحقق مما إذا كان جدار الحماية أو موفر خدمة الإنترنت يحظران المنفذ AzFileDiagnostics 445، استخدم الأداة أو Test-NetConnection cmdlet.

لاستخدام Test-NetConnection cmdlet، يجب تثبيت الوحدة النمطية Azure PowerShell، راجع Test-NetConnection لمزيد من المعلومات. تذكر استبدال <your-storage-account-name> الأسماء ذات الصلة بحساب التخزين الخاص بك وبأسمائها <your-resource-group-name> .

$resourceGroupName = "<your-resource-group-name>"
$storageAccountName = "<your-storage-account-name>"

# This command requires you to be logged into your Azure account and set the subscription your storage account is under, run:
# Connect-AzAccount -SubscriptionId ‘xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx’
# if you haven't already logged in.
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName

# The ComputerName, or host, is <storage-account>.file.core.windows.net for Azure Public Regions.
# $storageAccount.Context.FileEndpoint is used because non-Public Azure regions, such as sovereign clouds
# or Azure Stack deployments, will have different hosts for Azure file shares (and other storage resources).
Test-NetConnection -ComputerName ([System.Uri]::new($storageAccount.Context.FileEndPoint).Host) -Port 445

إذا كان الاتصال ناجحا ، فيجب أن تشاهد الإخراج التالي:

ComputerName     : <your-storage-account-name>
RemoteAddress    : <storage-account-ip-address>
RemotePort       : 445
InterfaceAlias   : <your-network-interface>
SourceAddress    : <your-ip-address>
TcpTestSucceeded : True

ملاحظة

يرجع الأمر أعلاه عنوان IP الحالي لحساب التخزين. عنوان IP هذا غير مضمون للبقاء كما هو، وقد يتغير في أي وقت. لا تقم بترميز عنوان IP هذا في أي برامج نصية أو في تكوين جدار حماية.

الحل للسبب 1

الحل 1 — استخدام Azure File Sync

يمكن ل Azure File Sync تحويل خادم Windows المحلي إلى ذاكرة تخزين مؤقت سريعة لمشاركة ملفات Azure. يمكنك استخدام أي بروتوكول متوفر على Windows Server للوصول لبياناتك محليًا، بما في ذلك بروتوكولات SMB وNFS وFTPS. يعمل Azure File Sync عبر المنفذ 443 وبالتالي يمكن استخدامه كحل بديل للوصول إلى ملفات Azure من العملاء الذين تم حظر المنفذ 445 عليهم. تعرف على كيفية إعداد Azure File Sync.

الحل 2 — استخدام VPN

من خلال إعداد VPN لحساب التخزين الخاص بك ، ستمر حركة المرور عبر نفق آمن بدلا من الإنترنت. اتبع الإرشادات لإعداد VPN للوصول إلى ملفات Azure من Windows.

الحل 3 — إلغاء حظر المنفذ 445 بمساعدة مسؤول موفر خدمة الإنترنت/تكنولوجيا المعلومات

اعمل مع قسم تكنولوجيا المعلومات أو موفر خدمة الإنترنت لفتح المنفذ 445 الصادر إلى نطاقات Azure IP.

الحل 4 — استخدم الأدوات المستندة إلى واجهة برمجة تطبيقات REST مثل مستكشف التخزين/PowerShell

يدعم Azure Files أيضا REST بالإضافة إلى SMB. يعمل الوصول إلى REST عبر المنفذ 443 (tcp القياسي). هناك العديد من الأدوات التي تتم كتابتها باستخدام واجهة برمجة تطبيقات REST التي تتيح تجربة واجهة مستخدم غنية. مستكشف التخزين هو واحد منهم. قم بتنزيل مستكشف التخزين وتثبيته والاتصال بمشاركة الملفات المدعومة بملفات Azure. يمكنك أيضا استخدام PowerShell الذي يستخدم أيضا واجهة برمجة تطبيقات REST.

السبب 2: تم تمكين NTLMv1

يمكن أن يحدث خطأ في النظام 53 أو خطأ في النظام 87 إذا تم تمكين اتصال NTLMv1 على العميل. يدعم Azure Files مصادقة NTLMv2 فقط. يؤدي تمكين NTLMv1 إلى إنشاء عميل أقل أمانا. لذلك، يتم حظر الاتصال لملفات Azure.

لتحديد ما إذا كان هذا هو سبب الخطأ، تحقق من عدم تعيين مفتاح التسجيل الفرعي التالي إلى قيمة أقل من 3:

HKLM \ النظام \\ CurrentControlSet \ التحكم \\ Lsa LmCompatibilityLevel

لمزيد من المعلومات، راجع الموضوع LmCompatibilityLevel على TechNet.

الحل للسبب 2

إرجاع قيمة LmCompatibilityLevel إلى القيمة الافتراضية 3 في مفتاح التسجيل الفرعي التالي:

HKLM \\ النظام \\ CurrentControlSet \ التحكم \\ Lsa

خطأ 1816 - لا تتوفر حصة نسبية كافية لمعالجة هذا الأمر

السبب

يحدث الخطأ 1816 عند الوصول إلى الحد الأعلى من المقابض المفتوحة المتزامنة المسموح بها لملف أو دليل على مشاركة ملف Azure. لمزيد من المعلومات، راجع أهداف مقياس ملفات Azure.

حل

تقليل عدد المقابض المفتوحة المتزامنة عن طريق إغلاق بعض المقابض ثم إعادة المحاولة. لمزيد من المعلومات، راجع قائمة التحقق من أداء Microsoft Azure Storage وقابلية التوسع.

لعرض المقابض المفتوحة لمشاركة ملف أو دليل أو ملف، استخدم cmdlet Get-AzStorageFileHandle PowerShell.

لإغلاق المقابض المفتوحة لمشاركة ملف أو دليل أو ملف، استخدم cmdlet إغلاق AzStorageFileHandle PowerShell.

ملاحظة

يتم تضمين Get-AzStorageFileHandle و cmdlets Close-AzStorageFileHandle في الإصدار 2.4 من الوحدة النمطية Az PowerShell أو إصدار أحدث. لتثبيت أحدث وحدة نمطية Az PowerShell، راجع تثبيت وحدة Azure PowerShell النمطية.

خطأ "لا يوجد وصول" عند محاولة الوصول إلى مشاركة ملفات Azure أو حذفها

عند محاولة الوصول إلى مشاركة ملف Azure أو حذفها في البوابة الإلكترونية، قد تتلقى الخطأ التالي:

لا يمكن الوصول
رمز الخطأ: 403

السبب 1: تمكين قواعد الشبكة الظاهرية أو جدار الحماية على حساب التخزين

الحل للسبب 1

تحقق من تكوين قواعد الشبكة الظاهرية وجدار الحماية بشكل صحيح على حساب التخزين. لاختبار ما إذا كانت قواعد الشبكة الظاهرية أو جدار الحماية هي السبب في حدوث المشكلة، قم بتغيير الإعداد الموجود على حساب التخزين مؤقتا للسماح بالوصول من جميع الشبكات. لمعرفة المزيد، راجع تكوين جدران الحماية Azure Storage والشبكات الظاهرية.

السبب 2: حساب المستخدم الخاص بك ليس لديه حق الوصول إلى حساب التخزين

الحل للسبب 2

استعرض للوصول إلى حساب التخزين حيث توجد مشاركة ملف Azure، وانقر فوق التحكم في الوصول (IAM) وتحقق من أن حساب المستخدم الخاص بك لديه حق الوصول إلى حساب التخزين. لمعرفة المزيد، راجع كيفية تأمين حساب التخزين الخاص بك باستخدام التحكم في الوصول المستند إلى دور Azure (Azure RBAC).

غير قادر على تعديل أو حذف مشاركة ملف Azure (أو مشاركة لقطات) بسبب الأقفال أو عقود الإيجار

توفر ملفات Azure طريقتين لمنع التعديل أو الحذف غير المقصود لمشاركات ملفات Azure ومشاركة اللقطات:

  • تأمين موارد حساب التخزين: تدعم جميع موارد Azure، بما في ذلك حساب التخزين، عمليات تأمين الموارد. قد يتم وضع الأقفال على حساب التخزين بواسطة مسؤول، أو بواسطة خدمات ذات قيمة مضافة مثل Azure Backup. توجد نوعان مختلفان من أقفال الموارد: تعديل، مما يمنع جميع التعديلات على حساب التخزين وموارده، والحذف، الذي يمنع فقط حذف حساب التخزين وموارده. عند تعديل المشاركات أو حذفها من خلال موفر الموارد Microsoft.Storage ، يتم فرض تأمين الموارد على مشاركات ملفات Azure ومشاركة اللقطات. تستخدم Microsoft.Storage معظم عمليات البوابة الإلكترونية، وأوامر Azure PowerShell cmdlets لملفات Azure مع Rm الاسم (أي )، وأوامر Azure CLI في share-rm مجموعة الأوامر (أي Get-AzRmStorageShareaz storage share-rm list) موفر الموارد. تستخدم بعض الأدوات والأدوات المساعدة مثل مستكشف التخزين وأوامر إدارة ملفات Azure القديمة PowerShell بدون Rm الاسم (أي ) وأوامر CLI القديمة من Azure Files ضمن share مجموعة الأوامر (أي Get-AzStorageShareaz storage share list) واجهات برمجة التطبيقات القديمة في واجهة برمجة تطبيقات FileREST التي تتجاوز Microsoft.Storage موفر الموارد وأقفال الموارد. لمزيد من المعلومات حول واجهات برمجة تطبيقات الإدارة القديمة التي تم عرضها في واجهة برمجة تطبيقات FileREST، راجع مستوى التحكم في ملفات Azure.

  • عقود إيجار اللقطات للمشاركة/المشاركة: تعد عقود إيجار الأسهم نوعا من القفل الخاص بمشاركات ملفات Azure ولقطات مشاركة الملفات. قد يتم وضع عقود الإيجار على مشاركات ملفات Azure الفردية أو لقطات مشاركة الملفات بواسطة المسؤولين عن طريق استدعاء واجهة برمجة التطبيقات من خلال برنامج نصي، أو عن طريق خدمات ذات قيمة مضافة مثل Azure Backup. عند وضع عقد إيجار على مشاركة ملف Azure أو لقطة مشاركة ملف، يمكن تعديل أو حذف لقطة مشاركة/مشاركة الملف باستخدام معرف التأجير. يمكن للمسؤولين أيضا تحرير عقد الإيجار قبل عمليات التعديل ، والتي تتطلب معرف الإيجار ، أو كسر عقد الإيجار ، الذي لا يتطلب معرف الإيجار. لمزيد من المعلومات حول عقود إيجار الأسهم، راجع تأجير الأسهم.

نظرا لأن عمليات تأمين الموارد وعقود الإيجار قد تتداخل مع عمليات المسؤول المقصودة على حسابات التخزين/مشاركات ملفات Azure، فقد ترغب في إزالة أي أقفال/عقود إيجار للموارد تم وضعها على مواردك يدويا أو تلقائيا بواسطة خدمات ذات قيمة مضافة مثل Azure Backup. يزيل البرنامج النصي التالي كافة أقفال الموارد وعقود الإيجار. تذكر أن تحل محل <resource-group> القيم المناسبة لبيئتك وبقيمها <storage-account> .

لتشغيل البرنامج النصي التالي، يجب تثبيت الإصدار 3.10.1 معاينة من الوحدة النمطية PowerShell التخزين Azure.

هام

قد تقوم الخدمات ذات القيمة المضافة التي تأخذ أقفال الموارد وتشارك/مشاركة عقود إيجار اللقطات على موارد Azure Files بإعادة تطبيق عمليات التأمين وعقود الإيجار بشكل دوري. قد يؤثر تعديل الموارد المقفلة أو حذفها بواسطة الخدمات ذات القيمة المضافة على التشغيل المنتظم لتلك الخدمات، مثل حذف لقطات المشاركة التي تمت إدارتها بواسطة Azure Backup.

# Parameters for storage account resource
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"

# Get reference to storage account
$storageAccount = Get-AzStorageAccount `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName

# Remove resource locks
Get-AzResourceLock `
        -ResourceType "Microsoft.Storage/storageAccounts" `
        -ResourceGroupName $storageAccount.ResourceGroupName `
        -ResourceName $storageAccount.StorageAccountName | `
    Remove-AzResourceLock -Force | `
    Out-Null

# Remove share and share snapshot leases
Get-AzStorageShare -Context $storageAccount.Context | `
    Where-Object { $_.Name -eq $fileShareName } | `
    ForEach-Object {
        try {
            $leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($_.ShareClient)
            $leaseClient.Break() | Out-Null
        } catch { }
    }

غير قادر على تعديل ملف أو دليل أو نقله/إعادة تسميته أو حذفه

أحد الأغراض الرئيسية لمشاركة الملفات هو أن العديد من المستخدمين والتطبيقات قد يتفاعلون في وقت واحد مع الملفات والدلائل في المشاركة. للمساعدة في هذا التفاعل، توفر مشاركات الملفات عدة طرق للتوسط في الوصول إلى الملفات والدلائل.

عند فتح ملف من مشاركة ملف Azure مثبتة عبر SMB، يطلب التطبيق/نظام التشغيل مقبض ملف، وهو مرجع إلى الملف. من بين أمور أخرى، يحدد تطبيقك وضع مشاركة الملفات عندما يطلب مقبض ملف، والذي يحدد مستوى حصرية وصولك إلى الملف الذي تفرضه Azure Files:

  • Noneلديك وصول حصري.:
  • Readقد يقرأ الآخرون الملف أثناء فتحه.:
  • Writeقد يكتب آخرون إلى الملف أثناء فتحه.:
  • ReadWriteمزيج من كل من وضعي Read المشاركة والمشاركة Write .:
  • Deleteقد يقوم الآخرون بحذف الملف أثناء فتحه.:

على الرغم من أن بروتوكول FileREST كبروتوكول عديم الجنسية لا يحتوي على مفهوم مقابض الملفات ، إلا أنه يوفر آلية مماثلة للتوسط في الوصول إلى الملفات والمجلدات التي قد يستخدمها البرنامج النصي أو التطبيق أو الخدمة: عقود إيجار الملفات. عند تأجير ملف، يتم التعامل معه على أنه مكافئ لمقبض ملف مع وضع مشاركة الملفات .None

على الرغم من أن مقابض الملفات وعقود الإيجار تخدم غرضا مهما، إلا أنه في بعض الأحيان قد تكون مقابض الملفات وعقود الإيجار يتيمة. عند حدوث ذلك، يمكن أن يسبب هذا مشاكل في تعديل الملفات أو حذفها. قد تظهر لك رسائل خطأ مثل:

  • يتعذر على العملية الوصول إلى الملف لأنه يتم استخدامه بواسطة عملية أخرى.
  • لا يمكن إكمال الإجراء لأن الملف مفتوح في برنامج آخر.
  • يتم تأمين المستند للتحرير بواسطة مستخدم آخر.
  • يتم وضع علامة على المورد المحدد للحذف بواسطة عميل SMB.

يعتمد حل هذه المشكلة على ما إذا كان هذا ناتجا عن معالجة ملف يتيم أو تأجير.

السبب 1

يمنع مقبض الملف ملف/دليل من التعديل أو الحذف. يمكنك استخدام cmdlet Get-AzStorageFileHandle PowerShell لعرض المقابض المفتوحة.

إذا قام كافة عملاء SMB بإغلاق المقابض المفتوحة الخاصة بهم على ملف/دليل واستمرت المشكلة في الحدوث، يمكنك فرض إغلاق مقبض ملف.

الحل 1

لفرض إغلاق مقبض ملف، استخدم cmdlet إغلاق AzStorageFileHandle PowerShell.

ملاحظة

يتم تضمين Get-AzStorageFileHandle و cmdlets Close-AzStorageFileHandle في الإصدار 2.4 من الوحدة النمطية Az PowerShell أو إصدار أحدث. لتثبيت أحدث وحدة نمطية Az PowerShell، راجع تثبيت وحدة Azure PowerShell النمطية.

السبب 2

يمنع تأجير الملف من تعديل ملف أو حذفه. يمكنك التحقق مما إذا كان الملف يحتوي على تأجير ملف باستخدام PowerShell التالي، واستبداله <resource-group><file-share><storage-account>بالقيم <path-to-file> المناسبة للبيئة الخاصة بك:

# Set variables 
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"
$fileShareName = "<file-share>"
$fileForLease = "<path-to-file>"

# Get reference to storage account
$storageAccount = Get-AzStorageAccount `
        -ResourceGroupName $resourceGroupName `
        -Name $storageAccountName

# Get reference to file
$file = Get-AzStorageFile `
        -Context $storageAccount.Context `
        -ShareName $fileShareName `
        -Path $fileForLease

$fileClient = $file.ShareFileClient

# Check if the file has a file lease
$fileClient.GetProperties().Value

إذا كان الملف يحتوي على عقد إيجار ، فيجب أن يحتوي الكائن الذي تم إرجاعه على الخصائص التالية:

LeaseDuration         : Infinite
LeaseState            : Leased
LeaseStatus           : Locked

الحل 2

لإزالة عقد إيجار من ملف، يمكنك تحرير عقد الإيجار أو كسر عقد الإيجار. لتحرير عقد الإيجار ، تحتاج إلى LeaseId الخاص بعقد الإيجار ، والذي تقوم بتعيينه عند إنشاء عقد الإيجار. لا تحتاج إلى LeaseId لكسر عقد الإيجار.

يوضح المثال التالي كيفية كسر عقد الإيجار للملف المشار إليه في السبب 2 (يستمر هذا المثال مع متغيرات PowerShell من السبب 2):

$leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($fileClient)
$leaseClient.Break() | Out-Null

بطء نسخ الملفات من وإلى Azure Files في Windows

قد ترى أداء بطيئا عند محاولة نقل الملفات إلى خدمة Azure File.

  • إذا لم يكن لديك حد أدنى محدد لمتطلبات حجم الإدخال/الإخراج، فإننا نوصي باستخدام 1 ميجابت كحجم إدخال/إخراج للحصول على الأداء الأمثل.
  • إذا كنت تعرف الحجم النهائي للملف الذي تقوم بتوسيعه باستخدام عمليات الكتابة ، ولم يكن لدى برنامجك مشاكل في التوافق عندما يحتوي الذيل غير المكتوب على الملف على أصفار ، فقم بتعيين حجم الملف مقدما بدلا من جعل كل كتابة موسعة.
  • استخدم طريقة النسخ الصحيحة:
    • استخدم AzCopy لأي نقل بين مشاركتين للملفات.
    • استخدم Robocopy بين مشاركات الملفات على كمبيوتر محلي.

اعتبارات Windows 8.1 أو Windows Server 2012 R2

بالنسبة للعملاء الذين يقومون بتشغيل Windows 8.1 أو Windows Server 2012 R2، تأكد من تثبيت الإصلاح العاجل KB3114025. يعمل هذا الإصلاح العاجل على تحسين أداء مقابض الإنشاء والإغلاق.

يمكنك تشغيل البرنامج النصي التالي للتحقق مما إذا كان قد تم تثبيت الإصلاح العاجل:

reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies

إذا تم تثبيت الإصلاح العاجل، يتم عرض الإخراج التالي:

HKEY_Local_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies {96c345ef-3cac-477b-8fcd-bea1a564241c} REG_DWORD 0x1

ملاحظة

تحتوي صور Windows Server 2012 R2 في Azure Marketplace على الإصلاح العاجل KB3114025 مثبتا بشكل افتراضي، بدءا من كانون الأول/ديسمبر عام 2015.

لا يوجد مجلد يحتوي على حرف محرك أقراص في "جهاز الكمبيوتر" أو "هذا الكمبيوتر"

إذا قمت بتعيين مشاركة ملف Azure كمسؤول باستخدام الاستخدام الصافي، فستظهر المشاركة مفقودة.

السبب

بشكل افتراضي، لا يتم تشغيل مستكشف الملفات Windows كمسؤول. إذا قمت بتشغيل net use من موجه أوامر إداري، يمكنك تعيين محرك أقراص الشبكة كمسؤول. نظرا لأن محركات الأقراص المعينة تتمحور حول المستخدم، فإن حساب المستخدم الذي تم تسجيل الدخول إليه لا يعرض محركات الأقراص إذا تم تحميلها ضمن حساب مستخدم مختلف.

حل

قم بتحميل المشاركة من سطر أوامر غير مسؤول. بدلا من ذلك، يمكنك اتباع موضوع TechNet هذا لتكوين قيمة التسجيل EnableLinkedConnections .

فشل الأمر Net use إذا كان حساب التخزين يحتوي على شرطة مائلة للأمام

السبب

يفسر الأمر net use شرطة مائلة للأمام (/) كخيار سطر أوامر. إذا بدأ اسم حساب المستخدم الخاص بك بشرطة مائلة للأمام، فهذا يعني فشل تعيين محرك الأقراص.

حل

يمكنك استخدام أي من الخطوات التالية كمحاولة للتغلب على هذه المشكلة:

  • تشغيل أمر PowerShell التالي:

    New-SmbMapping -LocalPath y: -RemotePath \\server\share -UserName accountName -Password "password can contain / and \ etc"

    من ملف دفعي، يمكنك تشغيل الأمر بهذه الطريقة:

    Echo new-smbMapping ... | powershell -command –

  • ضع علامات اقتباس مزدوجة حول المفتاح كمحاولة للتغلب على هذه المشكلة - ما لم تكن الشرطة المائلة للأمام هي الحرف الأول. إذا كان الأمر كذلك ، فاستخدم الوضع التفاعلي وأدخل كلمة المرور الخاصة بك بشكل منفصل أو أعد إنشاء مفاتيحك للحصول على مفتاح لا يبدأ بشرطة مائلة للأمام.

يتعذر على التطبيق أو الخدمة الوصول إلى محرك أقراص Azure Files محمول

السبب

يتم تركيب محركات الأقراص لكل مستخدم. إذا كان التطبيق أو الخدمة قيد التشغيل ضمن حساب مستخدم مختلف عن الحساب الذي قام بتركيب محرك الأقراص، فلن يرى التطبيق محرك الأقراص.

حل

استخدم أحد الحلول التالية:

  • قم بتركيب محرك الأقراص من نفس حساب المستخدم الذي يحتوي على التطبيق. يمكنك استخدام أداة مثل PsExec.

  • تمرير اسم حساب التخزين والمفتاح في معلمات اسم المستخدم وكلمة المرور الخاصة بالأمر net use.

  • استخدم الأمر cmdkey لإضافة بيانات الاعتماد إلى إدارة بيانات الاعتماد. قم بإجراء ذلك من سطر أوامر ضمن سياق حساب الخدمة ، إما من خلال تسجيل دخول تفاعلي أو باستخدام runas.

    cmdkey /add:<storage-account-name>.file.core.windows.net /user:AZURE\<storage-account-name> /pass:<storage-account-key>

  • قم بتعيين المشاركة مباشرة دون استخدام حرف محرك أقراص معين. قد لا تقوم بعض التطبيقات بإعادة الاتصال بحرف محرك الأقراص بشكل صحيح، لذا فإن استخدام مسار UNC الكامل قد يكون أكثر موثوقية.

    net use * \\storage-account-name.file.core.windows.net\share

بعد اتباع هذه الإرشادات، قد تتلقى رسالة الخطأ التالية عند تشغيل net use لحساب خدمة النظام/الشبكة: "حدث خطأ في النظام 1312. جلسة عمل تسجيل دخول محددة غير موجودة. ربما تم إنهاؤها بالفعل". في حالة حدوث ذلك، تأكد من أن اسم المستخدم الذي يتم تمريره إلى صافي الاستخدام يتضمن معلومات المجال (على سبيل المثال: "[اسم حساب التخزين].file.core.windows.net").

خطأ "أنت تقوم بنسخ ملف إلى وجهة لا تدعم التشفير"

عندما يتم نسخ ملف عبر الشبكة، يتم فك تشفير الملف على الكمبيوتر المصدر، ويتم إرساله بنص عادي، وإعادة تشفيره في الوجهة. ومع ذلك، قد ترى الخطأ التالي عند محاولة نسخ ملف مشفر: "أنت تنسخ الملف إلى وجهة لا تدعم التشفير".

السبب

يمكن أن تحدث هذه المشكلة إذا كنت تستخدم نظام تشفير الملفات (EFS). يمكن نسخ الملفات المشفرة بواسطة BitLocker إلى ملفات Azure. ومع ذلك، لا تدعم ملفات Azure NTFS EFS.

الحل البديل

لنسخ ملف عبر الشبكة، يجب عليك أولا فك تشفيره. استخدم أحد الأساليب التالية:

  • استخدم الأمر نسخ /d . يسمح بحفظ الملفات المشفرة كملفات تم فك تشفيرها في الوجهة.
  • تعيين مفتاح التسجيل التالي:
    • المسار = HKLM \ البرامج \\ السياسات \\ مايكروسوفت \ Windows \\ النظام
    • نوع القيمة = DWORD
    • الاسم = CopyFileAllowDecryptedRemoteDestination
    • القيمة = 1

كن على علم بأن تعيين مفتاح التسجيل يؤثر على كافة عمليات النسخ التي يتم إجراؤها على مشاركات الشبكة.

التعداد البطيء للملفات والمجلدات

السبب

يمكن أن تحدث هذه المشكلة إذا لم يكن هناك ذاكرة تخزين مؤقت كافية على الجهاز العميل للدلائل الكبيرة.

حل

لحل هذه المشكلة، ضبط قيمة التسجيل DirectoryCacheEntrySizeMax للسماح التخزين المؤقت لقوائم الدليل أكبر في الجهاز العميل:

  • الموقع: ⁧HKLM\System\CCS\Services\Lanmanworkstation\Parameters⁩
  • اسم القيمة: DirectoryCacheEntrySizeMax
  • نوع القيمة: DWORD

على سبيل المثال ، يمكنك تعيينه ومعرفة 0x100000 ما إذا كان الأداء يتحسن أم لا.

خطأ AadDsTenantNotFound في تمكين مصادقة Azure Active Directory Domain Service (Azure AD DS) لملفات Azure "غير قادر على تحديد موقع المستأجرين النشطين باستخدام معرف المستأجر aad-tenant-id"

السبب

يحدث الخطأ AadDsTenantNotFound عند محاولة تمكين مصادقة خدمات مجال Azure Active Directory (Azure AD DS) على ملفات Azure على حساب تخزين حيث لا يتم إنشاء Azure AD Domain Service(Azure AD DS) على مستأجر Azure AD للاشتراك المقترن.

حل

قم بتمكين Azure AD DS على مستأجر Azure AD للاشتراك الذي تم نشر حساب التخزين الخاص بك إليه. تحتاج إلى امتيازات المسؤول لمستأجر Azure AD لإنشاء مجال مدار. إذا لم تكن مسؤول مستأجر Azure AD، فاتصل بالمسؤول واتبع الإرشادات خطوة بخطوة لإنشاء مجال مدار من خدمات مجال Azure Active Directory Domain Services وتكوينه.

Error ConditionHeadersNotSupported من تطبيق ويب باستخدام ملفات Azure من المستعرض

يحدث الخطأ ConditionHeadersNotSupported عند الوصول إلى المحتوى المستضاف في ملفات Azure من خلال تطبيق يستخدم الرؤوس الشرطية، مثل مستعرض ويب، يفشل الوصول. يشير الخطأ إلى أن رؤوس الشروط غير معتمدة.

Azure Files conditional headers error

السبب

الرؤوس الشرطية غير مدعومة بعد. ستحتاج التطبيقات التي تنفذها إلى طلب الملف الكامل في كل مرة يتم فيها الوصول إلى الملف.

الحل البديل

عند تحميل ملف جديد، تكون خاصية التحكم في ذاكرة التخزين المؤقت افتراضيا هي "بدون ذاكرة تخزين مؤقت". لإجبار التطبيق على طلب الملف في كل مرة، يجب تحديث خاصية التحكم في ذاكرة التخزين المؤقت للملف من "بدون ذاكرة تخزين مؤقت" إلى "بدون ذاكرة تخزين مؤقت أو تخزين أو إعادة التحقق من الصحة". ويمكن تحقيق ذلك باستخدام مستكشف تخزين Azure.

Storage explorer content cache modification for Azure Files conditional headers

غير قادر على تحميل ملفات Azure باستخدام بيانات اعتماد AD

خطوات التشخيص الذاتي

أولا، تأكد من اتباع جميع الخطوات الأربع لتمكين مصادقة Azure Files AD.

ثانيا، حاول تركيب مشاركة ملف Azure باستخدام مفتاح حساب التخزين. إذا فشلت في التحميل، فقم بالتنزيل AzFileDiagnostics لمساعدتك في التحقق من صحة بيئة تشغيل العميل، واكتشاف تكوين العميل غير المتوافق الذي قد يتسبب في فشل الوصول إلى ملفات Azure، وتقديم إرشادات إرشادية حول الإصلاح الذاتي، وجمع آثار التشخيص.

ثالثا ، يمكنك تشغيل Debug-AzStorageAccountAuth cmdlet لإجراء مجموعة من الفحوصات الأساسية على تكوين AD الخاص بك مع مستخدم AD الذي قام بتسجيل الدخول. يتم دعم هذا cmdlet على إصدار AzFilesHybrid v0.1.2 +. تحتاج إلى تشغيل cmdlet هذا مع مستخدم AD لديه إذن المالك على حساب التخزين المستهدف.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -Verbose

يقوم cmdlet بإجراء هذه الفحوصات أدناه بالتسلسل ويوفر إرشادات للفشل:

  1. CheckADObjectPasswordIsCorrect: تأكد من أن كلمة المرور التي تم تكوينها على هوية AD التي تمثل حساب التخزين تتطابق مع كلمة مرور مفتاح kerb1 أو kerb2 لحساب التخزين. إذا كانت كلمة المرور غير صحيحة، يمكنك تشغيل Update-AzStorageAccountADObjectPassword لإعادة تعيين كلمة المرور.
  2. CheckADObject: تأكد من وجود كائن في Active Directory يمثل حساب التخزين وله SPN الصحيح (الاسم الأساسي للخدمة). إذا لم يتم إعداد SPN بشكل صحيح، الرجاء تشغيل cmdlet Set-AD الذي تم إرجاعه في cmdlet تصحيح الأخطاء لتكوين SPN.
  3. CheckDomainJoined: تحقق من أن الجهاز العميل هو مجال متصل ب AD. إذا لم يكن جهازك مرتبطا بنطاق AD، فيرجى الرجوع إلى هذه المقالة للحصول على تعليمات الانضمام إلى النطاق.
  4. CheckPort445Connectivity: تحقق من فتح المنفذ 445 للاتصال بالشركات الصغيرة والمتوسطة. إذا لم يكن المنفذ المطلوب مفتوحا، فيرجى الرجوع إلى أداة AzFileDiagnostics استكشاف الأخطاء وإصلاحها بحثا عن مشكلات الاتصال بملفات Azure.
  5. CheckSidHasAadUser: تحقق من مزامنة مستخدم AD الذي قام بتسجيل الدخول إلى Azure AD. إذا كنت تريد البحث عما إذا كان مستخدم AD معين قد تمت مزامنته مع Azure AD، فيمكنك تحديد -UserName و-Domain في معلمات الإدخال.
  6. CheckGetKerberosTicket: حاول الحصول على تذكرة Kerberos للاتصال بحساب التخزين. إذا لم يكن هناك رمز Kerberos صالح ، فقم بتشغيل klist احصل على cifs / storage-account-name.file.core.windows.net cmdlet وافحص رمز الخطأ للتسبب الجذري في فشل استرداد التذكرة.
  7. CheckStorageAccountDomainJoined: تحقق مما إذا تم تمكين مصادقة الإعلان وتمت تعبئة خصائص الإعلان الخاصة بالحساب. إذا لم يكن الأمر كذلك، فراجع الإرشادات هنا لتمكين مصادقة AD DS على ملفات Azure.
  8. CheckUserRbacAssignment: تحقق مما إذا كانت هوية AD تحتوي على تعيين دور RBAC المناسب لتوفير إذن مستوى المشاركة للوصول إلى ملفات Azure. إذا لم يكن الأمر كذلك ، فراجع التعليمات هنا لتكوين إذن مستوى المشاركة. (مدعوم على إصدار AzFilesHybrid v0.2.3+ )
  9. CheckUserFileAccess: تحقق مما إذا كانت هوية AD لديها إذن الدليل/الملف المناسب (Windows قوائم التحكم في الوصول) للوصول إلى ملفات Azure. إذا لم يكن الأمر كذلك ، فراجع التعليمات هنا لتكوين إذن مستوى الدليل / الملف. (مدعوم على إصدار AzFilesHybrid v0.2.3+ )

غير قادر على تكوين أذونات مستوى الدليل/الملف (Windows قوائم التحكم في الوصول) باستخدام مستكشف الملفات Windows

Symptom

قد تواجه أي من الأعراض الموضحة أدناه عند محاولة تكوين قوائم التحكم في الوصول Windows باستخدام مستكشف الملفات على مشاركة ملف محملة:

  • بعد النقر فوق تحرير الإذن ضمن علامة التبويب أمان ، لا يتم تحميل معالج الأذونات.
  • عند محاولة تحديد مستخدم جديد أو مجموعة جديدة، لا يعرض موقع المجال مجال AD DS الصحيح.

حل

نوصيك باستخدام أداة icacls لتكوين أذونات مستوى الدليل/الملف كحل بديل.

أخطاء عند تشغيل Join-AzStorageAccountForAuth cmdlet

خطأ: "تعذر على خدمة الدليل تخصيص معرف نسبي"

قد يحدث هذا الخطأ إذا كانت وحدة تحكم مجال التي تحتفظ بدور RID Master FSMO غير متوفرة أو تمت إزالتها من المجال واستعادتها من النسخة الاحتياطية. تأكد من أن كافة وحدات تحكم المجال قيد التشغيل ومتوفرة.

خطأ: "لا يمكن ربط المعلمات الموضعية لأنه لم يتم إعطاء أسماء"

من المرجح أن يتم تشغيل هذا الخطأ بسبب خطأ في بناء الجملة في الأمر Join-AzStorageAccountforAuth. تحقق من الأمر بحثا عن الأخطاء الإملائية أو أخطاء بناء الجملة وتحقق من تثبيت أحدث إصدار من الوحدة النمطية AzFilesHybrid (https://github.com/Azure-Samples/azure-files-samples/releases) .

دعم مصادقة Azure Files المحلية AD DS لتشفير AES 256 Kerberos

يدعم Azure Files دعم تشفير AES 256 Kerberos لمصادقة AD DS مع الوحدة النمطية AzFilesHybrid v0.2.2. إذا قمت بتمكين مصادقة AD DS باستخدام إصدار وحدة نمطية أقل من الإصدار 0.2.2، فستحتاج إلى تنزيل أحدث وحدة AzFilesHybrid (الإصدار 0.2.2+) وتشغيل PowerShell أدناه. إذا لم تقم بتمكين مصادقة AD DS على حساب التخزين الخاص بك حتى الآن، فيمكنك اتباع هذه الإرشادات للتمكين.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

هوية المستخدم التي كانت في السابق تملك تعيين دور المالك أو المساهم لا يزال لديها حق الوصول إلى مفتاح حساب التخزين

يمنح دور مالك حساب التخزين والمساهم القدرة على إدراج مفاتيح حساب التخزين. يتيح مفتاح حساب التخزين الوصول الكامل إلى بيانات حساب التخزين بما في ذلك مشاركات الملفات وحاويات blob والجداول وقوائم الانتظار والوصول المحدود إلى عمليات إدارة ملفات Azure عبر واجهات برمجة تطبيقات الإدارة القديمة التي يتم عرضها من خلال واجهة برمجة تطبيقات FileREST. إذا كنت تقوم بتغيير تعيينات الأدوار، يجب أن تضع في اعتبارك أن المستخدمين الذين تتم إزالتهم من أدوار المالك أو المساهم قد يستمرون في الاحتفاظ بحق الوصول إلى حساب التخزين من خلال مفاتيح حساب التخزين المحفوظ.

الحل 1

يمكنك علاج هذه المشكلة بسهولة عن طريق تدوير مفاتيح حساب التخزين. نوصي بتدوير المفاتيح واحدة تلو الأخرى ، وتبديل الوصول من واحد إلى آخر أثناء تدويرها. هناك نوعان من المفاتيح المشتركة التي يوفرها حساب التخزين: مفاتيح حساب التخزين، التي توفر وصول المسؤول المتميز إلى بيانات حساب التخزين، ومفاتيح Kerberos، التي تعمل كسر مشترك بين حساب التخزين ووحدة تحكم مجال Active Directory Windows Server لسيناريوهات Active Directory ل Windows Server Active Directory.

لتدوير مفاتيح Kerberos لحساب تخزين، راجع تحديث كلمة مرور هوية حساب التخزين في AD DS.

انتقل إلى حساب التخزين المطلوب في مدخل Azure. في جدول المحتويات لحساب التخزين المطلوب، حدد مفاتيح Access ضمن عنوان الأمان + الشبكة . في جزء مفتاح الوصول*، حدد تدوير المفتاح أعلى المفتاح المطلوب.

A screenshot of the access key pane

هل تحتاج إلى مساعدة؟ الاتصال بالدعم.

إذا كنت لا تزال بحاجة إلى مساعدة، فاتصل بالدعم لحل مشكلتك بسرعة.