ربط Nextcloud مع Storage Server: مساحة وحصص وروابط مشاركة

يستطيع Nextcloud كل ما لا يستطيعه Storage Server: إدارة المستخدمين، ومنح كل واحد منهم حصة خاصة به، ومشاركة المجلدات، وإنشاء روابط بكلمة مرور وتاريخ انتهاء، وتسليم الملفات إلى المتصفحات عبر HTTPS. أما ما يجعل Nextcloud مكلفاً فهو المساحة، لأنها تقع على قرص NVMe-SSD الخاص بالخادم.

واجتماع الاثنين يعطي البنية التي فرضت نفسها في الواقع العملي: خادم صغير لـ Nextcloud، والملفات على Storage Server. يعرض هذا المقال طريقَي الإعداد كليهما، ويوضح أيّهما أفضل ومتى، ويذكر المطبّات التي تظهر في كل مرة.

لماذا يتلاءم هذا الجمع إلى هذا الحد

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

طريقان، وأيّهما الأفضل

الطريق A: يخاطب Nextcloud المساحة بنفسه، عبر مشغّل SMB أو SFTP المدمج فيه. ولا حاجة إلى أي تدخّل في نظام التشغيل.

الطريق B: تربطون المساحة في نظام التشغيل كمجلد، وتنشئون في Nextcloud تخزيناً خارجياً من النوع «محلي» يشير إلى هذا المجلد.

خذوا الطريق B إن كانت لديكم صلاحيات root. فالمرور عبر نظام الملفات أسرع بشكل ملموس من مشغّل SFTP في Nextcloud، خصوصاً مع كثرة الملفات الصغيرة، وهو يتجاوز اضطرابات الشبكة بشكل أفضل. والطريق A هو الحل إذا لم تستطيعوا أو لم تريدوا تغيير شيء في نظام التشغيل.

التحضير: حساب فرعي خاص

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

تستخدم الأمثلة القيم التالية، فاستبدلوها بقيمكم الخاصة:

الطريق B: الربط في النظام والاستخدام كتخزين محلي

أولاً الربط. على Debian وUbuntu:

apt install -y cifs-utils
mkdir -p /mnt/storage
printf 'username=u123456-sub1\npassword=كلمة_المرور\n' > /etc/samba/storage.cred
chmod 600 /etc/samba/storage.cred

ثم السطر في /etc/fstab، لكي يبقى الربط بعد إعادة التشغيل:

//u123456.storage.kernelhost.net/backup /mnt/storage cifs credentials=/etc/samba/storage.cred,uid=www-data,gid=www-data,file_mode=0660,dir_mode=0770,seal,_netdev,nofail 0 0

والخيارات الثلاثة المهمة: uid=www-data يجعل خادم الويب قادراً على الكتابة، وseal يشفّر النقل باستخدام ⁦SMB 3⁩، و_netdev مع nofail يمنعان تعليق الخادم عند الإقلاع إذا لم تستجب المساحة في تلك اللحظة.

mount -a
sudo -u www-data touch /mnt/storage/test && echo "الكتابة تعمل"

بعد ذلك فعّلوا في Nextcloud تطبيق «External storage support» وأدخلوا المساحة، إما في الواجهة ضمن الإدارة، التخزين الخارجي، أو من سطر الأوامر:

sudo -u www-data php occ app:enable files_external
sudo -u www-data php occ files_external:create البيانات local null::null -c datadir=/mnt/storage
sudo -u www-data php occ files_external:list

يظهر المجلد «البيانات» الآن عند المستخدمين الذين تمنحونهم إياه. وتتحكمون في المنح لكل مستخدم أو لكل مجموعة، فلا يرى كل واحد كل شيء.

الطريق A: تخزين خارجي داخل Nextcloud مباشرة

الأمر ممكن أيضاً دون صلاحيات root ودون ربط في النظام. ويحتاج SMB إلى امتداد PHP المناسب:

apt install -y smbclient php-smbclient
systemctl restart php8.3-fpm

ثم أنشئوا سطراً ضمن الإدارة، التخزين الخارجي:

أما مع SFTP فتختارون النوع «SFTP» بدلاً من ذلك، وتدخلون كمضيف u123456.storage.kernelhost.net وكمنفذ 23. وهذا أكثر مصادر الخطأ في هذا الطريق: يقترح Nextcloud المنفذ 22، أما مساحتنا فتسمع على 23.

منح حصة لكل مستخدم

الآن يأتي الجزء الذي يبرّر هذه البنية كلها. ضمن الإدارة، المستخدمون تدخلون حصة لكل حساب، ⁦50 GB⁩ مثلاً. أو من سطر الأوامر:

sudo -u www-data php occ user:setting photographer1 files quota "50 GB"

ويحسب Nextcloud الإصدارات وسلة المحذوفات ضمن هذا الرقم. وهذا هو الصحيح، لكنه يفاجئ كثيراً: فمن يحصل على ⁦50 GB⁩ ويرفع ⁦50 GB⁩ يجد نفسه قد شغل أكثر مما توقّع بسبب الإصدارات القديمة. وللحسابات التي تستبدل كثيراً بدلاً من أن تضيف، يستحق الأمر تقييد مدة الاحتفاظ بالإصدارات.

روابط مشاركة لموقعكم الخاص

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

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

أربعة مطبّات تظهر في كل مرة

• مجلد البيانات لا ينتمي إلى المساحة. ممكن تقنياً، لكنه حسّاس عملياً: فـ Nextcloud يضع هناك أيضاً ملفات الإقفال والحالات الوسيطة، وانقطاع قصير في الشبكة يُعطّل المنصة بكاملها. أما كتخزين خارجي فلا يصيب الخلل إلا ذلك المجلد وحده.
• قاعدة البيانات تبقى محلية. دائماً. فإلى المساحة تنتمي الملفات، لا شيء غيرها.
• أعدّوا Redis. فبدون ذاكرة مؤقتة لأقفال الملفات يصبح Nextcloud مع تخزين خارجي بطيئاً بشكل ملموس، لأن كل قفل يمر عبر قاعدة البيانات.
• المنفذ 23 لا 22. يقترح Nextcloud المنفذ 22 عند SFTP. أما مساحتنا فتسمع على 23، ورسالة الخطأ في هذه الحالة قليلة الفائدة.

أي خادم وأي تعرفة

يكفي لـ Nextcloud نفسه جهاز صغير. فالملفات تقع في مكان آخر، والخادم يدير فقط: من حفنة مستخدمين نشطين إلى بضع عشرات تكفي ذاكرة من ⁦4 GB⁩ إلى ⁦8 GB⁩، بشرط أن يعمل Redis وأن يكون التشغيل الدوري في الخلفية معدّاً. ويوجد دليل لذلك في تثبيت Nextcloud على خادمكم الخاص.

أما في المساحة فيتبع الاختيار حجم ما تحتاجونه:

وتقع جميع خوادم Storage Server في ألمانيا، وتتحدث SMB وSFTP وWebDAV وأكثر، وتسمح بما يصل إلى 100 حساب فرعي، وتأتي مع اللقطات. دون رسوم إعداد، بنظام PrePaid ودون حد أدنى لمدة الالتزام. وإذا نمت حاجتكم إلى المساحة، انتقلتم إلى التعرفة الأكبر دون أن تلمسوا البيانات.