امتلأ قرص Mac ولا يوجد عليه شيء؟ افحصوا مجلد سجلات حساب Root

إليكم مشكلة تخزين تتغلب على كل أداة يلجأ إليها معظم الناس عادة.

يخبركم جهاز Mac أن القرص شارف على الامتلاء. تفتحون أداة لتحليل التخزين وتجمعون ما وجدته — فيكون المجموع أقل بعشرات الغيغابايتات مما يقول macOS إنه مستخدم. تُفيد أداة Disk Utility بعدم وجود لقطات (snapshots). تحذفون التطبيقات، وتُفرغون الصور إلى مكان آخر، وتُفرغون سلة المهملات، بينما لا يتحرك الرقم إلا بالكاد. تساعد إعادة التشغيل لمدة ساعة، ثم تختفي المساحة مجددًا.

الملفات حقيقية. أدواتكم لا تستطيع رؤيتها لأنها موجودة في /private/var/root — المجلد الرئيسي (home directory) لحساب root — وكل واحدة من تلك الأدوات تعمل بصفتكم أنتم.

في أجهزة Mac التي تتأثر بهذه المشكلة بأشد صورها، يكون معظم السبب شيئًا واحدًا: ملفات سجلات يكتبها عفريت نظام (daemon) يُدعى rtcreportingd، بكميات تصل إلى عشرات الغيغابايتات. وثّق Michael Tsai حالة في 21 أغسطس 2026 كان فيها مجلد /private/var/root/Library/Logs وحده يستهلك 74 غيغابايت على جهاز MacBook Air بمعالج M4، وعاد فيها المجلد إلى 27 غيغابايت خلال يوم واحد فقط بعد إفراغه.

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

أبرز النقاط

• /private/var/root غير مرئي لأي شيء يعمل بصفتكم كمستخدم. تحققنا على macOS 26.5.2 من أن الأمر ls /private/var/root يُرجع Permission denied. أدوات تحليل التخزين وFinder وأرقام الاستخدام في Disk Utility، كلها تُغفل ما بداخله.
• rtcreportingd عفريت نظام حقيقي من Apple يعمل بصلاحيات root. تحققنا من أن مهمة launchd الخاصة به تُعلن UserName => root، وهذا بالضبط سبب انتهاء سجلاته في المجلد الرئيسي لـ root بدلًا من مجلدكم الخاص.
• الأحجام المُبلَّغ عنها تصل إلى عشرات الغيغابايتات، وتعاود النمو بسرعة. 74 غيغابايت في حالة موثّقة، وعودة إلى 27 غيغابايت خلال يوم واحد من الحذف، لأن السبب الجذري كان لا يزال يعمل.
• الخطأ الشائع يُفسد المهمة برمّتها. حذف الملفات بأداة رسومية تعمل تحت sudo ينقلها إلى سلة مهملات root غير المرئية. لا تُستعاد المساحة. عليكم الحذف الفوري، أو إفراغ سلة مهملات root.
• ابحثوا عن عميل مزامنة عالق. في الحالة الموثّقة كان كل من rtcreportingd وfileproviderd عالقين قرب 100% من استخدام المعالج، وأدى إنهاء Dropbox إلى إيقاف كليهما. fileproviderd هو عملية macOS التي تستضيف إضافات File Provider الخاصة بالتخزين السحابي.
• لا تحذفوا أشياء في /private/var/root عشوائيًا. السجلات (logs) والذواكر المؤقتة (caches) آمنة للحذف. الأشياء الأخرى هناك ليست كذلك، وهذا المقال محدد بشأن ما هو ما.

لماذا لا تستطيع أدوات التخزين رؤيتها

قبل الحل، الآلية — لأن فهمها هو ما يمنعكم من ملاحقة الشيء الخطأ في المرة القادمة.

لدى Root مجلد رئيسي، وعفاريت النظام تستخدمه

على macOS، المجلد الرئيسي لحساب root هو /private/var/root. يفترض معظم الناس أنه فارغ أساسًا ولا يُلمَس إلا عند تشغيل Terminal من macOS Recovery. لم يعد هذا صحيحًا منذ سنوات. عفاريت النظام التي تعمل بصلاحيات root وتريد تخزين حالتها أو ذاكرتها المؤقتة أو سجلاتها تكتبها هناك، ضمن نفس بنية Library التي يستخدمها مجلدكم الرئيسي الخاص:

