TrueNAS عملياً: من التثبيت إلى أول مشاركة محمية

في مقال أنظمة NAS قارنا TrueNAS بالبدائل، ولخصنا خطوات تثبيته من التوثيق دون أن نشغله، وفي ZFS للمبتدئين شرحنا ال Pool وال vdev وال Snapshots وال Scrub بسطر الأوامر. وفي هذا المقال سوف نقوم بتشغيل TrueNAS Community Edition فعلاً في جهاز افتراضي، ونبني عليه ما يحتاجه بيت أو مكتب صغير من البداية: Pool، ومشاركة Windows بصلاحيات مختلفة لكل شخص، ومشاركة NFS لأجهزة Linux، وSnapshots يستعيد منها المستخدم ملفه بنفسه، وتنبيهات، ثم نسخة على قرص آخر ونسخة مشفرة خارج الجهاز. وكل صورة في المقال من تثبيتنا نحن، وكل مخرج من الجهاز نفسه.

وسوف نناقش في هذا المقال ما يلي:

• أي إصدار تثبت اليوم، وتثبيته في جهاز افتراضي.
• إنشاء ال Pool وال Datasets والمستخدمين والمجموعات.
• مشاركة SMB بصلاحيات ACL، وتصدير NFS، واختبارهما من كلاينت حقيقي.
• Snapshots دورية واستعادة ملف محذوف عبر Previous Versions.
• ال Scrub وفحوص SMART بعد أن أزال الإصدار 25.10 واجهتها، والتنبيهات والبريد.
• النسخ المتماثل Replication إلى Pool آخر، ونسخة مشفرة خارج الجهاز بـ Cloud Sync.
• التطبيقات باختصار، والتحديثات وبيئات الإقلاع Boot Environments، والأخطاء الشائعة.

والصورة التالية تبين ما سوف نبنيه:

أي إصدار تثبت؟

صفحة حالة البرامج هي المرجع الذي تعود إليه قبل أي تثبيت، وهي توصي المستخدم العادي General في 9 أكتوبر 2026 بالإصدار 25.10.7 (Goldeye) الصادر في 2 سبتمبر 2026، أما 27.0.0-RC.1 الصادر في 6 أكتوبر 2026 فهو لمن يريد التجربة المبكرة Early Adopter، والصفحة نفسها تقول إن TrueNAS CORE لم يعد تحت التطوير النشط. لذلك ثبتنا 25.10.7، وملف ISO منشور مع ملف sha256 على سيرفر التنزيل، ولاحظ أن اسم الملف ما زال يحمل كلمة SCALE مع أن الاسم التجاري اليوم Community Edition.

بيئة التجربة: TrueNAS في جهاز افتراضي

شغلنا TrueNAS بـ QEMU مع KVM داخل Container بصلاحيات كاملة، بذاكرة 8 جيجابايت، وهي الحد الأدنى في دليل العتاد، وقرص إقلاع بحجم 20 جيجابايت، وأربعة أقراص بيانات بحجم 8 جيجابايت لكل منها، وكل قرص له رقم تسلسلي Serial خاص به لأن TrueNAS يعرف الأقراص به. وإذا كان عندك Proxmox فأنشئ جهازاً افتراضياً بالمواصفات نفسها كما في دليل أول VM في Proxmox، والخطوات بعد ذلك واحدة. والأوامر التالية هي ما قمنا به:

mkdir -p vm && cd vm
curl -L -O https://download.truenas.com/TrueNAS-SCALE-Goldeye/25.10.7/TrueNAS-SCALE-25.10.7.iso
curl -L -O https://download.truenas.com/TrueNAS-SCALE-Goldeye/25.10.7/TrueNAS-SCALE-25.10.7.iso.sha256
cat TrueNAS-SCALE-25.10.7.iso.sha256; echo; sha256sum TrueNAS-SCALE-25.10.7.iso
docker run -d --name lab-truenas-qemu --privileged -p 127.0.0.1:28443:8443 -p 127.0.0.1:28080:8080 -v "$PWD:/vm" debian:13 sleep infinity
docker exec lab-truenas-qemu sh -c 'apt-get update -qq && apt-get install -y -qq qemu-system-x86 qemu-utils socat netpbm smbclient nfs-common openssh-client jq >/dev/null 2>&1'

والمخرج سوف يكون كما يلي:

54ce9441ce66966a392e28f63604ca3c2c083d0bec4db7bb5af2f74f7a007c8e
54ce9441ce66966a392e28f63604ca3c2c083d0bec4db7bb5af2f74f7a007c8e *TrueNAS-SCALE-25.10.7.iso

ال Hash مطابق، ثم ننشئ الأقراص ونشغل الجهاز من ملف ISO:

docker exec -i lab-truenas-qemu bash <<'EOF'
mkdir -p /work && cd /vm
qemu-img create -q -f qcow2 lab-truenas-boot.qcow2 20G
for i in 1 2 3 4; do qemu-img create -q -f qcow2 lab-truenas-data$i.qcow2 8G; done
nohup qemu-system-x86_64 -enable-kvm -cpu host -smp 4 -m 8192 -machine q35 \
  -display none -vga std -monitor unix:/work/mon.sock,server,nowait -serial file:/work/serial.log \
  -device virtio-scsi-pci,id=scsi0 \
  -drive file=/vm/lab-truenas-boot.qcow2,if=none,id=boot,format=qcow2 -device scsi-hd,drive=boot,bus=scsi0.0,serial=LABBOOT0001 \
  -drive file=/vm/lab-truenas-data1.qcow2,if=none,id=d1,format=qcow2 -device scsi-hd,drive=d1,bus=scsi0.0,serial=LABDATA0001 \
  -drive file=/vm/lab-truenas-data2.qcow2,if=none,id=d2,format=qcow2 -device scsi-hd,drive=d2,bus=scsi0.0,serial=LABDATA0002 \
  -drive file=/vm/lab-truenas-data3.qcow2,if=none,id=d3,format=qcow2 -device scsi-hd,drive=d3,bus=scsi0.0,serial=LABDATA0003 \
  -drive file=/vm/lab-truenas-data4.qcow2,if=none,id=d4,format=qcow2 -device scsi-hd,drive=d4,bus=scsi0.0,serial=LABDATA0004 \
  -cdrom /vm/TrueNAS-SCALE-25.10.7.iso -boot order=d \
  -netdev user,id=n0,hostfwd=tcp::8443-:443,hostfwd=tcp::8080-:80,hostfwd=tcp:127.0.0.1:2222-:22,hostfwd=tcp:127.0.0.1:4450-:445 \
  -device virtio-net-pci,netdev=n0 > /work/qemu.log 2>&1 &
