SMB Access Denied: الحساب صحيح، لكن ليش المجلد المشترك يرفضك؟

زميلك يفتح المجلد المشترك وأنت يطلع لك Access Denied. الحساب صحيح، والجهاز داخل الدومين، وقدرت تشوف اسم المشاركة. أول فكرة تجي غالبًا أن كلمة المرور فيها مشكلة، لكن رفض الوصول قد يكون نتيجة سليمة لصلاحيات المورد. نحتاج نعرف بأي هوية دخلت، وأي مسار فتحت، وأي عملية طلبت؛ بعدها نقرأ صلاحيات المشاركة وصلاحيات الملف نفسه. هذا الشرح على خادم ويندوز ومجلد NTFS داخل لاب مصرح، عشان نتعلم تشخيص الرفض بدون توسيع الصلاحيات من باب التجربة.

حدد العملية اللي انرفضت، مو بس اسم الخطأ

عبارة Access Denied تظهر في مراحل وعمليات مختلفة. يمكن تشوف المشاركة لكن ما تقدر تفتحها، أو تفتح المجلد وتعرض أسماء الملفات لكن ما تقدر تقرأ ملفًا معينًا، أو تقرأ الملف لكن ما تقدر تحفظ تعديلًا. هذي ثلاث نتائج مختلفة، وتوثيقها كلها بعبارة «المشاركة ما تشتغل» يخفي أهم معلومة في التشخيص.

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

في اللاب جهز ملفًا وهميًا لا يحتوي بيانات حساسة. تحتاج مثالًا يمكن إعادة التجربة عليه بدون فتح ملفات مستخدمين حقيقيين. ولا تختبر الحذف أو الكتابة عشان تعرف هل القراءة ممكنة؛ اختر العملية التي تجيب عن سؤالك بأقل أثر. القراءة نفسها تحتاج أن تكون داخل التصريح، لكن الكتابة والحذف يزيدان أثر الاختبار ولا يُفترضان ضمنه تلقائيًا.

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

تأكد من المورد والهوية قبل قراءة الصلاحيات

خلنا نفترض خادمًا اسمه files01.lab.test، ومشاركة اسمها TrainingShare، ومجلدًا فرعيًا اسمُه Reports. راجع أنك فتحت اسم الخادم والمشاركة الصحيحين، مو اختصارًا يشير إلى مشاركة ثانية أو جهاز قديم. اسم متشابه داخل نافذة المستكشف ما يضمن أنك على المورد نفسه الذي اختبره زميلك.

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

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

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

صلاحيات المشاركة وصلاحيات NTFS: طبقتان تحتاج تقرأهما

صلاحيات المشاركة تتحكم في الوصول عبر تلك المشاركة، وصلاحيات NTFS مرتبطة بالمجلدات والملفات الموجودة على نظام الملفات. لما تدخل عن طريق SMB، لازم تسمح الطبقتان بالعملية المطلوبة في السياق الذي نختبره. وجود سماح في واحدة ما يتجاوز قيدًا في الثانية.

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

لا تختصر الحل بجملة «خل المشاركة Full Control للجميع وارتاح». تصميم الصلاحيات يعتمد على الحاجة وهيكل المجموعات ومتطلبات البيئة. بعض التصاميم تعتمد على ضبط أدق في NTFS، لكن المختبر ما يغير سياسة الوصول من نفسه لأن تصميمًا معينًا شائع في شرح. دوره هنا يقرأ الواقع ويحدد لماذا سُمح أو رُفض الطلب.

وفي البيئات التي تستخدم خدمات ملفات أخرى أو سياسات وصول إضافية، قد يكون فيه طبقات تختلف عن مثال خادم ويندوز التقليدي. لا تعمم خطواتنا على Azure Files أو NAS أو NFS بدون مراجعة آلية التفويض الخاصة بها. اسم «مجلد مشترك» يغطي منتجات متعددة، وليس نموذج صلاحيات واحدًا في كل مكان.

الصورة: وين تشوف صلاحيات المجلد؟