/private/var/root/Library/Logs
/private/var/root/Library/Caches

يمكنكم التأكد من أن هذا المجلد محظور عليكم بأمر واحد. على جهاز Mac لا يملك فيه Terminal صلاحيات مرتفعة:

ls /private/var/root

نفّذنا هذا الأمر بالضبط على macOS 26.5.2 (الإصدار 25F84) وحصلنا على:

ls: /private/var/root: Permission denied

هذا رفض أذونات Unix عادي — المجلد الرئيسي لـ root مقيَّد بالوضع (mode) لصالح root فقط. إنه ليس حماية خصوصية من نوع TCC، وليس شيئًا يُصلحه Full Disk Access. أداة تحليل التخزين التي شغّلتموها من الـ Dock تعمل بصفتكم أنتم، فهي تتجول في نظام الملفات بصفتكم، وكل ما تحت ذلك المجلد يمثل ثغرة في خريطتها.

لهذا السبب تختلف الأرقام

العرض الذي يصفه الناس هو «مجاميع أداة التخزين عندي لا تتطابق»، وهذا هو السبب. في الحالة الموثّقة، بلغت مجاميع مجلدات OmniDiskSweeper أقل بنحو 90 غيغابايت مما أفاد macOS بأنه مستخدم.

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

عرض Howard Oakley الحسابات العامة في 21 أغسطس 2026، والأرقام من جهاز Mac mini الخاص به توضح الفكرة:

المصدر	القيمة المُبلَّغ عنها كمستخدم على نفس وحدة التخزين
الفرق في الحاوية عبر diskutil apfs list	837.101 GB
مجموع Capacity Consumed لكل وحدة تخزين	837.027 GB
Get Info في Finder للوحدة	826.67 GB
Disk Utility	814.03 GB

أربع أدوات، أربعة أرقام، وفارق يبلغ نحو 23 غيغابايت، ولا خطأ في ذلك على الإطلاق. تنشأ الفروق من احتساب الحاوية مقابل وحدة التخزين، والمساحة القابلة للتطهير (purgeable space)، وسلوك الملفات الخاصة في نظام APFS:

• الحاوية مقابل وحدة التخزين. تضم حاوية APFS عدة وحدات تخزين تتشارك المساحة الحرة. «المساحة الحرة على Macintosh HD» و«المساحة الحرة في الحاوية» سؤالان مختلفان لهما إجابتان مختلفتان.
• المساحة القابلة للتطهير. يُصنّف macOS بعض المحتوى على أنه قابل للإزالة عند الحاجة — ذواكر مؤقتة، وبعض اللقطات، وبعض المحتوى الذي تم تنزيله. يقول دليل مساعدة Disk Utility نفسه: «لا يمكنكم إزالة الملفات المُصنَّفة على أنها قابلة للتطهير يدويًا، لكن macOS يزيلها عند الحاجة إلى المساحة.» قاس Oakley 47.04 غيغابايت قابلة للتطهير على وحدة Data الخاصة به.
• الملفات الخاصة. تتشارك ملفات النسخ المستنسخة (clone) في APFS مساحة التخزين حتى تتباين؛ وتُخزّن الملفات المتناثرة (sparse) بياناتها غير الفارغة فقط؛ وبعض ملفات النظام مضغوطة؛ والملفات عديمة البيانات (dataless) تحتفظ ببياناتها في السحابة وتتجسّد عند الطلب. يعتمد احتساب المساحة الحرة على ما هو موجود فعليًا على القرص الآن.

لا شيء من ذلك ينتج عنه فارق دائم ومتنامٍ وغير مُفسَّر بمقدار 90 غيغابايت. إذا كانت الفجوة عندكم صغيرة وثابتة، فهذا احتساب طبيعي. أما إذا كانت كبيرة وتتنامى بينما جهاز Mac خامل، فهناك شيء يكتب ملفات لا يمكنكم رؤيتها.

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

ما هو rtcreportingd فعليًا

لنكن صادقين بشأن حدود معرفتنا هنا، لأن الإنترنت على وشك أن يمتلئ بتفسيرات واثقة لعفريت نظام لم توثّقه Apple قط.

ما تحققنا منه مباشرة، على macOS 26.5.2 (الإصدار 25F84):

