لماذا تستضيف مكتبتك الصوتية بنفسك؟
تفرض منصات الأوديوبوك كتالوجاتها وحماية DRM ورسومها الشهرية. مع Audiobookshelf تستورد ملفاتك M4B أو MP3 أو FLAC الخاصة — سواء اشتريتها أو استعرتها أو أنتجتها — وتصل إليها من أي جهاز عبر تطبيقات مفتوحة المصدر. مكتبتك تنمو بإيقاعك، لا بإيقاعهم.
ما يقدمه Audiobookshelf على VPS من ServOrbit
- البث والمزامنة — استأنف الأوديوبوك من حيث توقفت على الويب أو الموبايل دون حساب سحابي.
- تطبيقات iOS وAndroid مفتوحة المصدر — العملاء الرسميون تحت رخصة GPL-3.0 قابلون للتدقيق ويديرهم المجتمع.
- نسخ احتياطية مجدولة مدمجة — يستطيع الخادم إنتاج أرشيف لقاعدة بياناته وبياناته الوصفية، مع مدة احتفاظ قابلة للضبط.
- البودكاست المتكامل — اشترك في خلاصات RSS وتُنزَّل الحلقات تلقائياً وتُشغَّل في نفس الواجهة.
- حسابات متعددة — لكل فرد من العائلة حسابه وتاريخه ولوائح تشغيله.
- بيانات وصفية تلقائية — يمكن جلب الأغلفة والفصول والأوصاف من مزودين مثل Audnexus دون إدخال يدوي.
صيغ الصوت المدعومة
يشغّل Audiobookshelf الصيغ الشائعة، ومنها MP3 وM4A وM4B (مع الفصول) وAAC وOGG وFLAC وWAV وOPUS. علامات فصول M4B معروضة في المشغّل بعناوينها ومُددها. ملفات Audible المحمية بـDRM لا تُشغَّل كما هي: لا تستورد إلا ملفات يحق لك استخدامها، بصيغة مفتوحة.
المتطلبات والتحجيم
الخادم نفسه متواضع: يكفي VPS بنظام Ubuntu 24.04 مع Docker لعائلة كاملة. الذي يثقل هو القرص، لأن المكتبة (خصوصاً حلقات البودكاست التي تُنزَّل مع الوقت) تكبر باستمرار، أما المعالج فلا يُستهلك إلا حين يطلب العميل تحويلاً عبر ffmpeg بدل التشغيل المباشر. حجّم حجم البيانات على مجموعتك، واترك هامشاً للبيانات الوصفية والأغلفة والنسخ الاحتياطية، فهي تُحفظ افتراضياً في الحجم نفسه /metadata.
يجب أن تبقى قاعدة SQLite على القرص المحلي للـVPS. وثائق Audiobookshelf صريحة: لا يجوز ربط المجلد /config بمشاركة شبكية، وإلا ظهر البطء ثم التلف. أما ملفات الصوت فيمكن أن تكون في مكان آخر.
نشر Audiobookshelf باستخدام Docker Compose
تجهيز الـVPS وDocker
اتصل عبر SSH وحدّث النظام ثم ثبّت Docker وإضافة Compose. تحقق بالأمر
docker compose version. على VPS من ServOrbit يقوم قالب Audiobookshelf بهذه الخطوات عنك: يفيدك هذا الدليل في فهم ما يعمل واستلام زمامه.إنشاء المجلدات وضبط المالك
أنشئ مجلداً لكل حجم:
mkdir -p /opt/audiobookshelf/{config,metadata,audiobooks,podcasts}. اختر المستخدم الذي سيعمل به الحاوية (مثلاً 1000:1000) ثم سلّمه المجلدات:chown -R 1000:1000 /opt/audiobookshelf. يجب أن تكون المجلدات الأربعة نقاط ربط منفصلة، لا يحتوي أحدها الآخر.كتابة ملف docker-compose.yml
عرّف خدمة
audiobookshelfبالصورةghcr.io/advplyr/audiobookshelf(ثبّت وسم الإصدار الذي تحققت منه بدلlatest) معrestart: unless-stoppedوالتوجيهuser: "1000:1000"والمنفذ127.0.0.1:13378:80وأربعة روابط:/opt/audiobookshelf/config:/configو/opt/audiobookshelf/metadata:/metadataو/opt/audiobookshelf/audiobooks:/audiobooksو/opt/audiobookshelf/podcasts:/podcasts. أضفTZ=Africa/Casablanca(أو منطقتك الزمنية) كمتغير بيئة. لا يستخدم Audiobookshelf المتغيرين PUID وPGID: التوجيهuser:هو الذي يحدد المستخدم.التشغيل والتحقق
نفّذ
docker compose up -dثمdocker compose logs -f audiobookshelf. عند أول تشغيل يطبّق الخادم ترحيلات قاعدة البيانات: انتظر السطر الذي يعلن الاستماع على المنفذ 80 داخل الحاوية. إذا أظهرdocker compose psأن الخدمة تعيد التشغيل باستمرار فانتقل مباشرة إلى قسم استكشاف الأخطاء أدناه.إنشاء حساب المدير والمكتبة
افتح الواجهة (عبر نفق SSH أو نطاقك) وأنشئ حساب root، ثم أضف مكتبة تشير إلى
/audiobooksوأخرى إلى/podcasts. شغّل المسح: تظهر الكتب بأغلفتها وفصولها.ربط التطبيق المحمول
في تطبيق iOS أو Android أدخل عنوان HTTPS لنسختك واسم المستخدم وكلمة المرور. تتزامن بعدها التقدمات بين الهاتف والويب. للاستخدام الدائم ضع وكيلاً عكسياً بـHTTPS أمام الحاوية باتباع صفحة «Reverse Proxy» في وثائق Audiobookshelf (خصوصاً تمرير WebSocket).
الإعداد بدون نطاق
لا يحتاج Audiobookshelf إلى نطاق ليعمل. مع قالب ServOrbit تستمع الحاوية على الواجهة المحلية للـVPS فقط، على المنفذ 13780. افتح نفق SSH من جهازك: ssh -L 13378:127.0.0.1:13780 root@<ip-vps> ثم تصفّح http://localhost:13378. للوصول الدائم من التطبيق المحمول، اربط نطاقاً من لوحة ServOrbit — يمرّر nginx الحاوية عبر HTTPS — أو استخدم النطاق الفرعي المجاني {app}.{dns_slug}.servorbit-dns.com المُدرج مع كل VPS.
صلاحيات الأحجام والمستخدم غير الجذري
أربعة أحجام وأربعة أدوار. يحتوي /config على قاعدة SQLite وسكربتات الترحيل. ويحتوي /metadata على البيانات الوصفية والأغلفة وصور المؤلفين والسجلات والذاكرة المؤقتة، وافتراضياً النسخ الاحتياطية. أما /audiobooks و/podcasts فيمنحان الوصول إلى ملفات الوسائط. يجب أن يستطيع الخادم الكتابة في /config و/metadata؛ وفي /audiobooks لا تلزم الكتابة إلا إن أردت أن يكتب بيانات وصفية بجوار الملفات، وفي /podcasts هي ضرورية لأن الحلقات تُنزَّل فيه.
افتراضياً لا يحدد المثال الرسمي أي مستخدم. للتحصين أضف التوجيه user:: عندها لا تملك الحاوية صلاحيات الجذر على الروابط، وهنا بالضبط تظهر أخطاء الصلاحيات. القاعدة بسيطة: يجب أن يكون مالك مجلدات المضيف هو UID:GID الوارد في التوجيه user:. اختبر قبل تحميل المكتبة: docker compose exec audiobookshelf touch /config/test /metadata/test ثم احذف الملفين.
على نظام ملفات بقوائم ACL (مثل ZFS مع ACL من نوع NFSv4) لا يكفي chown دائماً: الحادثة الموصوفة أدناه توضح ذلك، بحاوية تعمل بالمستخدم 568 مع سحب كل القدرات على مجموعة بيانات ZFS.
حجم مسمّى أم مجلد على المضيف لـ /config و/metadata
مرّر الجدول أفقيًا
| المعيار | حجم Docker مسمّى | مجلد على المضيف |
|---|---|---|
| المالك الأولي | يديره Docker وغالباً root | تضبطه بنفسك عبر chown |
| التوافق مع `user:` | يُتحقق منه قبل أول استيراد | مباشر إذا تطابق UID:GID |
| النسخ البارد | استخدم `docker volume inspect` لمعرفة المسار | `rsync` مباشر للمجلد |
| وضوح المسار | أقل وضوحاً | مسار ثابت ومعروف |
| النقل إلى VPS آخر | يلزم تخطيط لتصدير الحجم | نسخ المجلد |
| الاستخدام الموصى به | تجربة سريعة وقالب جاهز | الإنتاج بمستخدم غير جذري |
نسخ احتياطية متسقة: ما تغطيه النسخة المدمجة
يستطيع Audiobookshelf إنشاء نسخه الاحتياطية من الواجهة (الجدولة وعدد النسخ المحفوظة والحجم الأقصى). يحتوي كل أرشيف على قاعدة البيانات وصور الأغلفة من مجلد البيانات الوصفية؛ أما ملفات الوسائط المخزنة مع عناصر المكتبة فليست فيه. افتراضياً تُكتب الأرشيفات في /metadata/backups، أي على القرص نفسه الذي توجد عليه البيانات: عطل الـVPS يأخذ الاثنين معاً. انسخها بانتظام خارج الخادم.
النسخة لا تحمي إلا إذا كانت متسقة. القاعدة ملف SQLite حيّ: نسخ /config بـcp أو rsync بينما يكتب الخادم (تقدم الاستماع، المسح) قد ينتج ملفاً غير متسق. طريقتان آمنتان: استعمال النسخة المدمجة في الخادم ثم نسخ الأرشيف الناتج؛ أو إيقاف الحاوية طوال مدة النسخ. ملفات الصوت تُنسخ على حدة بـrsync أو بأداة نسخ احتياطي تزيل التكرار.
تتم الاستعادة على نوع النظام نفسه: تحذر الوثائق من أن نسخة Linux تُستعاد على Linux، وأن الانتقال من طريقة تثبيت إلى أخرى قد يُضيّع التقدم والبيانات الوصفية.
النسخ البارد والاستعادة اليدوية
إيقاف الحاوية
من مجلد ملف compose نفّذ
docker compose stop audiobookshelf. لم تعد هناك كتابات جارية على القاعدة.نسخ الإعدادات والبيانات الوصفية
انسخ
/opt/audiobookshelf/configو/opt/audiobookshelf/metadataإلى مكان خارج الـVPS بالأمرrsync -aمع حفظ الصلاحيات. أضف مجلدات الصوت وفق استراتيجيتك لنسخ الوسائط.إعادة التشغيل والتحقق
نفّذ
docker compose start audiobookshelfوتحقق من السجلات أن الخادم يستمع من جديد. يدوم الانقطاع بقدر مدة نسخ القاعدة.الاستعادة من أرشيف الخادم
أوقف الحاوية، وفُكّ ضغط أحدث أرشيف في
metadata/backups، وانسخaudiobookshelf.sqliteإلى مجلد الإعدادات بدل الملف الموجود، ثم انسخ المجلدينmetadata-authorsوmetadata-itemsإلىauthorsوitems. إن كان الأرشيف غير صالح فجرّب الذي قبله. توفر صفحة النسخ الاحتياطية في الواجهة أيضاً زر استعادة.اختبار استعادة تجريبية
مرة كل ثلاثة أشهر استعد نسخة على VPS تجريبي وتحقق من وجود المستخدمين والتقدم والمكتبات. النسخة التي لم تُستعد قط تبقى مجرد فرضية.
التحديثات والإصدارات: ثبّت الوسم بدل متابعة latest
يسحب قالب ServOrbit الصورة latest. هذا مريح لكنه يعرّضك لانحدارات بين إصدار وآخر. التحديث الموثّق بسيط: docker compose pull ثم docker compose down ثم docker compose up --detach. قبل كل تحديث خذ نسخة احتياطية (مدمجة أو باردة) واقرأ ملاحظات الإصدار في صفحة الإصدارات بمستودع GitHub.
حالة حديثة تبرّر ذلك. نقل الإصدار 2.37.0 الخادم إلى Node.js 24، وأصابت الإصدار 2.37.1 حلقة إعادة تشغيل في بعض التثبيتات (انظر أدناه). التصحيح منشور في 2.37.2، وهو وقت الكتابة آخر إصدار مستقر يعرضه المشروع. وسم مثبّت ونسخة احتياطية سابقة يتيحان لك الرجوع دون ارتجال.
استكشاف الأخطاء: حلقة إعادة تشغيل عند البدء (EPERM … copyfile)
العَرَض: تعيد الحاوية التشغيل في حلقة بعد الترقية إلى 2.37.1، وتظهر في السجلات الرسالة «Failed to copy migrations to the config directory» ثم «EPERM: operation not permitted, copyfile» من المجلد /app/dist-server/server/migrations/ إلى /config/migrations/ ثم «Database migration failed».
الحالة الفعلية للحادثة (المسألة رقم 5637 في مستودع advplyr/audiobookshelf، فُتحت في أكتوبر 2026): هي مغلقة. كان صاحب البلاغ يستخدم TrueNAS SCALE وحاوية بالمستخدم 568 مع سحب كل القدرات وno-new-privileges، و/config على مجموعة بيانات ZFS مربوطة ربط bind. أبلغ عدة مستخدمين لـTrueNAS عن الأمر نفسه. لا يوجد سبب جذري مثبت رسمياً في النقاش؛ أظهر اختبار أن copyFileSync يفشل بـEPERM على هذا الربط بينما تنجح كتابة ملف مباشرة بالمستخدم نفسه، ويُشتبه في انحدار في مسار النسخ مرتبط بـNode.js 24. يضيف التصحيح (طلب الدمج رقم 5668) مساراً بديلاً عند فشل النسخ؛ وهو منشور في 2.37.2.
العلاج: رقِّ إلى 2.37.2 أو أحدث. إن تعذّر التحديث فوراً فالحل المؤقت المذكور في المسألة هو الرجوع إلى 2.36.1 مع نسخة احتياطية أُخذت قبل التحديث. وإذا استمرت الرسالة نفسها بعد التحديث فتحقق من مالك مجلد الإعدادات وقوائم ACL لمجموعة البيانات: لم يعد ذلك الخطأ نفسه.
استكشاف الأخطاء: النسخة الليلية تُسقط الحاوية (SQLITE_BUSY)
العَرَض: يتوقف الخادم في وقت النسخة المجدولة مع «FATAL: [Server] Uncaught exception» والخطأ SQLITE_BUSY: database is locked. مع restart: unless-stopped يعيد Docker تشغيل الحاوية: لا ترى إلا انقطاعاً قصيراً يكشفه عدّاد إعادة تشغيل غير صفري (docker inspect --format '{{.RestartCount}}' <container>؛ استبدل الاسم باسم حاويتك).
الحالة الفعلية (المسألة رقم 4572، فُتحت في أغسطس 2025): ما زالت مفتوحة. يشرح أحد المساهمين السبب: تُصدر النسخة الاحتياطية في SQLite خطأ «القاعدة مشغولة» كحدث بلا مستمع، فتعامله Node.js كاستثناء غير ملتقَط، ولا تُجرى أي محاولة إعادة. يقع الانهيار حين تُبقي كتابة أخرى، مثل حفظ عميل لتقدم الاستماع، القفل أكثر من ثانية أثناء النسخ. طلب الدمج رقم 5660 (نسخ على دفعات يعيد المحاولة عند القفل، وأخطاء الجلسات تُسجَّل بدل أن تُسقط الخادم) مفتوح وغير مدمج حتى اليوم: لا يتضمنه أي إصدار منشور. وأُغلق طلب دمج منافس سابق لصالح هذا الطلب.
في الأثناء ثلاثة حلول مؤقتة ذُكرت في المسألة: إبعاد النسخة عن ساعات الاستماع (الفجر أفضل من المساء)؛ إبقاء restart: unless-stopped لتعود الحاوية وحدها؛ أو استبدال النسخة المدمجة بنسخ بارد مجدول على المضيف يوقف الحاوية لحظات. تذكير من الوثائق: يجب أن تكون القاعدة على قرص محلي، لا على مشاركة شبكية أبداً.
أخطاء شائعة أخرى
- Permission denied في السجلات — مالك مجلدات المضيف لا يطابق UID:GID في التوجيه
user:. صحّح بـchown -Rثم أعد التشغيل. - مكتبة فارغة بعد المسح — مسار المكتبة ليس مسار الحاوية. أضف
/audiobooksأو/podcastsلا مساراً من المضيف. - «Cannot find module '/index.js'» — تشير الوثائق إلى ذاكرة صور قديمة عند بعض مديري الحاويات: أعد إنشاء الحاوية أو الحزمة بعد
docker compose pull. - التطبيق المحمول لا يتصل — تحقق من عنوان HTTPS والشهادة وتمرير WebSocket عبر الوكيل العكسي؛ نفق SSH لا يخدم إلا المتصفح.
- حاوية «unhealthy» — يستعلم فحص الصحة المنفذ 80 داخل الحاوية: راجع
docker compose logsلمعرفة هل يفشل ترحيل عند البدء.
تحصين أدنى
ثبّت وسم الصورة، شغّل الحاوية بالتوجيه user:، انشر المنفذ على 127.0.0.1 فقط خلف وكيل عكسي بـHTTPS، انسخ أرشيفات /metadata/backups خارج الـVPS كل أسبوع وجرّب استعادة. هذا الدليل مقدَّم كما هو: لا يوفّر ServOrbit دعماً للتطبيق نفسه.
للمتابعة
حين يستقر الخادم أضف طبقة حماية ثانية: نسخة احتياطية مشفّرة لمجلدات الإعدادات إلى تخزين بعيد، وتنبيهاً إذا أُعيد تشغيل الحاوية أكثر من مرة يومياً. تابع المسائل المذكورة هنا: سيلزم التحقق من انهيار النسخ الاحتياطي من جديد فور دمج طلب الدمج رقم 5660 ونشره.