أواجه مشكلة في تفعيل ترخيص Registered Community على مثيل ذاتي الاستضافة. عند محاولة التفعيل عبر واجهة الويب أو باستخدام متغير البيئة، يفشل التفعيل مع خطأ التحقق من صحة بصمة الجهاز.
ومع ذلك، فإن تشغيل أداة CLI داخل الحاوية يظهر أنه يتم إنشاء بصمة صحيحة. يبدو أن هناك تناقضًا حيث أن عملية الويب في الخلفية/SDK تمرر سلسلة بصمة فارغة أو مختصرة إلى خوادم الترخيص الخاصة بك.
عند الوصول لأول مرة إلى محطة الحاوية وتشغيل n8n license:info يدويًا، يتم إنشاء بصمة صحيحة كاملة بـ 64 حرفًا بنجاح وتكون مرئية:
لم أتمكن من جعل Debug في Editor يعمل - قالت إنني بحاجة إلى التسجيل. كان يجب أن أكون قد قمت به بالفعل. لقد فعلت ذلك في الماضي - لا أعرف لماذا تغير هذا.
رأيت هذا في السجلات الخاصة بي:
[license SDK] cert is invalid because it has expired: (autorenewalsEnabled: true, expiredAt: Sat May 09 2026 15:29:44 GMT-0400 (Eastern Daylight Time), issuedAt: Wed Apr 29 2026 15:29:44 GMT-0400 (Eastern Daylight Time))
لدي TZ=America/New_York و32 بت N8N_ENCRYPTION_KEY لم يتغير. مفتاح التشفير موجود في متغيرات البيئة والملف الإعدادات .n8n/config
عندما أحاول النقر فوق الزر في بريد التفعيل أو لصقه، أحصل على نفس الشيء:
UI:
Activation key is in the wrong format
log:
[license SDK] license activation failed: request/body/deviceFingerprint must NOT have fewer than 32 characters
قمت بـ n8n license:clear ثم أعدت التشغيل. الآن أحصل على هذا في السجل:
[license SDK] Skipping renewal on init: license cert is not initialized
كان هذا يعمل بشكل جيد على صورة Docker هذه (الإصدارات السابقة قبل عدة أشهر).
حاولت أيضًا تمرير المفتاح مباشرة إلى الحاوية عبر N8N_LICENSE_ACTIVATION_KEY، مما أسفر عن نفس فشل السجل.
لقد استخدمت 3 ذكاء اصطناعي مختلف للمساعدة في إصلاح هذا وقد نفدنا من الأفكار
ماذا يمكنني أن أفعل؟
ما هي رسالة الخطأ (إن وجدت)؟
عند محاولة التفعيل عبر واجهة المستخدم أو استخدام N8N_LICENSE_ACTIVATION_KEY، تُظهر سجلات الحاوية:
[license SDK] Skipping renewal on init: license cert is not initialized
[license SDK] license activation failed: request/body/deviceFingerprint must NOT have fewer than 32 characters
Could not activate license
معلومات إعداد n8n الخاص بك
إصدار n8n: 2.26.7 (يحدث أيضًا مع الإصدارات السابقة)
@jmaver تشغيلك للـ CLI قد جدّده بالفعل، عرض license:info الثاني يظهر isValid true الآن (ينتهي في 28 يونيو). حالة الترخيص مخزّنة في قاعدة البيانات، لذا الشهادة مصححة هناك لكن العملية التي تعمل لديك تحتفظ بالشهادة المنتهية الصلاحية التي تم تخزينها مؤقتاً عند البدء. أعد تشغيل حاوية n8n، فهي تعيد تحميل الشهادة الصحيحة من قاعدة البيانات ويعود الـ registered و Debug في Editor. انتهت الصلاحية لأن رخصة المجتمع يجب أن تصل إلى license.n8n.io/v1 للتجديد تقريباً كل 10 أيام، لذا تأكد من أن الاتصالات الخارجة لا تكون مسدودة بواسطة proxy أو firewall.
لقد أعدت التشغيل عدة مرات. كل إقلاع مع متغير التفعيل يظهر نفس الخطأ، محاولة إضافة رمز الترخيص يدويًا لا تزال تفشل، ولا يزال بإمكاني تصحيح الأخطاء في المحرر.
@jmaver نعم، هذا هو عدم التطابق بين بصمة الجهاز، الشهادة الخاصة بك مرتبطة ببصمة واحدة لكن النسخة تقدم بصمة مختلفة في كل إقلاع لذا تظل ترفضها بغض النظر عن عدد مرات إعادة التشغيل، وهذا أيضًا السبب في عدم الاحتفاظ بـ license.cert. قم أولاً بإسقاط متغير البيئة N8N_LICENSE_ACTIVATION_KEY، تركه يعني أن كل إقلاع يعيد تشغيل التفعيل ويعيد ضربة عدم التطابق بدلاً من مجرد تحميل ما هو في قاعدة البيانات. لكن بما أن الربط نفسه معطل، فإن الحل الحقيقي هو إرسال بريد إلى help@n8n.io لإعادة تعيين المفتاح، يتم استهلاك مفتاح المجتمع مقابل البصمة القديمة ولا يمكن إطلاقه إلا من خلالهم حتى يعاد ربطه بنسختك الحالية.
عندما تقوم بتشغيل n8n license:info في shell، فأنت على الأرجح تقوم بتشغيله كمستخدم (غالباً root أو مستخدم node الافتراضي) لديه وصول كامل إلى معرّفات النظام المستخدمة لإنشاء البصمة. ومع ذلك، فإن عملية n8n الرئيسية—التي تتعامل مع Web UI وN8N_LICENSE_ACTIVATION_KEY—تفشل في حل نفس البصمة، وترسل سلسلة نصية فارغة أو قيمة null إلى خادم الترخيص، مما يؤدي إلى تشغيل خطأ التحقق “أقل من 32 حرفاً”.
حاول أن تقوم بربط ملف machine-id بشكل صريح في الحاوية للتأكد من أنه متسق وقابل للقراءة.
أنشئ ملفاً على مضيف Synology الخاص بك (على سبيل المثال، في مجلد إعدادات n8n الخاص بك) باسم machine-id يحتوي على سلسلة نصية عشوائية بطول 32 حرفاً سادس عشري بداخله.
أضف تعيين volume في إعدادات Docker/Container Manager:
File/Folder:/volume1/docker/n8n/machine-id (اضبطها حسب مسارك) →Mount path:/etc/machine-id
/etc $ ls -al /etc/machine-id
-rwxr-xr-x 1 1024 100 32 Jun 22 11:57 /etc/machine-id
/etc $ ls -l /etc/machine-id /var/lib/dbus/machine-id
ls: /var/lib/dbus/machine-id: No such file or directory
التفصيل الرئيسي هنا هو أن توليد بصمة n8n يتحقق من كل من /etc/machine-id و /var/lib/dbus/machine-id - بما أن المسار الثاني مفقود في حاويتك، قد لا يتم حل المعرّف بشكل صحيح حتى مع تعيين الأول.
إذا كنت لا تملك هذا الملف على المضيف، أنشئه أولاً: cat /etc/machine-id | sudo tee /var/lib/dbus/machine-id. ثم أعد تشغيل الحاوية وحاول تفعيل الترخيص مرة أخرى.
@jmaver مسار machine-id هو طريق مسدود، سطر الأوامر لديك بالفعل ينشئ بصمة كاملة بـ 64 حرفًا من /etc/machine-id لذا القرار يعمل بشكل جيد، هذا ليس هو المشكلة. البصمة الفارغة تظهر فقط في طلب التفعيل، هذا هو الخلل الحقيقي، التفعيل لا يرسل البصمة التي تحسبها نسختك بوضوح. وطلب license:info السابق لديك جدّد شهادة صالحة (isValid: true)، لذا التجديد يعمل والتفعيل فقط هو المعطل، مما يعني أن license:clear كان الخطوة الخاطئة، لقد مسحت تلك الشهادة الجيدة وألقت بك على مسار التفعيل المعطل. إعادة محاولة التفعيل أو مفتاح env لن تساعد الآن. أسهل استعادة هي استعادة صف license.cert في جدول الإعدادات من لقطة قاعدة بيانات مأخوذة قبل المسح. بدون لقطة، إذن هذا خلل تفعيل نظيف وقابل للتكرار، أرسل ناتج license:info هذا إلى help@n8n.io حتى يعيدوا الزراعة ضد بصمتك.
~ $ ls -l /etc/machine-id /var/lib/dbus/machine-id
-rwxr-xr-x 1 1024 100 32 Jun 22 11:57 /etc/machine-id
-rwxr-xr-x 1 1024 100 32 Jun 22 11:57 /var/lib/dbus/machine-id
نفس النتائج. إليك نسخة التصحيح من السجل، لا يبدو أنها تضيف أي شيء:
- 2026-06-22T19:29:18.132Z | debug | [license SDK] initializing for deviceFingerprint n8n-j {"scopes":["license"],"file":"LicenseManager.js","function":"log"}
- 2026-06-22T19:29:18.137Z | info | [license SDK] Skipping renewal on init: license cert is not initialized {"scopes":["license"],"file":"LicenseManager.js","function":"log"}
- 2026-06-22T19:29:18.138Z | debug | License initialized {"scopes":["license"],"file":"license.js","function":"init"}
- 2026-06-22T19:29:18.141Z | debug | Attempting license activation {"file":"base-command.js","function":"initLicense"}
- 2026-06-22T19:29:18.335Z | warn | [license SDK] license activation failed: request/body/deviceFingerprint must NOT have fewer than 32 characters {"scopes":["license"],"file":"LicenseManager.js","function":"log"}
- 2026-06-22T19:29:18.574Z | error | Could not activate license {"error":{"name":"Error","message":"license activation failed: request/body/deviceFingerprint must NOT have fewer than 32 characters","stack":"Error: license activation failed: request/body/deviceFingerprint must NOT have fewer than 32 characters\n at v.activate (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n_io+license-sdk@2.25.0/node_modules/@n8n_io/license-sdk/src/LicenseManager.ts:461:17)\n at processTicksAndRejections (node:internal/process/task_queues:104:5)\n at License.activate (/usr/local/lib/node_modules/n8n/src/license.ts:208:3)\n at Start.initLicense (/usr/local/lib/node_modules/n8n/src/commands/base-command.ts:318:5)\n at Start.init (/usr/local/lib/node_modules/n8n/src/commands/start.ts:239:3)\n at CommandRegistry.execute (/usr/local/lib/node_modules/n8n/src/command-registry.ts:82:4)\n at /usr/local/lib/node_modules/n8n/bin/n8n:63:2"},"file":"base-command.js","function":"initLicense"}
@jmaver حسنًا، الملفان موجودان الآن وتستمر المشكلة، لذا تم استبعاد معرّف الجهاز بالكامل. لكن انظر إلى هذا السطر من التصحيح، الخادم يتم تهيئته باستخدام deviceFingerprint “n8n-j…” وهي قيمة قصيرة، وهذه هي قيمة أقل من 32 حرفًا التي يتم رفضها، وليست hash بـ 64 حرفًا الذي ينشئه CLI الخاص بك. وبالتالي فإن العملية قيد التشغيل يتم تمريرها بصمة مقطوعة من مكان ما بدلاً من حسابها. ما اسم مضيف الحاوية، وهل هناك أي إدخالات متبقية متعلقة بـ N8N_LICENSE_* أو بصمة الإصبع في compose/config الخاص بك من المحاولات السابقة؟ هذا الاختصار n8n-j يأتي بالتأكيد من أحد تلك الإدخالات.
تصحيح لردي السابق، كان لدي الآلية خاطئة لذا تجاهل جزء اسم المضيف. بصمة ترخيص n8n هي instanceId (من المصدر، deviceFingerprint: () => instanceId)، وليس اسم المضيف. واجهة سطر الأوامر لديك تعرض instanceId صحيح بـ 64 حرفًا (a11f905a…)، لكن طلب التفعيل يتم رفضه لأنه يرسل واحدًا أقل من 32 حرفًا، لذلك مسار التفعيل لا يختار instanceId صحيحًا على الرغم من وجود واحد بوضوح.
ليس لدي سبب جذري موثق لسبب ظهوره قصيرًا فقط في تدفق التفعيل. لكن بما أن license:info السابق لديك قد جدد شهادة صحيحة بالفعل، فإن المسار الأكثر موثوقية هو استعادة صف license.cert من لقطة قاعدة بيانات مأخوذة قبل تشغيل license:clear، أو طلب دعم n8n لإعادة بذره، بدلاً من المزيد من تغييرات معرّف الجهاز أو اسم المضيف.
مرحبًا @jmaver، لقد وجدت المشكلة في compose الخاص بك، أنت تملك:
N8N_INSTANCE_ID: n8n-j
هذا يحتوي على 5 أحرف فقط. SDK الترخيص في n8n يشتق deviceFingerprint مباشرة من معرّف المثيل (instance ID)، وخادم الترخيص يتطلب حد أدنى من 32 حرفًا. لذلك n8n-j هو ما يتم إرساله كـ fingerprint، وهذا بالضبط السبب في حصولك على خطأ “must NOT have fewer than 32 characters”.
الحل: إما أن تزيل N8N_INSTANCE_ID بالكامل (سيقوم n8n بإنشاء UUID صحيح تلقائيًا)، أو استبدله بـ UUID صحيح:
بعد تغييره، أزل N8N_LICENSE_ACTIVATION_KEY مؤقتًا، وأعد التشغيل، وشغّل n8n license:info للتأكد من أن الـ fingerprint الجديد يحتوي على 64 حرفًا، ثم أعد إضافة مفتاح التفعيل وأعد التشغيل مرة واحدة أخرى.
هذا يجب أن يحل المشكلة دون الحاجة للتواصل مع فريق الدعم.