الملف التنفيذي موجود في /usr/libexec/rtcreportingd وحجمه نحو 1.45 ميغابايت. مهمة launchd الخاصة به موجودة في /System/Library/LaunchDaemons/com.apple.rtcreportingd.plist، ونصّها كالتالي:

{
  "EnablePressuredExit" => true
  "EnableTransactions" => true
  "Label" => "com.apple.rtcreportingd"
  "MachServices" => {
    "com.apple.rtcreportingd" => true
  }
  "ProgramArguments" => [
    0 => "/usr/libexec/rtcreportingd"
  ]
  "UserName" => "root"
}

تحققوا منها على جهاز Mac الخاص بكم — ملف plist قابل للقراءة من الجميع:

plutil -p /System/Library/LaunchDaemons/com.apple.rtcreportingd.plist

UserName => root هو التفسير الكامل لوجهة السجلات. عفريت نظام يعمل بصلاحيات root ويكتب إلى ~/Library/Logs يكتب إلى /private/var/root/Library/Logs. لا شيء غريب في الأمر.

الملف الثنائي مكتوب بلغة Swift، وأسماء أصنافه (classes) الداخلية مرئية عبر الأمر strings. وتشمل BackendHTTP وTransparencyLog وStorebagCache وStorebagCoordinator وSessionCoordinator وXPCActivity — ولاحظوا هذا الاسم — CacheCleanupActivity. وتشمل أسماء خدمات Mach الخاصة به com.apple.rtcreporting وcom.apple.rtcreporting.pathmonitor وcom.apple.rtcreportingd.storebag.

ما لن نخبركم به هو معنى اختصار «RTC» أو ما الذي يُبلّغ عنه هذا العفريت بالضبط. لا توثّقه Apple، ولن نخترع توسيعًا لاختصار ونقدمه كحقيقة. ما تدعمه أسماء الأصناف هو وصف متواضع: إنها خدمة إبلاغ أو قياس عن بُعد (telemetry) تتواصل مع خلفية (backend) تابعة لـ Apple عبر HTTP، وتخزّن الحالة مؤقتًا محليًا، وتراقب توفر مسار الشبكة، ولديها نشاط مجدوَل لتنظيف ذاكرتها المؤقتة الخاصة.

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

توضيحًا للحدود هنا: هذا استنتاج من أسماء الأصناف، وليس تصريحًا بشأن تنفيذ Apple الفعلي. تعاملوا معه كفرضية تصادف أنها تتوافق مع السلوك المُلاحَظ.

العثور على المساحة

ستحتاجون إلى sudo لكل ما يلي، وينبغي أن تقرؤوا كل أمر قبل تنفيذه.

1. تأكدوا من وجود الفجوة

أولًا، ما يعتقد macOS أنه مستخدم:

df -h / /System/Volumes/Data

على جهاز Mac حديث ستحصلون على سطرين، لأن وحدة تخزين النظام لقطة مختومة للقراءة فقط، بينما تعيش بياناتكم في وحدة تخزين منفصلة داخل نفس الحاوية. على جهاز الاختبار لدينا:

Filesystem        Size    Used   Avail Capacity  Mounted on
/dev/disk3s1s1   926Gi    12Gi   331Gi     4%    /
/dev/disk3s5     926Gi   568Gi   331Gi    64%    /System/Volumes/Data

لاحظوا أن كلا السطرين يُفيدان بنفس قيمتي Size وAvail — وهذه هي المساحة الحرة المشتركة في الحاوية، لا حصة خاصة بكل وحدة تخزين على حدة. هذا هو الفارق بين الحاوية ووحدة التخزين الذي ذكرناه سابقًا، مجسَّدًا هنا بشكل ملموس.

بعد ذلك تحققوا من اللقطات، حتى تستبعدوها:

diskutil apfs listSnapshots /System/Volumes/Data

وعرض الحاوية:

diskutil apfs list

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

2. قيسوا المجلد الرئيسي لـ root

هذا هو الأمر الذي يعثر عليها:

sudo du -h -d 2 /private/var/root/

يحصر -d 2 العمق في مستويين، وهذا كافٍ لمعرفة ما إذا كان Library/Logs أو Library/Caches هو المتسبب دون انتظار اجتياز كامل. توقعوا أن يستغرق الأمر دقيقة أو دقيقتين على جهاز فيه مُسبِّب كبير للمشكلة.