الصورة الخارجية أعلاه من دليل Yubico، وتعرض تبويب Security لمجلد SoftwareShare. المجموعة المحددة فيها Administrators، ولذلك العلامات المعروضة تخص هذه المجموعة في المثال. هذي مو لقطة من لابنا، ومو دليل على صلاحيات حساب التدريب الذي سنراجعه. فائدتها أنك تعرف مكان قراءة صلاحيات نظام الملفات، وتنتبه أن اختيار اسم مختلف في القائمة يغير الصلاحيات التي تنظر لها.

تبويب Sharing ظاهر بجانب Security، لكنهما ما يعرضان الطبقة نفسها. راجع إعداد المشاركة في مكانه، وصلاحيات المجلد في مكانها. لا تلتقط صورة لتبويب Security وتكتب تحتها أنها تثبت إعدادات المشاركة الشبكية كلها.

في مراجعة حقيقية، راجع كذلك Advanced عندما تحتاج تفاصيل الإدخالات والوراثة ونطاق تطبيق الصلاحية. الواجهة المختصرة تساعدك تبدأ، لكنها لا تغني عن التفاصيل عندما تكون المشكلة في مجلد فرعي أو إدخال موروث. لا تضغط Edit أو Apply عشان تستكشف؛ القراءة شيء وتغيير الصلاحيات شيء آخر.

مصدر الصورة وسياقها الأصلي، ضمن دليل نشر YubiKey Minidriver:
https://docs.yubico.com/software/yubikey/tools/minidriver/md_auto_install.html

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

قراءة ACL من PowerShell بدون تغييرها

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

Get-Acl -LiteralPath 'D:/LabShare' | Format-List Path,Owner,Access

ولعرض إدخالات الوصول كصفوف يمكن مراجعتها:

(Get-Acl -LiteralPath 'D:/LabShare').Access | Select-Object IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags,PropagationFlags

Get-Acl يقرأ واصف الأمان، و-LiteralPath يتعامل مع المسار كما كتبته بدل تفسير أحرفه كأنها نمط بحث. نحن نستخدم أمر قراءة، وليس Set-Acl. إذا تعذر عليك قراءة الإعداد، اطلب من المسؤول توفير المخرجات المناسبة بدل افتراض أن الرفض يثبت أن الحساب لا يستطيع قراءة محتوى الملف؛ قراءة إعداد الأمان وقراءة البيانات عمليتان مختلفتان.

IdentityReference يوضح الجهة التي يخصها الإدخال، وFileSystemRights يصف الحقوق، وAccessControlType يبين السماح أو المنع. IsInherited يساعدك تعرف هل الإدخال موروث. لكن مجرد استخراج صف لمجموعة ما لا يحسب تلقائيًا وصول حسابك الفعلي؛ تحتاج مراجعة عضويته وسياق العملية وبقية الإدخالات ذات الصلة.

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

icacls مفيد، لكن انتبه للخيارات اللي تضيفها

بديل القراءة من الطرفية هو icacls، المتوفر على ويندوز. لمجلد التدريب نفسه:

icacls 'D:/LabShare'

هذا المثال يعرض DACL للمسار المحدد. الأداة نفسها تستطيع تعديل الصلاحيات بخيارات أخرى، ولذلك الاسم وحده ما يعني أن كل استخدام لها قراءة. لا تضف grant أو reset أو تغيير المالك إلى أمر التشخيص. هذي تغييرات لها أثر فعلي، وتحتاج خطة إدارية وتصريحًا منفصلًا عن مجرد مراجعة الإعداد.

في الإخراج قد ترى اختصارات مثل R للقراءة وM للتعديل وF للصلاحية الكاملة، وعلامات وراثة مثل I. ارجع للدليل الرسمي إذا ظهر حق متقدم أو علامة ما تعرفها، ولا تحذفها من الناتج عشان تبسطه. تحديد هل الإدخال ينطبق على المجلد نفسه أو على الأبناء مهم جدًا في تفسير الفرق بين مجلد وملف تحته.

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

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

المجموعات المتداخلة والوراثة: ليش اسمك مو ظاهر؟

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

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

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

لا تختصر كل مراجعة لعبارة «Deny يفوز دائمًا». ترتيب الإدخالات ونوعها ونطاقها وسياق الطلب لها أهمية، ولا يصح قراءة سطر منع منفرد خارج البقية. إذا احتجت حساب الوصول الفعلي، استخدم وسائل المراجعة المعتمدة مع المسؤول واختبارًا محدودًا بالحساب المقصود. المطلوب نتيجة قابلة للتفسير، وليس قاعدة محفوظة تطبقها بدون النظر إلى الحالة.

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