EOF

في الإعداد أعلاه لاحظ التالي:

• واجهة TrueNAS (المنفذ 443 في الجهاز الافتراضي) تصل إلى جهازنا على https://127.0.0.1:28443 فقط، فلا يراها أي جهاز آخر في الشبكة، ومنافذ SMB وssh مربوطة على 127.0.0.1 داخل ال Container، لأننا نختبرها من ال Container نفسه. وبعد التثبيت أعدنا تشغيل الجهاز بالأمر نفسه دون -cdrom ومع -boot order=c، وأضفنا المنفذ 2049 لـ NFS بالطريقة نفسها.
• الجهاز بلا شاشة، وصور المثبت في القسم التالي أخذناها بالأمر screendump من شاشة مراقبة QEMU، وأرسلنا المفاتيح بالأمر sendkey، وإذا كنت على Proxmox فسوف تراها في Console مباشرة.

التثبيت

المثبت نصي، وأول شاشة فيه تعرض Install/Upgrade وShell وReboot، وبعدها شاشة اختيار قرص الإقلاع. وهنا أهم قرار في التثبيت كله، فالقرص الذي تختاره لا يستخدم بعد ذلك في أي Pool للبيانات، لذلك اختر القرص الصغير المخصص للنظام، وهو في جهازنا قرص 20 جيجابايت:

بعدها يحذرك المثبت من أنه سوف يمسح القرص، ولاحظ الملاحظة تحت التحذير، فالمثبت نفسه يقول إن التثبيت على SATA أو SAS أو NVMe هو الموصى به وإن ذاكرة USB غير مستحبة، وهذا ما يقوله دليل العتاد أيضاً لأن الإصدارات الحديثة تكتب على قرص الإقلاع أكثر من القديمة، وجودة ذاكرات USB متفاوتة:

ثم يسألك عن طريقة الدخول إلى الواجهة، فاخترنا المستخدم الإداري truenas_admin وكتبنا له كلمة مرور، والمثبت يذكر أن الدخول بكلمة مرور root سوف يكون معطلاً. والسؤال الأخير عن الإقلاع بـ EFI، وجهازنا الافتراضي يعمل بـ BIOS القديم، فأجبنا No، أما الجهاز الحديث فيجيب Yes. واستغرق التثبيت عدة دقائق على قرص افتراضي بطيء، ثم أزلنا ملف ISO وأعدنا التشغيل من القرص.

أول دخول

بعد الإقلاع دخلنا إلى الواجهة من https://127.0.0.1:28443 بالمستخدم truenas_admin، والشهادة ذاتية التوقيع، فسوف يحذرك المتصفح في المرة الأولى. ولوحة التحكم تعرض الإصدار ومعلومات الجهاز والذاكرة:

ومن ال Shell داخل الجهاز يمكنك أن ترى ما تحت الواجهة، فالنواة 6.12.105-production+truenas وOpenZFS بالإصدار 2.3.9، وهذا ما ظهر عندنا بالأمرين uname -r وzfs version. وقبل أي شيء آخر تذكر أن هذه الواجهة تتحكم بكل بياناتك، فلا تفتحها على الإنترنت بتوجيه منفذ من الراوتر، وادخل إليها من الخارج عبر VPN كما شرحنا في قسم الأمان في مقال بناء NAS.

إنشاء ال Pool

من Storage ثم Create Pool يفتح معالج Pool Creation Wizard، وفيه اسم ال Pool ثم خطوة Data، ثم خطوات اختيارية Log وSpare وCache وMetadata وDedup، وهي نفسها SLOG وL2ARC وspecial vdev التي شرحنا في مقال ZFS متى تفيد ومتى لا تفيد، فاتركها فارغة إلا إذا كان عندك سبب واضح. وفي خطوة Data اخترنا Layout بقيمة RAIDZ1 وعرض Width بثلاثة أقراص وvdev واحد:

واخترنا RAIDZ1 لأن أقراص التجربة صغيرة، أما مع أقراص حقيقية بعدة تيرابايت فالأنسب RAIDZ2، والسبب حساب إعادة البناء الذي شرحناه في مقال NAS وSAN. وبعد التأكيد بأن الأقراص سوف تمسح ظهر ال Pool في لوحة التخزين:

ومن ال Shell يظهر ال Pool كما يعرفه ZFS، ولاحظ أن TrueNAS يستخدم معرفات الأقسام وليس أسماء الأقراص مثل sda، والسبب أن هذه الأسماء قد تتغير بين إقلاع وآخر كما سوف نرى في قسم SMART:

sudo zpool status tank

والمخرج سوف يكون كما يلي:

  pool: tank
 state: ONLINE
config:

	NAME                                      STATE     READ WRITE CKSUM
	tank                                      ONLINE       0     0     0
	  raidz1-0                                ONLINE       0     0     0
	    c6e382f7-643a-49cf-8dfb-da2333d2f72c  ONLINE       0     0     0
	    94f61543-65de-4f3d-b1a3-d4c01f491ac0  ONLINE       0     0     0
	    dd5e13d2-e1f5-46d4-967f-817c3fcb5fe1  ONLINE       0     0     0