للحصول على عرض مُرتَّب لأسوأ المتسببين على مستوى أعمق بدرجة واحدة:

sudo du -h -d 3 /private/var/root/Library | sort -h | tail -20

على جهاز Mac سليم، تكون هذه المجاميع صغيرة — ميغابايتات لا غيغابايتات. فإذا أعاد /private/var/root/Library/Logs رقمًا يليه حرف «G» وأكثر من رقم واحد قبله، فتلك هي مساحتكم المفقودة.

3. اطّلعوا على المحتوى

قبل حذف أي شيء، ألقوا نظرة:

sudo ls -la /private/var/root/Library/Logs
sudo du -h -d 1 /private/var/root/Library/Logs | sort -h | tail

في الحالة الموثّقة كانت المحتويات «تكاد تكون بالكامل من RTCReporting». إذا كان محتواكم يهيمن عليه شيء آخر، فذلك يغيّر ما ينبغي عليكم فعله — يظل نهج التشخيص في هذا المقال ساريًا، لكن المتسبب سيكون نظامًا فرعيًا مختلفًا.

4. بديل بواجهة رسومية

إذا كنتم تفضلون رؤية هذا في نافذة، فإن OmniDiskSweeper مجانية وهي ما كشف المشكلة في التقرير الأصلي. الجزء المهم هو أنه يجب عليكم إعادة تشغيلها بصلاحيات مرتفعة حتى تتمكن من رؤية المجلد الرئيسي لـ root. عند تشغيلها بشكل عادي ستُظهر لكم نفس الصورة الناقصة التي تُظهرها كل الأدوات الأخرى.

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

استعادة المساحة — والخطأ الذي يُفسد المهمة برمّتها

إليكم الفخ، وهو فخ محكم.

إذا حذفتم هذه الملفات بأداة رسومية تعمل تحت sudo، فستفعل الأداة ما تفعله دائمًا: نقلها إلى سلة المهملات. لكن بما أن العملية تعمل بصلاحيات root، فتلك هي سلة مهملات root، الموجودة في /private/var/root/.Trash، والتي لا تظهر في الـ Dock لديكم ولن يخطر ببالكم إفراغها أبدًا. تبقى الملفات على القرص. لا تتغير مساحتكم الحرة. فتستنتجون أن الحذف لم ينجح.

في OmniDiskSweeper تحديدًا، اضغطوا مع الاستمرار على مفتاح Option لتحويل Delete إلى Delete Immediately.

من Terminal، احذفوا محتوى السجلات مباشرة:

