خطای User does not exist on the system در Directadmin

خطای User does not exist on the system در دایرکت ادمین یعنی نام کاربری در دیتای داخلی خود پنل ثبت شده، اما کاربر متناظر آن در سطح سیستم‌عامل (فایل /etc/passwd) وجود ندارد؛ اگر جای این‌گونه فایل‌ها را نمی‌شناسید، ساختار دایرکتوری‌های لینوکس و مسیر فایل‌های مهم سیستمی نقشه کلی را نشان می‌دهد. راه‌حل درست، بازسازی همان طرفی است که کم است؛ نه پاک کردن عجولانه طرف دیگر.

این خطا دقیقاً چه چیزی را نشان می‌دهد

دایرکت ادمین اطلاعات هر اکانت را در دو جای کاملاً مستقل نگه می‌دارد:

• رکورد داخلی پنل: پوشه /usr/local/directadmin/data/users/username و فایل user.conf داخل آن، به‌علاوه نام کاربر در فایل users.list متعلق به سازنده‌اش (ادمین یا نماینده).
• کاربر واقعی لینوکس: رکوردهای موجود در /etc/passwd، /etc/shadow، /etc/group و /etc/gshadow به‌همراه دایرکتوری خانگی در /home/username.

این پیام را با تعلیق اکانت اشتباه نگیرید؛ اگر کاربر فقط معلق شده باشد رکوردهایش سالم‌اند و مسیر رفع آن در رفع مشکل suspend شدن اکانت در دایرکت ادمین توضیح داده شده است. تا وقتی این دو با هم هماهنگ‌اند همه چیز عادی است. به‌محض اینکه یکی از آن‌ها ناقص شود، پنل هنگام لیست کردن کاربران یا شروع بکاپ‌گیری به نام کاربری می‌رسد که معادل سیستمی ندارد و همین پیام را نمایش می‌دهد. پس این خطا یک باگ در دایرکت ادمین نیست؛ گزارش یک ناهماهنگی در داده‌هاست.

چه چیزی این ناهماهنگی را می‌سازد

• ریستور یا انتقال ناقص اکانت‌ها؛ مثلاً وقتی اکانت‌ها روی یک ماشین مجازی تازه بازگردانی می‌شوند و ساخت کاربر سیستمی به‌دلیل پر شدن دیسک، تداخل UID یا قطع شدن فرآیند، نیمه‌کاره می‌ماند. مهاجرت بین دو کنترل‌پنل هم دقیقاً همین ریسک را دارد؛ ترتیب امن این کار در راهنمای انتقال بکاپ از دایرکت ادمین به سی پنل آمده است.
• حذف دستی اکانت با userdel به‌جای حذف از داخل پنل؛ در این حالت رکورد دایرکت ادمین سر جایش باقی می‌ماند.
• خراب شدن فایل users.list. مستندات رسمی دایرکت ادمین تصریح می‌کند این فایل وقتی چند پروسه هم‌زمان روی آن می‌نویسند می‌تواند خراب شود.
• بازگرداندن /etc/passwd از یک نسخه پشتیبان قدیمی‌تر از دیتای پنل.

گام اول: مشخص کنید کدام طرف کم است

قبل از هر تغییری با SSH وارد سرور شوید و وضعیت دو طرف را جداگانه ببینید. به‌جای username نام کاربر مشکل‌دار را بگذارید:

• وجود کاربر سیستمی: getent passwd username
• وجود رکورد پنل: ls -ld /usr/local/directadmin/data/users/username
• عضویت در لیست سازنده: grep -rn "^username$" /usr/local/directadmin/data/users/*/users.list
• دایرکتوری خانگی و شناسه عددی مالک آن: ls -dn /home/username
• سازنده اکانت: grep ^creator= /usr/local/directadmin/data/users/username/user.conf

خروجی همین پنج دستور تکلیف را روشن می‌کند. لاگ‌های /var/log/directadmin/error.log و /var/log/directadmin/errortaskq.log هم معمولاً علت اصلی را نشان می‌دهند و ارزش خواندن دارند.

حالت اول: کاربر سیستمی هست، اما در users.list نیست

اگر getent passwd username خروجی می‌دهد و پوشه دیتای کاربر هم موجود است، فقط نام کاربر از فایل لیست سازنده افتاده است. این کم‌خطرترین حالت است. کافی است نام را به لیست همان سازنده اضافه کنید (یک نام در هر خط):

• گرفتن نسخه پشتیبان از لیست: cp -a /usr/local/directadmin/data/users/admin/users.list /root/users.list.bak
• افزودن کاربر: echo "username" >> /usr/local/directadmin/data/users/admin/users.list

به‌جای admin همان مقداری را بگذارید که در creator= دیدید. اگر لیست چند نماینده هم‌زمان به‌هم ریخته، به‌جای ویرایش دستی از اسکریپت رسمی بازسازی لیست‌ها استفاده کنید که در مستندات دایرکت ادمین منتشر شده است؛ آن اسکریپت لیست هر نماینده را از روی user.conf کاربران بازسازی می‌کند.

بازسازی کش کاربران بعد از هر اصلاح

دایرکت ادمین فهرست کاربران را کش می‌کند، بنابراین تغییر فایل‌ها به‌تنهایی کافی نیست. پس از اصلاح، کش را پاک و صف وظایف را اجرا کنید:

• rm -f /usr/local/directadmin/data/admin/show_all_users.cache
• echo "action=cache&value=showallusers" >> /usr/local/directadmin/data/task.queue
• /usr/local/directadmin/dataskq d800

در نسخه‌های جدیدتر پنل همین کار با یک دستور انجام می‌شود: da taskq --run="action=cache&value=showallusers". اگر دستور da روی سرور شما وجود ندارد، نسخه پنل قدیمی است؛ به‌روزرسانی به نسخه‌های جدید نیازمند لایسنس معتبر دایرکت ادمین است و بهتر است پیش از هر تغییر ساختاری انجام شود.

حالت دوم: رکورد پنل هست، اما کاربر سیستمی وجود ندارد

هشدار: این حساس‌ترین حالت است. پیش از هر کاری از /home/username و /usr/local/directadmin/data/users/username یک آرشیو کامل بگیرید و آن را بیرون از مسیرهای اصلی نگه دارید.

امن‌ترین راه، ریستور همان اکانت از آخرین نسخه پشتیبان سالم دایرکت ادمین است؛ چون فرآیند ریستور، هم کاربر سیستمی و هم رکورد پنل را با هم و هماهنگ می‌سازد و چیزی از قلم نمی‌افتد.

اگر نسخه پشتیبانی در کار نیست و می‌خواهید کاربر سیستمی را دستی بسازید، باید UID و GID اصلی را دقیقاً رعایت کنید. خروجی ls -dn /home/username شناسه عددی مالک و گروه فایل‌های موجود را نشان می‌دهد. ساختن کاربر با شناسه متفاوت باعث می‌شود مالکیت فایل‌های خانه، صندوق‌های ایمیل و مسیرهای وب به‌هم بریزد و عملاً یک خرابی بزرگ‌تر جای خرابی کوچک‌تر بنشیند. اگر ترجیح می‌دهید این کار را خودتان انجام ندهید، روی یک VPS مدیریت‌شده نصب و پیکربندی کنترل‌پنل و رفع اشکال نرم‌افزارهای نصب‌شده بر عهده تیم فنی است.

حالت سوم: رکورد یتیمی که واقعاً نباید روی سرور باشد

گاهی کاربر عمداً حذف شده و فقط رد پای او در دیتای پنل مانده است. در این حالت هدف پاک‌سازی است، اما مسیر باید برگشت‌پذیر باشد:

• ابتدا آرشیو بگیرید: tar -czf /root/orphan-username.tar.gz /usr/local/directadmin/data/users/username /home/username
• سپس پوشه دیتا را به‌جای حذف، جابه‌جا کنید: mv /usr/local/directadmin/data/users/username /root/da-orphan-username
• و در پایان نام کاربر را از لیست سازنده بردارید: sed -i '/^username$/d' /usr/local/directadmin/data/users/admin/users.list

این سه دستور تخریبی هستند. اجرای sed -i فایل را در جا تغییر می‌دهد، پس نسخه پشتیبانی که در بالا گرفتید واقعاً باید وجود داشته باشد. اگر روی یک سرور عملیاتی کار می‌کنید و از یتیم بودن رکورد مطمئن نیستید، پیش از اجرا از تیم پشتیبانی کمک بگیرید. بعد از پاک‌سازی، کش کاربران را دوباره بسازید تا لیست پنل به‌روز شود.

درباره توصیه رایج ./directadmin i

در بسیاری از یادداشت‌های فارسی برای این خطا اجرای cd /usr/local/directadmin/ و سپس ./directadmin i پیشنهاد شده است. طبق مستندات رسمی، دستور info (با نام کوتاه o) فقط اطلاعات کامپایل باینری را چاپ می‌کند و چیزی را در دیتای کاربران اصلاح نمی‌کند. اگر با اجرای آن نتیجه نگرفتید، طبیعی است؛ مسیر درست همان بررسی دوطرفه‌ای است که در بالا آمد.

جمع‌بندی

این خطا تقریباً همیشه بعد از یک ریستور، مهاجرت یا حذف دستی ظاهر می‌شود و درمانش یک دستور جادویی نیست: اول با getent passwd و پوشه دیتای کاربر بفهمید کدام طرف کم است، بعد همان طرف را بازسازی کنید و در پایان کش کاربران را تازه کنید. بازگرداندن یک اکانت پاک‌شده معمولاً خیلی پرهزینه‌تر از یک بررسی چنددقیقه‌ای است، پس ترتیب «بکاپ، بررسی، اصلاح» را به‌هم نزنید.