سيناريو: تعرض أسماء الملفات، لكن واحد منها يرفض الفتح

المشاركة TrainingShare تسمح لمجموعة TrainingReaders بالقراءة، والمجلد الرئيسي يعرض أسماء الملفات للحساب التجريبي. داخل Reports، يوجد ملف training-summary.txt وآخر finance-example.txt، وكلاهما بيانات وهمية. الحساب يفتح الأول، ويرفض الثاني. عندك الآن دليل أن الخدمة والمسار يعملان في سياق جزئي، وليس دليلًا على فشل المشاركة كاملة.

راجع ACL الملف الثاني وقارنه بالأول، ثم راجع المجلد الفرعي. ربما الملف الثاني مخصص لمجموعة FinanceTraining، أو أُنشئ بإعداد مختلف، أو لم يرث الإدخالات كما تتوقع. لا تحتاج تعطيل حماية الخادم لتفصل هالاحتمالات؛ تحتاج مقارنة الإعدادات والهوية والعملية.

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

سيناريو آخر: سياسة اللاب تقول إن الجميع في TrainingReaders يحتاجون الملفين، لكن المسؤول وجد أن أحد الملفات لم يرث إدخال القراءة المقصود. هذا أقرب إلى خلل إعداد أو مشكلة تشغيلية في المثال. وثق الفرق وأثره، ويقرر صاحب المورد التعديل المناسب. لا تقفز لإعطاء Full Control لمجموعة واسعة لأن قراءة ملف واحد كانت ناقصة.

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

وش تكتب في التقرير بعد التشخيص؟

ابدأ بالمورد والحساب والعملية. مثلًا: «في مشاركة TrainingShare على files01.lab.test، تمكن حساب التدريب من عرض أسماء محتويات Reports، لكنه تلقى Access Denied عند قراءة finance-example.txt». بعده تذكر ما أكدته مراجعة الإعدادات، وما بقي احتمالًا يحتاج تحققًا. تفصل هكذا بين المشاهدة والتفسير.

إذا كانت النتيجة من مراجعة إدارية فقط، قل إن الاستنتاج مبني على ACL والعضوية المعروضة، ولا تدّع أنك اختبرت وصولًا فعليًا. وإذا كانت من محاولة قراءة ملف تجريبي، اذكر ذلك. الجمع بين السياقين مفيد، لكن كل دليل له حدوده ولا يغني عن الآخر في جميع الحالات.

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

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

احتفظ بالتفاصيل الحقيقية في تقرير داخلي معتمد. أما مقال التعلم أو معرض أعمالك، استخدم أسماء وهمية وصورًا من اللاب أو مصادر خارجية موضحة، بدون كشف قوائم موظفين أو ملفات أو بنية تخزين خاصة.

إذا بتتدرب: خلك على ملف واحد وفرضية واحدة

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

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

لأساسيات التعامل مع المشاركة من لينكس، راجع شرح smbclient:
https://courses.cyberpts.com/community/59/shrh-smbclient-afhs-msharkat-almlfat-wafhm-slahyatha-khtwh-bkhtwh
ولفهم المجموعة المتداخلة، راجع شرح Get-ADGroupMember:
https://courses.cyberpts.com/community/64/shrh-get-adgroupmember-lysh-almstkhdm-ywsl-llmjmwah-wasmh-mw-zahr-byn-aadayha

المراجع الفنية للقراءة:
Get-Acl في وثائق Microsoft:
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-acl
دليل icacls:
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/icacls
مثال Microsoft على فصل صلاحيات المشاركة عن المسار الفعلي، في سياق استضافة IIS:
https://learn.microsoft.com/en-us/iis/web-hosting/configuring-servers-in-the-windows-web-platform/configuring-share-and-ntfs-permissions

لما تشوف Access Denied مرة ثانية، ابدأ بالسؤال الصغير: أي حساب طلب أي عملية على أي عنصر؟ بعده اقرأ الطبقات المرتبطة بالطلب. غالبًا هنا ينكشف السبب، ويكون عندك تفسير واضح بدل تجربة صلاحيات أوسع كل مرة.