sudo rm -rf /private/var/root/Library/Logs/*

اقرؤوا هذا الأمر قبل تنفيذه. إنه يحذف محتويات مجلد Logs الخاص بـ root وليس شيئًا آخر. لا تختصروا المسار. ولا تضيفوا مسافة قبل الشرطة المائلة.

بعد ذلك تحققوا مما إذا كان هناك شيء في سلة مهملات root من محاولة سابقة:

sudo du -sh /private/var/root/.Trash

وإن وُجد:

sudo rm -rf /private/var/root/.Trash/*

الذواكر المؤقتة (caches) في مجلد root الرئيسي آمنة أيضًا للمسح بشكل عام — فهي، بحكم تعريفها، قابلة لإعادة التوليد:

sudo du -h -d 1 /private/var/root/Library/Caches | sort -h | tail

ما لا يجب لمسه. لا تحذفوا /private/var/root نفسه. لا تحذفوا /private/var/root/Library بالكامل. لا تُقدِموا على إزالة سلاسل مفاتيح (keychains) أو تفضيلات أو أي شيء لا تعرفونه. السجلات والذواكر المؤقتة هما الفئتان الآمنتان؛ أما كل شيء آخر هناك فينتمي إلى مكوّن نظام وضعه هناك لسبب ما.

أعيدوا تشغيل الجهاز بعد ذلك. ثم تحققوا مجددًا بالأمر df -h للتأكد من أن المساحة عادت فعلًا.

الآن اعثروا على المسبِّب

إذا توقفتم عند الحذف، فستعود المساحة إلى الامتلاء ثم تختفي مجددًا. في الحالة الموثّقة، عادت إلى 5 غيغابايت خلال دقائق من إعادة التشغيل و27 غيغابايت خلال يوم واحد.

راقبوا المعالج

افتحوا Activity Monitor، رتّبوا حسب % CPU، وابحثوا عن عمليتين:

• rtcreportingd — العفريت الذي يكتب السجلات
• fileproviderd — عملية macOS التي تستضيف إضافات File Provider الخاصة بالتخزين السحابي

في الحالة الموثّقة، كانت كلتاهما عالقتين باستمرار قرب 100% من استخدام المعالج، على جهاز Mac خامل.

من Terminal:

ps -Ao pid,pcpu,comm | grep -E 'rtcreportingd|fileproviderd'

توجد هاتان العمليتان وتعملان على أي جهاز Mac سليم — تحققنا من عملهما على جهاز الاختبار لدينا، الذي لا يعاني من أي مشكلة تخزين على الإطلاق. وجودهما طبيعي. أما استخدامهما المستمر والمرتفع للمعالج فليس كذلك. بضع نقاط مئوية أثناء تقدم عملية مزامنة أمر متوقع. أما البقاء عند 90-100% بينما جهاز Mac لا يُلمَس فهي الإشارة الفارقة.

راقبوا نمو السجلات

أكثر طريقة تأكيد مباشرة هي القياس مرتين:

sudo du -sh /private/var/root/Library/Logs

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

اشتبهوا في مزامنة السحابة أولًا

fileproviderd هو المؤشر الفاضح. إنه عملية النظام التي تستضيف إضافات File Provider — الآلية الحديثة التي تستخدمها Dropbox وOneDrive وGoogle Drive وBox وiCloud Drive جميعًا لعرض الملفات السحابية في Finder. إذا كانت تستهلك المعالج باستمرار، فإحدى تلك الإضافات عالقة.

في الحالة الموثّقة كان العميل هو Dropbox، على جهاز Mac كان يسيء التصرف فيه منذ نحو عام — لا يُبقي الملفات غير متصلة (offline) كما هو مُهيَّأ، ويبدو وكأنه يزامن باستمرار رغم عدم تغيّر شيء. أدى إنهاء Dropbox إلى إيقاف استخدام المعالج ونمو السجلات فورًا.

لاختبار هذا على جهاز Mac الخاص بكم، أنهوا عملاء المزامنة لديكم واحدًا تلو الآخر وراقبوا النتيجة. أنهوا العميل بالكامل — عبر أيقونة شريط القوائم، ثم Quit — بدلًا من إيقاف المزامنة مؤقتًا، لأن الإضافة الموقوفة مؤقتًا قد تظل محمَّلة.

# after quitting a sync client, check whether the load dropped
ps -Ao pid,pcpu,comm | grep -E 'rtcreportingd|fileproviderd'

إذا أدى إنهاء أحد العملاء إلى عودة العمليتين إلى حالة الخمول، فقد وجدتم المسبِّب.

ماذا تفعلون حيال عميل المزامنة

الخيارات، مرتبة تقريبًا حسب مقدار الجهد المطلوب:

1. حدّثوه. أخطاء إضافات File Provider شائعة وتُصلَح كثيرًا. تحققوا من وجود تحديث قبل أي شيء آخر.
2. سجّلوا الخروج ثم الدخول مجددًا. يُعيد هذا بناء الحالة المحلية للإضافة، ويحل عددًا مفاجئًا من حالات المزامنة العالقة.
3. أزيلوا العميل وأعيدوا تثبيته. أكثر إزعاجًا لكنه أشمل.
4. انقلوا البيانات إلى مكان آخر. في الحالة الموثّقة كانت النتيجة الانتقال إلى iCloud Drive، بعدما تبيّن أن Dropbox غير قادر على تنزيل الملفات بشكل موثوق لأغراض النقل — فانتهى الأمر بالكاتب إلى تنزيل المجلد من واجهة Dropbox على الويب بدلًا من ذلك. بعدها قام iCloud Drive «برفع كل شيء بسرعة ثم استقر في حالة عدم استخدام للمعالج».

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

نحن لا نقول إن Dropbox هو المذنب الوحيد. إنه العميل في الحالة الموثّقة فحسب. يمكن لأي إضافة File Provider أن تعلق، والتشخيص واحد أيًّا كان العميل الذي تستخدمونه.

الأماكن الأخرى التي تختبئ فيها المساحة عنكم

المجلد الرئيسي لـ root هو المكان الذي لا يتحقق منه أحد تقريبًا، لكنه ليس المكان الوحيد الذي تقصر فيه أداة تعمل على مستوى المستخدم. إذا لم تكن فجوتكم في /private/var/root، فاعملوا على مراجعة ما يلي قبل أن تستنتجوا أن الأرقام تكذب.

بيانات مملوكة لـ root تخص عفاريت أخرى. /private/var/root هو موقع المجلد الرئيسي لـ root، لكن مكوّنات النظام تكتب أيضًا تحت /private/var/db و/private/var/folders و/Library/Logs. قيسوها بنفس الطريقة:

sudo du -h -d 1 /private/var/db | sort -h | tail
sudo du -h -d 1 /Library/Logs | sort -h | tail
sudo du -sh /private/var/folders

يحتوي /private/var/folders على حاويات مؤقتة وذواكر مؤقتة خاصة بكل مستخدم، ويمكن أن يصل بشكل مشروع إلى عدة غيغابايتات. يُدار هذا المجلد بواسطة macOS وينبغي عمومًا تركه دون تدخل؛ تُزيل إعادة التشغيل الأجزاء المتقلبة منه.

لقطات Time Machine المحلية. هذا هو السبب الأكثر اتهامًا والأقل ذنبًا في الواقع. تحققوا بدلًا من الافتراض:

tmutil listlocalsnapshots /
diskutil apfs listSnapshots /System/Volumes/Data

إذا كانت اللقطات هي المشكلة فعلًا، فإن macOS يُقلّصها تلقائيًا تحت ضغط نقص المساحة، وتُغطّى الحالات الأعمق في دليلنا لاستكشاف أخطاء Time Machine وإصلاحها.

المجلدات الرئيسية لمستخدمين آخرين. واضح بمجرد ذكره، لكنه غير مرئي عمليًا — حساب ثانٍ على جهاز Mac يحتوي على 200 غيغابايت من الفيديو ليس شيئًا ستُظهره لكم أداة التخزين وهي تعمل بصفتكم. يجيب sudo du -h -d 1 /Users عن هذا في سطر واحد.

ملفات مفتوحة تحتفظ بها عملية قيد التشغيل. مساحة تم حذفها لكنها لم تتحرر، لأن عملية ما لا تزال تحتفظ بواصف الملف (file descriptor). يظهر هذا كفجوة تختفي بعد إعادة التشغيل:

sudo lsof / 2>/dev/null | grep -i deleted | head

مخزن Mail المحلي، ونسخ أجهزة iOS الاحتياطية، وXcode. المجلدات الثلاثة الكلاسيكية الكبيرة والمنسية على جهاز Mac لمطوّر أو لمستخدم مكثّف لتطبيق Mail:

du -sh ~/Library/Mail
du -sh ~/Library/Application\ Support/MobileSync/Backup
du -sh ~/Library/Developer/Xcode/{DerivedData,iOS\ DeviceSupport,Archives} 2>/dev/null

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

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

ما مدى شيوع هذه المشكلة؟

الإجابة الصادقة: لا نعرف، ولا يعرف أحد آخر ممن ينشرون عن هذا الموضوع.

ما هو موجود في السجل العام هو رواية مباشرة بأرقام محددة وحل محدد، وموضوع نقاش في Apple Support Community حول مساحة RTCReporting، وموضوع نقاش على Reddit من مستخدمين يسألون عمّا يستهلك مساحتهم. هذا كافٍ لإثبات أن المشكلة حقيقية وقابلة للتكرار، لكنه غير كافٍ لتحديد نسبة أجهزة Mac المتأثرة.

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

لم تنشر Apple أي وثيقة دعم بشأن هذا، ولم تعترف به، ولم تُصدر إصلاحًا موثّقًا له. إذا واجهتموه، فإرسال ملاحظات (feedback) إلى Apple يستحق الدقائق الخمس — فالمشكلة التي لا يُعترف بها تظل غير معترف بها.

استكشاف المشكلات الشائعة وإصلاحها

sudo du يستغرق وقتًا طويلًا للغاية

هذا طبيعي على شجرة مجلدات كبيرة أو مجزّأة بشدة. استخدموا -d 1 أولًا لمعرفة أي مجلد من المستوى الأعلى كبير الحجم، ثم انزلوا فقط إلى ذلك المجلد. تجنبوا تشغيل du عبر القرص بأكمله حين تعرفون بالفعل المجلد الذي يهمّكم.

حذفتُ السجلات لكن المساحة الحرة لم تتغيّر

مشكلة سلة المهملات. تحققوا بالأمر sudo du -sh /private/var/root/.Trash وأفرغوها بالأمر sudo rm -rf /private/var/root/.Trash/*. يقع في هذا الفخ تقريبًا كل من استخدم أداة رسومية.

الاحتمال الثاني هو أن عملية ما لا تزال تحتفظ بالملفات المحذوفة مفتوحة، وفي هذه الحالة لا تتحرر المساحة حتى تُنهى تلك العملية. أعيدوا تشغيل جهاز Mac وتحققوا مجددًا.

عادت المساحة إلى الامتلاء خلال يوم واحد

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

rtcreportingd يستهلك المعالج لكن ليس لديّ عملاء مزامنة سحابية

إذن فالمحفّز شيء آخر. رتّبوا Activity Monitor حسب المعالج وانظروا ما الذي يعمل بانشغال. تحققوا من السجل الموحّد (unified log) لنشاط العفريت نفسه:

log show --predicate 'process == "rtcreportingd"' --last 1h --info | head -50

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

تقول ميزة First Aid في Disk Utility إن القرص سليم

بالطبع ستقول ذلك. هذا ليس تلفًا في نظام الملفات. تتحقق First Aid من اتساق البيانات الوصفية (metadata)؛ ومجلد مليء بملفات كبيرة وصالحة متسق تمامًا.

هل يمكنني ببساطة تعطيل rtcreportingd؟

لن نفعل ذلك. إنه عفريت نظام تابع لـ Apple على جهاز Mac مزوَّد بحماية سلامة النظام (System Integrity Protection)، وتعطيل عفاريت تشغيل النظام للالتفاف حول عرض ما غالبًا ما يُنتج مشكلة ثانية أقل وضوحًا لاحقًا. أصلحوا العملية التي تُحرّكه بدلًا من ذلك. وإذا كان العفريت يسيء التصرف دون محفّز يمكن تحديده، فتلك مشكلة في Apple تستحق الإبلاغ عنها لا الالتفاف حولها.

جهاز Mac لديّ ينفد منه المساحة وأحتاج إلى حيّز الآن

مكاسب فورية وآمنة أثناء تشخيصكم للمشكلة: أفرغوا سلة مهملاتكم الخاصة، وأفرغوا سلة مهملات root كما سبق، واحذفوا محتوى Logs الخاص بـ root، وتحققوا من sudo du -h -d 1 /private/var/root/Library/Caches. غالبًا ما يُحرر هذا مجتمعًا مساحة كافية لجعل جهاز Mac قابلًا للاستخدام مجددًا بينما تبحثون عن السبب. يتناول دليلنا لأعطال التحديث الناجمة عن نقص المساحة ما ينبغي فعله إذا كان هذا يُعطّل تحديث macOS تحديدًا.

الأسئلة الشائعة

ما هو /private/var/root؟

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

لماذا لا يستطيع Finder أو تطبيق التخزين لديّ رؤية هذه الملفات؟

لأنهما يعملان بصفتكم أنتم، وأذونات Unix الخاصة بالمجلد تستبعد مستخدمكم. هذه ليست حماية خصوصية يمكن لميزة Full Disk Access رفعها — إنها أذونات ملفات عادية. يجب إعادة تشغيل أي أداة رسومية بصلاحيات مرتفعة حتى تتمكن من تصفح ذلك المجلد.

ما هو rtcreportingd؟

عفريت نظام تابع لـ Apple موجود في /usr/libexec/rtcreportingd، يُشغّله com.apple.rtcreportingd ويعمل بصلاحيات root. لا توثّقه Apple. تشير بنيته الداخلية إلى أنه خدمة إبلاغ تتواصل مع خلفية تابعة لـ Apple عبر HTTP وتحتفظ بذاكرة مؤقتة محلية. يوجد على أجهزة Mac السليمة وليس هو نفسه مشكلة.

هل هو برمجية خبيثة؟

لا. إنه ملف ثنائي تابع لـ Apple موجود في /usr/libexec، يُشغّله عفريت إطلاق (launch daemon) داخل وحدة تخزين النظام المختومة. يمكنكم التحقق من توقيعه:

codesign -dv --verbose=2 /usr/libexec/rtcreportingd

ما مقدار المساحة الطبيعي لمجلد Logs الخاص بـ root؟

على جهاز Mac سليم، مساحة صغيرة — لا ينبغي أن يكون هذا مجلدًا يمكنكم ملاحظته أصلًا. إذا أعاد sudo du -sh /private/var/root/Library/Logs رقمًا بخانتين من الغيغابايتات، فتلك هي المشكلة. لا يوجد حد رسمي معتمد من Apple؛ الاختبار العملي هو ما إذا كان ينمو بينما جهاز Mac خامل.

هل سيُصلح تطبيق تنظيف Mac هذه المشكلة؟

شبه المؤكد أنه لن يفعل، لنفس السبب الذي جعل أداة تحليل التخزين لديكم تُغفل المشكلة: ما لم يُصعِّد تطبيق التنظيف صلاحياته ويتصفح تحديدًا المجلد الرئيسي لـ root، فلن يستطيع رؤية الملفات. وحتى لو أزالها تطبيق تنظيف ما، فلن يوقف عودتها، لأن السبب عملية عالقة في حلقة تكرار لا مجرد فوضى متراكمة.

هل يؤثر هذا فقط على أجهزة Mac أو إصدارات macOS معينة؟

لا توجد بيانات عامة كافية لتحديد ذلك. كانت الحالة الموثّقة على جهاز MacBook Air بمعالج M4. تحققنا من العفريت وسلوك الأذونات على macOS 26.5.2. لا شيء في هذه الآلية يخص شريحة معينة أو إصدار macOS معين — فقد كان لـ root مجلد رئيسي منذ وجود macOS نفسه.

هل ينبغي أن أبلغ Apple عن هذا؟

نعم، إذا واجهتموه. أرفقوا مخرجات الأمر sudo du -h -d 2 /private/var/root/، وأرقام استخدام المعالج لكل من rtcreportingd وfileproviderd، وأي عميل مزامنة أدى إيقافه إلى حل المشكلة. لم تنشر Apple شيئًا عن هذا، والتقارير المحددة هي ما يُغيّر ذلك.

الخاتمة

سبب كون هذه المشكلة محبطة إلى هذا الحد هو أن كل حدس لديكم بشأن تخزين Mac يكون خاطئًا في التعامل معها. الملفات ليست في مجلد يمكنكم إيجاده. ليست لقطات. وليست System Data بالمعنى الذي تقصده لوحة Storage. حذف التطبيقات لا يساعد، والأرقام لا تتطابق، والأداة الوحيدة التي كانت ستُظهرها لكم هي التي لم يخطر ببالكم تشغيلها بـ sudo.

بمجرد أن تعرفوا أين تنظرون، تصبح المهمة عمل عشر دقائق: قيسوا /private/var/root بالأمر du، احذفوا السجلات، أفرغوا سلة مهملات root، ثم — الجزء الذي يهم فعلًا — راقبوا Activity Monitor حتى تعثروا على العملية التي تملؤها مجددًا. في تسع من كل عشر حالات، ومع وجود fileproviderd بجانب rtcreportingd في قائمة استخدام المعالج، يكون المتسبب عميل مزامنة سحابية كان معطوبًا بصمت منذ أشهر.

أما إذا كانت أرقام تخزين جهاز Mac لديكم تختلف ببضعة غيغابايتات لا بتسعين، فاطمئنوا. هذا ببساطة سلوك APFS المعتاد، وحسابات Howard Oakley تُفسّره بالكامل.

قراءات ذات صلة: مساحة System Data ضخمة على Mac ولا تتقلّص · إدارة تخزين macOS وتحسينه · مقارنة أدوات تحليل تخزين Mac · دليل iCloud Drive الكامل · توقف تحديث macOS: نقص المساحة

المصادر: Michael Tsai، «Huge RTCReporting Logs and Dropbox»، 21 أغسطس 2026 · The Eclectic Light Company، «The arithmetic of free space»، 21 أغسطس 2026 · موضوع نقاش رقم 254838127 في Apple Support Community (RTCReporting) · Apple، دليل مساعدة Disk Utility (المساحة القابلة للتطهير) · تحقق محلي على macOS 26.5.2 (الإصدار 25F84)، 22 أغسطس 2026، باستخدام ls وplutil وstrings وdf وps.