errors: No known data errors

Dataset لكل مشاركة

من Datasets ثم Add Dataset أنشأنا Dataset باسم family، واخترنا Dataset Preset بقيمة SMB، وهذا الإعداد يضبط الصلاحيات وحساسية الأحرف لمشاركة Windows، ويعرض عليك إنشاء المشاركة في الخطوة نفسها:

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

sudo zfs get -o property,value,source compression,recordsize,atime,acltype,aclmode,xattr,casesensitivity tank/family

والمخرج سوف يكون كما يلي:

PROPERTY         VALUE           SOURCE
compression      lz4             inherited from tank
recordsize       128K            default
atime            off             inherited from tank
acltype          nfsv4           local
aclmode          restricted      local
xattr            on              local
casesensitivity  insensitive     -

في المخرج أعلاه لاحظ التالي:

• الضغط lz4 وatime متوقف، وكلاهما موروث من ال Pool، فـ TrueNAS يضبطهما على tank عند إنشائه.
• acltype=nfsv4 يعني صلاحيات NFSv4 التي تشبه صلاحيات Windows، وcasesensitivity=insensitive لأن Windows لا يفرق بين حروف الأسماء الكبيرة والصغيرة، وهذه الخاصية لا تتغير بعد إنشاء ال Dataset، لذلك اختر ال Preset الصحيح من البداية.

وأنشأنا Dataset ثانياً باسم linux بالإعداد Generic لمشاركة NFS، كما سوف نرى بعد قليل.

المستخدمون والمجموعات

الصلاحيات في المشاركة تكون للمستخدمين والمجموعات المحلية في TrueNAS، فأنشأنا مجموعة باسم family، ثم من Credentials ثم Users ثم Add أنشأنا المستخدم alice، وأبقينا SMB Access مفعلاً، وأضفنا family إلى Auxiliary Groups:

لاحظ أن الواجهة في 25.10 تفصل نوع الوصول: SMB Access وTrueNAS Access للواجهة وShell Access وSSH Access، فلا تعط مستخدم المشاركة إلا SMB Access، والسبب أن كل صلاحية زائدة طريق آخر للمخترق إذا سرقت كلمة مروره. والمجموعة والمستخدم الثاني bob يمكنك إنشاؤهما من الواجهة بالطريقة نفسها، ونحن أنشأناهما من ال Shell بالأمر midclt الذي يستدعي واجهة TrueNAS البرمجية نفسها التي تستدعيها الواجهة، ولاحظ أن bob ليس في المجموعة family:

sudo midclt call group.create '{"name": "family"}'
sudo midclt call user.create '{"username":"bob","full_name":"bob","password":"bob-lab-2026","group_create":true,"smb":true}' > /dev/null
id alice; id bob

والمخرج سوف يكون كما يلي:

110
uid=3000(alice) gid=3001(alice) groups=3001(alice),545(builtin_users),3000(family)
uid=3001(bob) gid=3002(bob) groups=3002(bob),545(builtin_users)

صلاحيات المشاركة ACL

من Datasets نختار tank/family ثم Edit في بطاقة Permissions فيفتح محرر ACL. وأول ما تلاحظه أن الإعداد الافتراضي فيه سطر Group - builtin_users بصلاحية Modify، وكل مستخدم له SMB Access عضو في builtin_users كما رأيت في مخرج id، وهذا يعني أن bob يستطيع تعديل كل الملفات. لذلك حذفنا هذا السطر، وأضفنا سطراً للمجموعة family بصلاحية Modify، وسطراً للمستخدم bob بصلاحية Read:

وبعد Save Access Control List يمكنك أن ترى ال ACL الحقيقي من ال Shell:

sudo nfs4xdr_getfacl /mnt/tank/family

والمخرج سوف يكون كما يلي:

# File: /mnt/tank/family
# owner: 0
# group: 0
# mode: 0o40770
# trivial_acl: false
# ACL flags: none
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWc--s:fd-----:allow
group:builtin_administrators:rwxpDdaARWcCos:fd-----:allow
      group:family:rwxpDdaARWc--s:fd-----:allow
          user:bob:r-x---a-R-c---:fd-----:allow

والحروف fd تعني أن الصلاحية تورث للملفات والمجلدات الجديدة داخل المشاركة. والآن نختبر من كلاينت SMB حقيقي، وهو smbclient داخل ال Container، فنرفع ملفاً باسم alice، ثم نحاول القراءة والكتابة باسم bob:

printf 'Family budget 2026\nRent: 4000\n' > budget.txt
smbclient //127.0.0.1/family -p 4450 -U 'alice%alice-lab-2026' -m SMB3 -c 'put budget.txt; ls' 2>&1 | grep -v -E '^\s*$|blocks of size'
smbclient //127.0.0.1/family -p 4450 -U 'bob%bob-lab-2026' -m SMB3 -c 'get budget.txt bob-copy.txt; put budget.txt bob-was-here.txt' 2>&1 | grep -v -E '^\s*$'
cat bob-copy.txt

والمخرج سوف يكون كما يلي:

putting file budget.txt as \budget.txt (1.7 kb/s) (average 1.7 kb/s)
  .                                   D        0  Fri Oct  9 21:28:06 2026
  ..                                  D        0  Fri Oct  9 21:28:06 2026
  budget.txt                          A       30  Fri Oct  9 21:28:06 2026
getting file \budget.txt of size 30 as bob-copy.txt (5.9 KiloBytes/sec) (average 5.9 KiloBytes/sec)
NT_STATUS_ACCESS_DENIED opening remote file \bob-was-here.txt
Family budget 2026
Rent: 4000

alice رفعت الملف، وbob قرأه ولكنه لم يستطع الكتابة، فرد السيرفر بـ NT_STATUS_ACCESS_DENIED، وهذا ما أردناه. وفي Windows تصل إلى المشاركة بالمسار \\عنوان-السيرفر\family من مستكشف الملفات، والبروتوكول نفسه شرحناه في قسم SMB.

