[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fucEnN7oFYfm-pFbVg635yHZTDYwbb-yvqnGjIE3pz9k":3},{"data":4,"related":93},{"id":5,"title":6,"slug":7,"excerpt":8,"cover":9,"category":11,"author":14,"track":20,"level":23,"reading_minutes":26,"is_featured":27,"published_at":28,"updated_at":28,"body":29,"toc":30,"tags":63,"faqs":77,"related_services":87,"comments_enabled":91,"meta_title":19,"meta_description":92,"canonical_url":19,"noindex":27,"is_live":91},42,"کران Nextcloud در Docker: چرا جاب‌های پس‌زمینه اجرا نمی‌شوند","nextcloud-docker-cron-background-jobs","هشدار «Last background job execution ran...» در Nextcloud Docker اغلب از اجرا نشدن cron.php داخل کانتینر است. مسیر، کاربر و حالت cron را درست می‌کنیم.",{"url":10,"alt":6},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F0ac03659-116f-46ee-9c7c-9e8e8107d8eb.webp",{"name":12,"slug":13},"ابزارهای Self-Hosted","self-hosted",{"name":15,"slug":16,"role":17,"bio":18,"linkedin_url":19,"avatar_url":19},"تحریریه کلودیکپ","cloudicap-editorial","تیم محتوای کلودیکپ","تیم فنی و محتوای کلودیکپ؛ مهندسانی که هر روز با DevOps، Kubernetes و زیرساخت ابری کار می‌کنند و تجربه‌هایشان را اینجا می‌نویسند.",null,{"value":21,"label":22},"engineers","مهندسان",{"value":24,"label":25},"intermediate","متوسط",7,false,"2026-11-12T06:15:27+00:00","\u003Cp>اگر \u003Ca href=\"\u002Fservices\u002Fnextcloud-self-hosted\">Nextcloud\u003C\u002Fa> را در Docker بالا آورده‌اید و در صفحه Overview پنل ادمین این هشدار را می‌بینید: «Last background job execution ran 4 hours ago. Something seems wrong.» احتمالاً تا حالا چند بار crontab هاست را چک کرده‌اید و خط کران هم سر جایش هست. اما مشکل معمولاً از نبودن کران نیست؛ از این است که آن خط، \u003Ccode>cron.php\u003C\u002Fcode> را در جای اشتباهی اجرا می‌کند.\u003C\u002Fp>\n\u003Cp>Nextcloud برای کارهایی مثل پاک‌سازی Trash، حذف نسخه‌های قدیمی فایل‌ها، تولید preview، پردازش اشتراک‌های فدرال و بسیاری کارهای پس‌زمینه به یک کران واقعی نیاز دارد که هر ۵ دقیقه اجرا شود. اگر این کران درست تنظیم نشود، خود Nextcloud بالا می‌آید و کاربران می‌توانند فایل آپلود کنند، ولی پشت صحنه کم‌کم به مشکل می‌خورد.\u003C\u002Fp>\n\u003Ch2 id=\"نشانه‌ها-چه-چیزی-واقعا-دیده-می‌شود\">نشانه‌ها؛ چه چیزی واقعاً دیده می‌شود\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>در پنل ادمین، هشدار «Last background job execution ran ... Something seems wrong» دیده می‌شود.\u003C\u002Fli>\n\u003Cli>پیش‌نمایش تصاویر و فایل‌های PDF دیر ساخته می‌شوند یا اصلاً ساخته نمی‌شوند.\u003C\u002Fli>\n\u003Cli>فایل‌های حذف‌شده مدت زیادی در Trash می‌مانند و سیاست نگه‌داری اعمال نمی‌شود.\u003C\u002Fli>\n\u003Cli>در محیط‌های شلوغ، صف کارهای پس‌زمینه طولانی می‌شود و \u003Ccode>occ background-job:list\u003C\u002Fcode> جاب‌هایی با زمان اجرای گذشته نشان می‌دهد.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>اگر همان دستوری را که در crontab گذاشته‌اید، دستی روی هاست اجرا کنید، ممکن است خروجی زیر را ببینید:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">Could not open input file: \u002Fvar\u002Fwww\u002Fhtml\u002Fcron.php\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>این خطا کل ماجرا را لو می‌دهد. مسیر \u003Ccode>\u002Fvar\u002Fwww\u002Fhtml\u002Fcron.php\u003C\u002Fcode> داخل کانتینر Nextcloud وجود دارد، نه روی فایل‌سیستم هاست. اگر خروجی کران را با \u003Ccode>>\u002Fdev\u002Fnull 2>&1\u003C\u002Fcode> خاموش کرده باشید، این خطا هیچ‌جا ثبت نمی‌شود و فقط هشدار ادمین باقی می‌ماند.\u003C\u002Fp>\n\u003Ch2 id=\"علت-ریشه‌ای\">علت ریشه‌ای\u003C\u002Fh2>\n\u003Cp>سه لایه باعث این رفتار می‌شود:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>مرز کانتینر:\u003C\u002Fstrong> کران روی هاست اجرا می‌شود، ولی فایل \u003Ccode>cron.php\u003C\u002Fcode> داخل ایمیج Nextcloud است. دستور \u003Ccode>php \u002Fvar\u002Fwww\u002Fhtml\u002Fcron.php\u003C\u002Fcode> روی هاست به فایلی اشاره می‌کند که وجود ندارد. باید از \u003Ccode>docker exec\u003C\u002Fcode> استفاده کنید تا دستور داخل کانتینر اجرا شود.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>کاربر اشتباه:\u003C\u002Fstrong> حتی وقتی از \u003Ccode>docker exec\u003C\u002Fcode> استفاده می‌کنید، اگر \u003Ccode>-u www-data\u003C\u002Fcode> را نزنید، کران با کاربر root داخل کانتینر اجرا می‌شود. Nextcloud فایل‌هایی مثل لاگ‌ها، previewها و appdata را با مالک root می‌سازد و بعداً کاربر وب (www-data) نمی‌تواند آن‌ها را بنویسد. این وضعیت می‌تواند به خطاهای آپلود و «Cannot write to appdata» منجر شود.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>حالت AJAX یا webcron:\u003C\u002Fstrong> Nextcloud چند حالت برای background job دارد. در حالت \u003Ccode>ajax\u003C\u002Fcode>، جاب‌ها فقط وقتی اجرا می‌شوند که کاربر صفحه‌ای باز کند. روی سروری که کم‌ترافیک است یا بیشتر با API و WebDAV کار می‌کند، این حالت قابل اتکا نیست. حالت \u003Ccode>webcron\u003C\u002Fcode> هم به یک سرویس بیرونی نیاز دارد که مرتب \u003Ccode>\u002Fcron.php\u003C\u002Fcode> را صدا بزند و در عمل کمتر درست پیکربندی می‌شود.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"راه‌حل-گام‌به‌گام\">راه‌حل گام‌به‌گام\u003C\u002Fh2>\n\u003Ch3 id=\"۱-نام-کانتینر-و-حالت-فعلی-را-ببینید\">۱. نام کانتینر و حالت فعلی را ببینید\u003C\u002Fh3>\n\u003Cp>در دستورهای این مقاله نام کانتینر را \u003Ccode>nextcloud\u003C\u002Fcode> گذاشته‌ام. اگر نام دیگری دارید، همان را جایگزین کنید. اول ببینید کانتینر در حال اجراست و بعد حالت background job را بخوانید:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">docker ps\ndocker exec -u www-data nextcloud php occ config:app:get core backgroundjobs_mode\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر خروجی \u003Ccode>ajax\u003C\u002Fcode> یا \u003Ccode>webcron\u003C\u002Fcode> بود، همان مشکل اصلی است. اگر \u003Ccode>cron\u003C\u002Fcode> بود، یعنی حالت درست است ولی کران اجرا نمی‌شود یا خطا می‌دهد.\u003C\u002Fp>\n\u003Ch3 id=\"۲-حالت-را-روی-cron-بگذارید\">۲. حالت را روی cron بگذارید\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-bash\">docker exec -u www-data nextcloud php occ background:cron\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>بعد از اجرا دوباره دستور \u003Ccode>occ config:app:get core backgroundjobs_mode\u003C\u002Fcode> را بزنید و مطمئن شوید خروجی \u003Ccode>cron\u003C\u002Fcode> است. این تغییر فقط حالت را تنظیم می‌کند؛ هنوز باید کران واقعی روی هاست یا داخل کانتینر اجرا شود.\u003C\u002Fp>\n\u003Ch3 id=\"۳-قبل-از-تنظیم-کران-دستی-تست-کنید\">۳. قبل از تنظیم کران، دستی تست کنید\u003C\u002Fh3>\n\u003Cp>این مرحله مهم است. اگر دستور زیر بدون خروجی و با کد ۰ تمام شود، یعنی مسیر، کاربر و دسترسی‌ها درست است:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">docker exec -u www-data nextcloud php -f \u002Fvar\u002Fwww\u002Fhtml\u002Fcron.php\necho $?\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر خطای \u003Ccode>Could not open input file\u003C\u002Fcode> گرفتید، نام کانتینر یا مسیر فایل اشتباه است. اگر خطای \u003Ccode>Permission denied\u003C\u002Fcode> گرفتید، کاربر اجرا یا مالکیت فایل‌ها مشکل دارد. اگر قبلاً کران را با root اجرا کرده‌اید، مالکیت data directory را برگردانید؛ مسیر را با مسیر واقعی data خودتان عوض کنید:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">docker exec -u root nextcloud chown -R www-data:www-data \u002Fvar\u002Fwww\u002Fhtml\u002Fdata\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3 id=\"۴-خط-کران-را-روی-هاست-اضافه-کنید\">۴. خط کران را روی هاست اضافه کنید\u003C\u002Fh3>\n\u003Cp>با کاربر root وارد crontab شوید:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">sudo crontab -u root -e\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>این خط را اضافه کنید:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">*\u002F5 * * * * \u002Fusr\u002Fbin\u002Fdocker exec -u www-data nextcloud php -f \u002Fvar\u002Fwww\u002Fhtml\u002Fcron.php >>\u002Fvar\u002Flog\u002Fnextcloud-cron.log 2>&1\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>چند نکته:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>مسیر \u003Ccode>\u002Fusr\u002Fbin\u002Fdocker\u003C\u002Fcode> را با خروجی \u003Ccode>command -v docker\u003C\u002Fcode> روی هاست خودتان تطبیق دهید.\u003C\u002Fli>\n\u003Cli>نام \u003Ccode>nextcloud\u003C\u002Fcode> را با نام واقعی کانتینر عوض کنید.\u003C\u002Fli>\n\u003Cli>در کران از \u003Ccode>-it\u003C\u002Fcode> استفاده نکنید؛ کران TTY ندارد و \u003Ccode>docker exec -it\u003C\u002Fcode> ممکن است با خطای «the input device is not a TTY» شکست بخورد.\u003C\u002Fli>\n\u003Cli>خروجی را به \u003Ccode>\u002Fdev\u002Fnull\u003C\u002Fcode> نفرستید. همین کار باعث می‌شود خطاهایی مثل نبودن فایل یا Permission denied ماه‌ها مخفی بمانند.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>اگر از Docker Compose استفاده می‌کنید، خط کران می‌تواند این شکل باشد. توجه کنید که \u003Ccode>-T\u003C\u002Fcode> برای غیرفعال کردن TTY لازم است و نام سرویس \u003Ccode>app\u003C\u002Fcode> را با نام سرویس خودتان عوض کنید:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">*\u002F5 * * * * cd \u002Fopt\u002Fnextcloud && \u002Fusr\u002Fbin\u002Fdocker compose exec -T -u www-data app php -f \u002Fvar\u002Fwww\u002Fhtml\u002Fcron.php >>\u002Fvar\u002Flog\u002Fnextcloud-cron.log 2>&1\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3 id=\"۵-لاگ-را-بررسی-کنید\">۵. لاگ را بررسی کنید\u003C\u002Fh3>\n\u003Cp>بعد از چند دقیقه لاگ را ببینید:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">sudo tail -n 20 \u002Fvar\u002Flog\u002Fnextcloud-cron.log\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر هیچ خطایی نبینید، خوب است؛ \u003Ccode>cron.php\u003C\u002Fcode> در حالت موفق معمولاً خروجی تولید نمی‌کند. اگر خطای \u003Ccode>Could not open input file\u003C\u002Fcode> یا \u003Ccode>Permission denied\u003C\u002Fcode> دیدید، به مرحله قبل برگردید. برای اطمینان بیشتر، همان دستور داخل کران را یک بار دستی در shell اجرا کنید و کد خروج را ببینید.\u003C\u002Fp>\n\u003Ch2 id=\"چطور-مطمئن-شویم-مشکل-واقعا-حل-شده-است\">چطور مطمئن شویم مشکل واقعاً حل شده است\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>دستور دستی \u003Ccode>docker exec -u www-data nextcloud php -f \u002Fvar\u002Fwww\u002Fhtml\u002Fcron.php\u003C\u002Fcode> با کد خروج ۰ تمام می‌شود.\u003C\u002Fli>\n\u003Cli>خروجی \u003Ccode>occ config:app:get core backgroundjobs_mode\u003C\u002Fcode> برابر \u003Ccode>cron\u003C\u002Fcode> است.\u003C\u002Fli>\n\u003Cli>پس از ۵ تا ۱۰ دقیقه، هشدار «Last background job execution ran ...» در پنل ادمین پاک می‌شود یا زمان آن به‌روز می‌شود.\u003C\u002Fli>\n\u003Cli>در خروجی \u003Ccode>docker exec -u www-data nextcloud php occ background-job:list\u003C\u002Fcode>، ستون آخرین اجرا (last run) برای جاب‌های دوره‌ای به‌روز شده است و جاب‌ها با next run در گذشته انبار نمی‌شوند.\u003C\u002Fli>\n\u003Cli>لاگ \u003Ccode>\u002Fvar\u002Flog\u002Fnextcloud-cron.log\u003C\u002Fcode> بعد از چند چرخه خطای جدیدی ندارد.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>اگر هشدار باقی ماند، اول مطمئن شوید کران روی هاست واقعاً اجرا می‌شود. با \u003Ccode>crontab -l -u root\u003C\u002Fcode> خط را ببینید و یک بار همان دستور را بدون redirect اجرا کنید. سپس بررسی کنید کانتینر با همین نام در حال اجراست و بعد از ری‌استارت‌ها نامش عوض نشده است.\u003C\u002Fp>\n\u003Ch2 id=\"پیشگیری-و-بهترین-روش‌ها\">پیشگیری و بهترین روش‌ها\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>در محیط production همیشه حالت background job را \u003Ccode>cron\u003C\u002Fcode> بگذارید. AJAX برای نصب‌های کوچک و کم‌ترافیک است و برای سرور واقعی قابل اتکا نیست.\u003C\u002Fli>\n\u003Cli>کران Nextcloud را با کاربر \u003Ccode>www-data\u003C\u002Fcode> اجرا کنید، نه root. این کار از مالکیت نادرست فایل‌ها و خطاهای بعدی جلوگیری می‌کند.\u003C\u002Fli>\n\u003Cli>خروجی کران را ذخیره کنید. اگر نمی‌خواهید لاگ دائمی داشته باشید، حداقل از \u003Ccode>logger\u003C\u002Fcode> استفاده کنید تا خطا در syslog دیده شود.\u003C\u002Fli>\n\u003Cli>از نام ثابت کانتینر یا نام سرویس Compose استفاده کنید. اگر کانتینر را با نام تصادفی بالا می‌آورید، کران بعد از هر بازسازی می‌شکند.\u003C\u002Fli>\n\u003Cli>بعد از هر آپدیت Nextcloud یا تغییر ایمیج، اجرای دستی \u003Ccode>cron.php\u003C\u002Fcode> و وضعیت هشدار ادمین را دوباره چک کنید.\u003C\u002Fli>\n\u003Cli>برای لاگ کران logrotate تنظیم کنید تا فایل لاگ در بلندمدت دیسک را پر نکند.\u003C\u002Fli>\n\u003Cli>در \u003Ca href=\"\u002Fservices\u002Fkubernetes\">Kubernetes\u003C\u002Fa> به‌جای کران هاست، یک CronJob با ایمیج Nextcloud و همان volume داده بسازید و دستور \u003Ccode>php -f \u002Fvar\u002Fwww\u002Fhtml\u002Fcron.php\u003C\u002Fcode> را با کاربر \u003Ccode>www-data\u003C\u002Fcode> اجرا کنید.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>جمع‌بندی ساده است: Nextcloud در Docker به کرانی نیاز دارد که داخل همان کانتینر و با همان کاربر وب اجرا شود. اگر خط کران را از روی مستندات کپی کرده‌اید ولی مسیر را روی هاست اجرا می‌کنید، فقط هشدار ادمین را جا گذاشته‌اید. با یک \u003Ccode>docker exec -u www-data\u003C\u002Fcode> و ثبت خروجی، هم مشکل را پیدا می‌کنید و هم از تکرارش جلوگیری می‌کنید.\u003C\u002Fp>",[31,35,38,41,45,48,51,54,57,60],{"id":32,"text":33,"level":34},"نشانه‌ها-چه-چیزی-واقعا-دیده-می‌شود","نشانه‌ها؛ چه چیزی واقعاً دیده می‌شود",2,{"id":36,"text":37,"level":34},"علت-ریشه‌ای","علت ریشه‌ای",{"id":39,"text":40,"level":34},"راه‌حل-گام‌به‌گام","راه‌حل گام‌به‌گام",{"id":42,"text":43,"level":44},"۱-نام-کانتینر-و-حالت-فعلی-را-ببینید","۱. نام کانتینر و حالت فعلی را ببینید",3,{"id":46,"text":47,"level":44},"۲-حالت-را-روی-cron-بگذارید","۲. حالت را روی cron بگذارید",{"id":49,"text":50,"level":44},"۳-قبل-از-تنظیم-کران-دستی-تست-کنید","۳. قبل از تنظیم کران، دستی تست کنید",{"id":52,"text":53,"level":44},"۴-خط-کران-را-روی-هاست-اضافه-کنید","۴. خط کران را روی هاست اضافه کنید",{"id":55,"text":56,"level":44},"۵-لاگ-را-بررسی-کنید","۵. لاگ را بررسی کنید",{"id":58,"text":59,"level":34},"چطور-مطمئن-شویم-مشکل-واقعا-حل-شده-است","چطور مطمئن شویم مشکل واقعاً حل شده است",{"id":61,"text":62,"level":34},"پیشگیری-و-بهترین-روش‌ها","پیشگیری و بهترین روش‌ها",[64,66,69,71,74],{"name":65,"slug":65},"docker",{"name":67,"slug":68},"Nextcloud","nextcloud",{"name":70,"slug":13},"Self-Hosted",{"name":72,"slug":73},"Cron","cron",{"name":75,"slug":76},"Background Jobs","background-jobs",[78,81,84],{"question":79,"answer":80},"آیا می‌توانم cron.php را با کاربر root داخل کانتینر اجرا کنم؟","نه. اجرای cron.php با root باعث می‌شود فایل‌های appdata، لاگ‌ها و previewها با مالک root ساخته شوند و بعداً www-data نتواند آن‌ها را بنویسد. همیشه از -u www-data استفاده کنید.",{"question":82,"answer":83},"چرا با وجود این که هر ۵ دقیقه کران را تنظیم کرده‌ام، هشدار Nextcloud باقی است؟","معمولاً خروجی کران را به \u002Fdev\u002Fnull فرستاده‌اید و خطایی مثل Could not open input file یا Permission denied دیده نمی‌شود. نام کانتینر، مسیر cron.php، کاربر اجرا و حالت background:cron را دوباره بررسی کنید.",{"question":85,"answer":86},"آیا حالت AJAX برای Nextcloud کافی نیست؟","برای نصب‌های کوچک و کم‌ترافیک ممکن است کار کند، ولی قابل اتکا نیست. جاب‌های پس‌زمینه فقط با باز شدن صفحه اجرا می‌شوند و روی سرورهای production یا محیط‌هایی که بیشتر با API کار می‌کنند، صف جاب‌ها عقب می‌افتد.",[88,89,90],"nextcloud-self-hosted","managed-devops","performance-cost-optimization",true,"رفع هشدار Last background job execution در Nextcloud Docker با اجرای cron.php داخل کانتینر، کاربر www-data و تنظیم occ background:cron.",[94,106,119],{"id":95,"title":96,"slug":97,"excerpt":98,"cover":99,"category":101,"author":102,"track":103,"level":104,"reading_minutes":26,"is_featured":27,"published_at":105,"updated_at":105},41,"ایمیل تحویل داده می‌شود ولی Inbox خالی است؛ تله‌ی mail_location","postfix-dovecot-mail-location-empty-inbox","ایمیل در لاگ Postfix «تحویل داده» می‌شود اما کاربر هنگام اتصال IMAP صندوق خالی می‌بیند. علت رایج، اختلاف مسیر تحویل میان Postfix و mail_location در Dovecot است.",{"url":100,"alt":96},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F48b5cdce-7a37-4e0d-af2d-4a25bbafd20f.webp",{"name":12,"slug":13},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},"2026-11-12T06:14:11+00:00",{"id":107,"title":108,"slug":109,"excerpt":110,"cover":111,"category":113,"author":114,"track":115,"level":116,"reading_minutes":117,"is_featured":27,"published_at":118,"updated_at":118},13,"رفع خطای no SASL authentication mechanisms در Postfix","postfix-dovecot-sasl-auth-socket-chroot","وقتی smtpd پورت ۵۸۷ با خطای «no SASL authentication mechanisms» بالا نمی‌آید، ریشه معمولاً سوکت Dovecot است که داخل chroot پست‌فیکس ساخته نشده. این مقاله علت و راه‌حل کامل را قدم‌به‌قدم بررسی می‌کند.",{"url":112,"alt":108},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002Ffb649a07-b046-4b39-a1f9-84734bc4883e.webp",{"name":12,"slug":13},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},6,"2026-10-15T13:00:17+00:00",{"id":120,"title":121,"slug":122,"excerpt":123,"cover":124,"category":126,"author":127,"track":128,"level":129,"reading_minutes":117,"is_featured":27,"published_at":130,"updated_at":130},8,"رفع dkim=none در Postfix با راه‌اندازی OpenDKIM","postfix-opendkim-dkim-signing-fix","اگر ایمیل‌های سرور Postfix شما در Gmail به اسپم می‌روند و هدر پیام dkim=none نشان می‌دهد، یعنی هیچ امضای DKIM روی پیام‌ها درج نمی‌شود. در این مقاله OpenDKIM را نصب، پیکربندی و به Postfix وصل می‌کنیم و رکورد DNS را منتشر می‌کنیم.",{"url":125,"alt":121},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F1b1288db-c0ed-41f3-8ee5-01f7b997c11d.webp",{"name":12,"slug":13},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},"2026-10-09T13:30:31+00:00"]