تصدير NFS لأجهزة Linux

من Shares ثم UNIX (NFS) Shares ثم Add، اخترنا المسار /mnt/tank/linux، وحددنا الشبكة التي يسمح لها بالوصول، وهي في جهازنا الافتراضي 10.0.2.0/24، وفي بيتك سوف تكون شبكتك المحلية فقط:

والسبب أن NFS بالإعداد sec=sys يصدق رقم المستخدم الذي يرسله الكلاينت كما ذكرنا في قسم NFS، فأي جهاز يصل إلى المنفذ يستطيع أن يدعي أنه أي مستخدم. وهذا ما كتبه TrueNAS في ملف التصدير، ثم نربطه من ال Container ونكتب فيه مرة باسم root ومرة برقم المستخدم 3000، وهو رقم alice. وفي المحاولة الأولى طلبنا الإصدار 4.2 بالخيار vers=4.2 فرفضه الكلاينت في ال Container، فتركنا الإصدار للتفاوض:

sudo cat /etc/exports

والمخرج سوف يكون كما يلي:

"/mnt/tank/linux"\
	10.0.2.0/24(sec=sys,rw,no_subtree_check)

ثم من ال Container:

mkdir -p /mnt/linux
mount -t nfs4 -o port=2049 127.0.0.1:/mnt/tank/linux /mnt/linux && echo mounted
mount | grep /mnt/linux | sed 's/,addr=.*//'
touch /mnt/linux/from-root.txt
id -u 3000 >/dev/null 2>&1 || useradd -u 3000 -M labalice
su labalice -s /bin/sh -c 'echo "written from Linux over NFS" > /mnt/linux/from-alice.txt && ls -ln /mnt/linux'

والمخرج سوف يكون كما يلي:

mounted
127.0.0.1:/mnt/tank/linux on /mnt/linux type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none
touch: cannot touch '/mnt/linux/from-root.txt': Permission denied
total 1
-rw-rw-r-- 1 3000 3000 28 Oct  9 21:29 from-alice.txt

في المخرج أعلاه لاحظ التالي:

• root على الكلاينت لم يستطع الكتابة، والسبب أن NFS يحول root القادم من الكلاينت إلى مستخدم بلا صلاحيات Root Squash ما لم تغير ذلك في Advanced Options.
• المستخدم برقم 3000 كتب الملف لأن المجلد ملك alice، وهذا يعني أن أرقام المستخدمين UID يجب أن تتطابق بين أجهزة Linux وTrueNAS، وإلا ظهرت الملفات بمالك خاطئ.
• الربط تم بالإصدار 4.1 كما في vers=4.1، والإعداد الافتراضي في 25.10.7 يفعل NFSv3 وNFSv4 معاً كما أعطانا midclt call nfs.config.

وصفحة Shares تعرض المشاركتين وحالة الخدمتين:

Snapshots دورية واستعادة Previous Versions

من Data Protection ثم Periodic Snapshot Tasks ثم Add، اخترنا tank/family، وجدول Hourly، ومدة الاحتفاظ أسبوعين، وهي القيمة الافتراضية:

واسم ال Snapshot مهم هنا، فبحسب صفحة Shadow Copies فإن TrueNAS يعرض Snapshots ال Dataset الذي تحت المشاركة لكلاينت Windows كنسخ ظل Shadow Copies، فتظهر في تبويب Previous Versions في خصائص الملف، والصفحة نفسها تقول إن 25.10 لا يسمح بإيقافها لكل مشاركة على حدة. ولنجرب ذلك شغلنا المهمة يدوياً، ثم عدلت alice الملف فأصبح الإيجار 4500، ثم سألنا السيرفر عن النسخ السابقة للملف:

sudo midclt call pool.snapshottask.run 1
sudo zfs list -t snapshot -o name,used,refer tank/family
printf 'Family budget 2026\nRent: 4500\n' > budget.txt
smbclient //127.0.0.1/family -p 4450 -U 'alice%alice-lab-2026' -m SMB3 -c 'put budget.txt' 2>&1 | grep -v '^\s*$'
smbclient //127.0.0.1/family -p 4450 -U 'alice%alice-lab-2026' -m SMB3 -c 'allinfo budget.txt' 2>&1 | grep -v '^\s*$'

والمخرج سوف يكون كما يلي:

NAME                                USED  REFER
tank/family@auto-2026-10-09_14-31     0B   128K
putting file budget.txt as \budget.txt (4.2 kb/s) (average 4.2 kb/s)
altname: budget.txt
create_time:    Fri Oct  9 21:28:06 2026 UTC
access_time:    Fri Oct  9 21:28:06 2026 UTC
write_time:     Fri Oct  9 21:31:30 2026 UTC
change_time:    Fri Oct  9 21:31:30 2026 UTC
attributes: A (20)
stream: [::$DATA], 30 bytes
@GMT-2026.10.09-21.31.24
create_time:    Fri Oct  9 21:28:06 2026 UTC
access_time:    Fri Oct  9 21:28:06 2026 UTC
write_time:     Fri Oct  9 21:28:06 2026 UTC
change_time:    Fri Oct  9 21:28:06 2026 UTC
size: 30

السطر @GMT-2026.10.09-21.31.24 هو ال Snapshot نفسه كما يراه بروتوكول SMB، بتوقيت UTC، وهو الذي يعرضه Windows في Previous Versions. والآن نحذف الملف كأننا أخطأنا، ثم نستعيد النسخة السابقة من مسار يبدأ بـ @GMT، وهي الطريقة التي يصل بها كلاينت SMB إلى النسخ السابقة:

S='smbclient //127.0.0.1/family -p 4450 -U alice%alice-lab-2026 -m SMB3'
$S -c 'del budget.txt; ls' 2>&1 | grep -v -E '^\s*$|blocks of size'
$S -c 'get @GMT-2026.10.09-21.31.24\budget.txt old-budget.txt' 2>&1 | grep -v '^\s*$'
cat old-budget.txt
$S -c 'put old-budget.txt budget.txt; ls' 2>&1 | grep -v -E '^\s*$|blocks of size'

والمخرج سوف يكون كما يلي:

  .                                   D        0  Fri Oct  9 21:31:40 2026
  ..                                  D        0  Fri Oct  9 21:31:40 2026
getting file \@GMT-2026.10.09-21.31.24\budget.txt of size 30 as old-budget.txt (7.3 KiloBytes/sec) (average 7.3 KiloBytes/sec)
Family budget 2026
Rent: 4000
putting file old-budget.txt as \budget.txt (7.3 kb/s) (average 7.3 kb/s)
  .                                   D        0  Fri Oct  9 21:31:40 2026
  ..                                  D        0  Fri Oct  9 21:31:40 2026
  budget.txt                          A       30  Fri Oct  9 21:31:40 2026

الملف حذف من المشاركة، ولكن نسخته في ال Snapshot بقيت، فاستعدناها بالإيجار القديم 4000 دون أن ندخل إلى TrueNAS أصلاً، وهذه أهم فائدة لل Snapshots في مكتب صغير، فالموظف يستعيد ملفه بنفسه. ولم نجرب تبويب Previous Versions في Windows نفسه، لأن مشاركة التجربة على المنفذ 4450 داخل ال Container، وكلاينت Windows يتصل بالمنفذ 445 فقط، والصفحة الرسمية تذكر أن الاستعادة في Windows تكون من مستكشف الملفات. وتذكر أيضاً أن المستخدم لا يستطيع حذف ال Snapshots من SMB، وهذا جيد أمام برنامج فدية يعمل بصلاحيات المستخدم، ولكنه لا يحميك إذا وصل المخترق إلى صلاحيات المدير في TrueNAS.

ال Scrub وفحوص SMART

رأينا في لوحة التخزين أن TrueNAS جدول Scrub تلقائياً عند إنشاء ال Pool، ومن Configure تفتح الإعداد:

وبحسب صفحة إدارة ال Pools فإن Threshold Days هي عدد الأيام التي يجب أن تمر بعد آخر Scrub مكتمل قبل أن يسمح بغيره، أي أن الجدول الافتراضي يعني عملياً Scrub في أول أحد بعد مرور 35 يوماً، وهذا مناسب لأغلب البيوت، وإذا كانت البيانات مهمة جداً فقلل الرقم. ويمكنك أن تشغله يدوياً من Scrub Now، أو من ال Shell:

sudo zpool scrub -w tank
sudo zpool status tank | sed -n '1,6p'

والمخرج سوف يكون كما يلي:

  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:00:00 with 0 errors on Fri Oct  9 14:32:44 2026
config:

	NAME                                      STATE     READ WRITE CKSUM

أما SMART فهنا تغيير مهم: ملاحظات الإصدار 25.10 تقول إنه أزال واجهة جدولة فحوص SMART ومراقبتها، فلم تعد في Data Protection ولا في صفحة الأقراص، وإن TrueNAS ما زال يقرأ بيانات SMART من كل قرص كل 90 دقيقة وينبه إذا تجاوزت قيمة حد الفشل، وإن الفحوص اليدوية تجدولها بمهمة Cron أو بتطبيق مثل Scrutiny، كما في صفحة صحة الأقراص. فإذا قرأت دليلاً قديماً يشرح SMART Tests من الواجهة فهو لا ينطبق على 25.10. لذلك أنشأنا من System ثم Advanced Settings ثم Cron Jobs مهمة شهرية تشغل الفحص الطويل على كل قرص:

والأمر الذي في المهمة هو:

for d in $(smartctl --scan | cut -d" " -f1); do smartctl -t long $d; done

وقد يتساءل البعض: لماذا لا نكتب أسماء الأقراص مباشرة مثل /dev/sda؟ والإجابة أننا فعلنا ذلك في المحاولة الأولى، ثم لاحظنا أن قرص الإقلاع كان اسمه sdc أثناء التثبيت وأصبح sdb بعد إعادة التشغيل، فأسماء sdX تتغير بترتيب اكتشاف الأقراص، وsmartctl --scan يعطيك القائمة الحالية في كل مرة. وأبقينا Hide Standard Error متوقفاً حتى تصل أخطاء الأمر إلى السجل. ولاحظ أن أقراص التجربة افتراضية، فالأمر smartctl -i عليها يقول SMART support is: Unavailable - device lacks SMART capability، أي أننا لم نر نتيجة فحص حقيقية، ولكنك سوف تراها على أقراص حقيقية.

التنبيهات والبريد

كل ما سبق لا فائدة منه إذا حدث خطأ ولم يخبرك أحد، والتنبيهات في TrueNAS تحتاج شيئين: إعداد إرسال البريد، وخدمة التنبيه التي تحدد من يستلم وأي مستوى. الأول من System ثم General Settings ثم Email ثم Settings، وفيه طريقة الإرسال SMTP أو حساب Gmail أو Outlook، ونحن ملأناه بقيم مثال من example.com، فلم نرسل بريداً حقيقياً:

والثاني من System ثم Alert Settings، وفيه خدمة E-Mail موجودة من البداية، ولكن عندما فتحناها وجدنا أمرين: المستوى Level بقيمة Warning، وحقل Override Admin Email فارغاً، أي أنها ترسل إلى بريد المستخدم الإداري، وبريده في تثبيتنا غير محدد. لذلك وضعنا البريد وغيرنا المستوى إلى Notice:

والسبب في تغيير المستوى ظهر في التجربة التالية: ملأنا Pool الثاني backup، الذي سوف نشرحه في القسم التالي، ببيانات عشوائية حتى وصل إلى 87%، فلون TrueNAS مؤشر الاستخدام بالأحمر، وتوثيق شاشة التخزين يقول إنه يعرض التحذير فوق 80%:

وبعد دقائق ظهر التنبيه في جرس التنبيهات:

في الصور أعلاه لاحظ التالي:

• التنبيه بمستوى NOTICE، وفي كود TrueNAS المنشور ثلاثة تنبيهات للمساحة: Notice فوق 85%، وWarning فوق 90%، وCritical فوق 95%، تفحص كل خمس دقائق. فلو بقيت خدمة البريد على Warning لما وصلك هذا التنبيه حتى 90%.
• المؤشر يقول 90.8% والتنبيه يقول 87%، والسبب أن التنبيه يقرأ نسبة capacity من zpool list وهي المساحة الخام المحجوزة، بينما المؤشر يحسب المستخدم من المساحة القابلة للاستخدام بعد ما يحجزه ZFS لنفسه، فلا تستغرب اختلاف الرقمين.
• التنبيه نفسه يقول إن الوقت بتوقيت America/Los_Angeles، وهو المنطقة الزمنية الافتراضية بعد التثبيت، فغيرها من Localization في General Settings حتى تفهم أوقات التنبيهات وأسماء ال Snapshots.

النسخ المتماثل إلى Pool آخر

أنشأنا Pool ثانياً باسم backup على القرص الرابع، ثم من Data Protection ثم Replication Tasks ثم Add فتح معالج Replication Task Wizard، واخترنا المصدر والوجهة On this System، والمصدر /mnt/tank/family والوجهة /mnt/backup/family:

وفي الخطوة الثانية اخترنا Run On a Schedule بالقيمة الافتراضية يومياً، وDestination Snapshot Lifetime بقيمة Same as Source. وبعد الحفظ شغلناه يدوياً من ال Shell، ثم سألنا TrueNAS عما أنشأه:

sudo -i
midclt call pool.snapshottask.query | jq -c '.[] | {id, dataset, naming_schema, schedule: (.schedule.minute+" "+.schedule.hour+" "+.schedule.dow), lifetime: "\(.lifetime_value) \(.lifetime_unit)"}'
ID=$(midclt call replication.query | jq '.[0].id')
midclt call -j replication.run $ID > /dev/null 2>&1
midclt call replication.query | jq -c '.[] | {name, state: .state.state, last_snapshot: .state.last_snapshot}'
zfs list -t all -o name,used,refer -r backup

والمخرج سوف يكون كما يلي:

{"id":1,"dataset":"tank/family","naming_schema":"auto-%Y-%m-%d_%H-%M","schedule":"0 * *","lifetime":"2 WEEK"}
{"id":2,"dataset":"tank/family","naming_schema":"auto-%Y-%m-%d_%H-%M","schedule":"0 0 *","lifetime":"2 WEEK"}
{"name":"tank/family - backup/family","state":"FINISHED","last_snapshot":"tank/family@auto-2026-10-09_14-31"}
NAME                                  USED  REFER
backup                                588K    96K
backup/family                          96K    96K
backup/family@auto-2026-10-09_14-31     0B    96K

في المخرج أعلاه لاحظ التالي:

• المعالج أنشأ مهمة Snapshot ثانية برقم 2 تعمل يومياً، بالإضافة إلى مهمتنا التي تعمل كل ساعة، والنسخ المتماثل مربوط بها، أي أنه يعمل بعد كل Snapshot يومي. فإذا أردت أن ينسخ كل Snapshot من مهمتك فاستخدم Advanced Replication Creation واختر مهمتك الموجودة.
• على backup ظهر ال Dataset وال Snapshot نفسه، وهذا هو zfs send وzfs receive الذي شرحناه في مقال ZFS، والمرات التالية ترسل الفرق فقط.

والنسخ إلى TrueNAS ثان يكون من المعالج نفسه باختيار On a Different System، ويحتاج اتصال SSH Connection بين الجهازين كما في صفحة النسخ البعيد، أما المحلي الذي قمنا به فتقول عنه صفحته إنه مفيد عندما يكون قرص في خطر، وإن النسخ الدوري إلى مكان بعيد هو الأفضل. والسبب واضح: tank وbackup في الجهاز نفسه، فالحريق والسرقة وبرنامج فدية بصلاحيات المدير تصل إليهما معاً.

نسخة مشفرة خارج الجهاز بـ Cloud Sync

النسخة الثالثة في قاعدة 3-2-1 يجب أن تكون خارج المكان، وفي TrueNAS طريقتان: النسخ المتماثل إلى TrueNAS آخر في بيت قريب أو مكتب آخر، أو Cloud Sync الذي يرسل الملفات إلى مزود تخزين. وقائمة المزودين في 25.10.7 كما يعطيها الأمر midclt call cloudsync.providers:

Amazon S3,Backblaze B2,Box,Dropbox,FTP,Google Cloud Storage,Google Drive,Google Photos,HTTP,Hubic,Microsoft Azure Blob Storage,Microsoft OneDrive,OpenStack Swift,pCloud,SFTP,Storj,WebDAV,Yandex,

ولم نستخدم حساباً سحابياً في التجربة، وإنما شغلنا سيرفر SFTP داخل ال Container يمثل الجهاز البعيد، ويصل إليه الجهاز الافتراضي على العنوان 10.0.2.2 الذي يعطيه QEMU للجهاز المضيف. ثم أضفنا بيانات الدخول من Credentials ثم Backup Credentials، وأنشأنا مهمة من Cloud Sync Tasks ثم Add، باتجاه PUSH ووضع COPY، من /mnt/tank/family إلى المجلد /home/offsite/nas-backup على السيرفر البعيد:

والوضع COPY ينسخ الجديد ولا يحذف من الوجهة ما حذفته من المصدر، أما SYNC فيجعل الوجهة مطابقة فيحذف منها، لذلك COPY أنسب لنسخة احتياطية، مع مراقبة المساحة. وخيار التشفير Remote Encryption موجود في النموذج المتقدم Advanced Options كما في صفحة Cloud Sync، ويستخدم rclone crypt. والانتقال إلى النموذج المتقدم من المعالج يمسح ما كتبته في الخطوة الثانية كما نبهتنا الواجهة، لذلك حفظنا المهمة من المعالج، ثم فعلنا التشفير وتشفير أسماء الملفات بـ midclt، ثم شغلناها:

sudo midclt call cloudsync.update 1 '{"encryption": true, "encryption_password": "offsite-encryption-pass-2026", "encryption_salt": "lab-salt-2026", "filename_encryption": true}' | jq -c '{description, direction, transfer_mode, path, attributes, encryption, filename_encryption}'
sudo midclt call -j cloudsync.sync 1 > /dev/null
sudo midclt call cloudsync.query | jq -c '.[] | {description, state: .job.state, progress: .job.progress.description}'

والمخرج سوف يكون كما يلي:

{"description":"family share to off-site SFTP (encrypted)","direction":"PUSH","transfer_mode":"COPY","path":"/mnt/tank/family","attributes":{"folder":"/home/offsite/nas-backup"},"encryption":true,"filename_encryption":true}
{"description":"family share to off-site SFTP (encrypted)","state":"SUCCESS","progress":"1 / 1, 78 B / 78 B, 0 B/s, ETA -"}

وعلى السيرفر البعيد هذا ما وصل:

ls -la /home/offsite/nas-backup
od -c /home/offsite/nas-backup/e6r1ej9asflgod84de3okhr8ns | head -3

والمخرج سوف يكون كما يلي:

total 12
drwxr-xr-x 2 offsite offsite 4096 Oct  9 21:51 .
drwx------ 3 offsite offsite 4096 Oct  9 21:49 ..
-rw-rw-r-- 1 offsite offsite   78 Oct  9 21:31 e6r1ej9asflgod84de3okhr8ns
0000000   R   C   L   O   N   E  \0  \0 201 302   n 226 235 304 266   _
0000020 035   G   _ 003   O 260 030   ;  \t 266 241 304   L   l   }   W
0000040 024 255   D 256   ^ 246   4   2   Q 315 300   a 027 275 225 245

في المخرج أعلاه لاحظ التالي:

• اسم الملف budget.txt أصبح e6r1ej9asflgod84de3okhr8ns، والمحتوى بحجم 30 بايتاً أصبح 78 بايتاً يبدأ بكلمة RCLONE، لأن Cloud Sync مبني على rclone وتشفيره، فالمزود لا يرى أسماء ملفاتك ولا محتواها.
• عبارة التشفير والملح Salt هما المفتاح الوحيد للاستعادة، فاحفظهما خارج TrueNAS، لأنك سوف تحتاجهما بالضبط عندما يكون TrueNAS نفسه قد ضاع.
• هذه نسخة ملفات وليست Snapshots، فإذا شفر برنامج فدية ملفاتك ثم عمل COPY بعده نسخت الملفات المشفرة فوق القديمة، لذلك اختر مزوداً يحفظ نسخ الملفات القديمة أو يمنع الحذف، كما شرحنا في قسم النسخ التي لا يحذفها المخترق، أو استخدم أداة نسخ احتياطي حقيقية مثل restic كما في مقارنة أدوات النسخ الاحتياطي.

وصفحة Data Protection تعرض الآن كل المهام وحالتها في مكان واحد:

ولاحظ بطاقة TrueCloud Backup Tasks، وهي خدمة نسخ احتياطي من TrueNAS على شبكة Storj كما يقول وصفها في الصفحة، ولم نستخدمها في التجربة.

التطبيقات باختصار

منذ الإصدار 24.10 (Electric Eel) تعمل تطبيقات TrueNAS على Docker بدل Kubernetes بحسب ملاحظات الإصدار، وعند أول دخول إلى Apps يطلب منك اختيار Pool للتطبيقات، فاخترنا tank، فأنشأ TrueNAS ال Dataset tank/ix-apps، وظهر Docker Engine بالإصدار 28.3.1، وعرض الكتالوج 461 تطبيقاً، وزر Custom App لتشغيل تطبيقك بملف Compose:

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

التحديثات وبيئات الإقلاع

صفحة System ثم Update تعرض الإصدار الحالي وملف التحديث Update Profile، وهو مستوى المخاطرة الذي تقبله: Developer ثم Early Adopter ثم General ثم Mission Critical، وصفحة التحديث تقول إن TrueNAS ينبهك فقط إلى التحديثات المناسبة لملفك:

ولاحظ أن تثبيتنا الجديد ظهر بالملف MISSION_CRITICAL، وهو بحسب صفحة شاشة التحديث أكثر الملفات تحفظاً وتحديثاته نادرة، مع أن الصفحة نفسها تعرض General على أنه الافتراضي، فاختر الملف الذي يناسبك بنفسك ولا تفترض. وقبل أي تحديث يعرض TrueNAS نافذة لحفظ ملف الإعدادات، فاحفظه مع Export Password Secret Seed، والسبب أن هذا الملف يعيد بناء الجهاز كله على قرص إقلاع جديد. والأمان الثاني في التحديث هو بيئات الإقلاع Boot Environments:

وبيئة الإقلاع Dataset على boot-pool، وبحسب صفحة إدارة الإقلاع فإن التحديث ينشئ Snapshot من البيئة الحالية ويضيفها إلى قائمة الإقلاع قبل أن يطبق التحديث، فإذا فشل التحديث تفعل البيئة السابقة وتعيد التشغيل، والخيار Keep يمنع حذف بيئة معينة عندما يحتاج تحديث إلى مساحة. وهذا سبب آخر لقرص إقلاع بحجم معقول، فدليل العتاد يقول إن 16 أو 32 جيجابايت تترك مساحة لبيئات أكثر.

أخطاء شائعة

• ذاكرة USB كقرص إقلاع: المثبت نفسه يحذر منها، ودليل العتاد يقول إن الإصدارات الحديثة تكتب على قرص الإقلاع أكثر، فاستخدم SSD صغيراً، واحتفظ بملف الإعدادات خارجه.
• RAID اللوحة الأم أو كرت RAID: دليل العتاد يقول لا تستخدم RAID اللوحة الأم، وإن كرت RAID قد يخفي أرقام الأقراص التسلسلية وبيانات SMART ويكون أبطأ، وقد يضيع البيانات إذا كانت ذاكرة الكتابة فيه ببطارية ميتة، فاستخدم وضع HBA أو IT كما في مقال بناء NAS.
• أقراص SMR: الدليل نفسه يقول إن الأقراص التي تديرها الشركة بنفسها DM-SMR لا تعمل جيداً مع TrueNAS وإعادة البناء عليها أطول وأقل موثوقية، والتفاصيل في قسم CMR وSMR.
• ملء ال Pool فوق 80%: الواجهة تحمر عند 80%، والتنبيهات تبدأ عند 85%، وخدمة البريد الافتراضية لا ترسل قبل 90%، فخطط للتوسيع قبل ذلك.
• عدم وجود نسخة خارج الجهاز: ال Snapshots والنسخ إلى Pool آخر كلها في الصندوق نفسه.
• ترك builtin_users بصلاحية Modify: كل مستخدم SMB يعدل كل شيء، فراجع ال ACL قبل أن تعطي الناس كلمات مرورهم.
• فتح NFS لكل العناوين: حدد الشبكة أو الأجهزة، لأن NFS يصدق رقم المستخدم الذي يرسله الكلاينت.
• الاعتماد على دليل SMART قديم: 25.10 أزال جدولة SMART من الواجهة، فاستخدم Cron أو تطبيقاً مثل Scrutiny.
• خدمة بريد بلا عنوان: التنبيه يظهر في الواجهة فقط، ولن تراه إذا لم تدخل إليها.
• فتح الواجهة على الإنترنت: ادخل عبر VPN فقط.

التنظيف

umount /mnt/linux
docker rm -f lab-truenas-qemu
rm -f lab-truenas-boot.qcow2 lab-truenas-data1.qcow2 lab-truenas-data2.qcow2 lab-truenas-data3.qcow2 lab-truenas-data4.qcow2

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

تدريب عملي

1. أضف مستخدماً ثالثاً إلى المجموعة family، وتأكد بـ smbclient أنه يكتب دون أن تغير ال ACL، ثم احذفه من المجموعة وتأكد أنه فقد الصلاحية.
2. غير مستوى خدمة البريد إلى Warning، وأضف ملفاً حتى يتجاوز backup نسبة 90%، وراقب متى يظهر التنبيه ومستواه.

الخلاصة

• الإصدار الموصى به اليوم TrueNAS CE 25.10.7، وفيه نواة 6.12.105 وOpenZFS 2.3.9 وDocker 28.3.1، والإصدار 27 ما زال RC.
• اختر قرص إقلاع SSD صغيراً، فالمثبت نفسه يحذر من USB، والقرص الذي تختاره لا يدخل في أي Pool.
• Dataset لكل مشاركة، والإعداد SMB يضبط ACL من نوع NFSv4 وأسماء لا تفرق بين الحروف، وراجع ال ACL الافتراضي لأن builtin_users فيه بصلاحية Modify.
• Snapshots كل ساعة تظهر في Previous Versions، واستعدنا بها ملفاً محذوفاً من SMB دون الدخول إلى TrueNAS.
• ال Scrub مجدول تلقائياً، وSMART أصبح بمهمة Cron منذ 25.10، والتنبيهات تحتاج عنوان بريد ومستوى Notice حتى تصلك عند 85%.
• النسخ المتماثل إلى Pool آخر سريع ولكنه في الجهاز نفسه، والنسخة الثالثة خارج الجهاز بـ Cloud Sync مشفر أو TrueNAS ثان.

دليلZFS للمبتدئين: كيف يحمي بياناتك من التلف الصامتكيف يكتشف ZFS التلف الصامت ويصلحه، وكيف ترتب الأقراص في Pool يتحمل العطل وتستعيد ملفاتك من Snapshots.دليلأي نظام تشغيل تضعه على NAS تبنيه بنفسك؟كيف تختار نظام تشغيل لجهاز NAS تبنيه بنفسك، مع تجربة تستعيد فيها ملفاً محذوفاً وقرصاً كاملاً من التماثل.دليلNAS جاهز أم تبنيه بنفسك؟ ما الذي تكسبه وما تخسرهكيف تقرر بين جهاز NAS جاهز وجهاز تبنيه بنفسك، بأرقام الشركات وأسعارها الرسمية وما تعلمناه من هجمات الفدية.دليلالنسخ الاحتياطي بقاعدة 3-2-1 واختبار الاستعادةكيف تحدد كم بيانات تقبل أن تخسر، وتبني نسخاً لا يستطيع المخترق حذفها، وتتأكد أنك تستطيع استعادتها فعلاً.دليلأي أداة نسخ احتياطي Backup تناسب سيرفرك؟مقارنة عملية لأشهر أدوات النسخ الاحتياطي مفتوحة المصدر على البيانات نفسها في الوقت والحجم والذاكرة، لتعرف أيها يناسب سيرفرك.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، والتجربة على TrueNAS CE 25.10.7 (Goldeye) من ملف ISO الرسمي في جهاز افتراضي بـ QEMU 10.0.13 مع KVM داخل Docker Engine 29.8.0، بذاكرة 8 جيجابايت وأقراص افتراضية بحجم 8 جيجابايت، والاختبار من smbclient 4.22.11 وكلاينت NFS في Debian 13، والمعلومات من توثيق TrueNAS 25.10 وصفحة حالة البرامج كما قرأناها في 9 أكتوبر 2026.