İlk Teşhis: Günlükleri (Log) ve Servis Durumunu Kontrol Edin

1. Plesk arayüzü erişilemiyorsa, sunucuya SSH ile bağlanın ve MariaDB/MySQL durumuna bakın:

   systemctl status mariadb
journalctl -u mariadb -n 200 --no-pager


   (Windows’ta Olay Görüntüleyici ve Plesk SQL Server servisini kontrol edin.) support.plesk.com

2. Geçmiş boot loglarını inceleyin (özellikle beklenmedik yeniden başlatma sonrası):

   journalctl --boot=-1 -n 5000


   (Forumda doğrulanan pratik bir yaklaşım.) Plesk Forum

3. Disk doluluk:

   df -h
du -sh /var/lib/mysql/* | sort -h


   Diskin dolması, MySQL’in başlamasını engeller ve 500 hatasına yol açar. Plesk Forum

Hızlı Onarım: Plesk Repair Utility (Önerilen)

Çalıştırın:

Bu komut Plesk veritabanı tutarlılığını denetler, gerekirse otomatik yedek (dump) alır ve onarım dener. Linux/Windows’ta kullanılabilir. Ek seçenek gerekmez. docs.plesk.com+2plesk.com+2

Not – Geçici 500 Hatası: plesk repair installation gibi geniş onarım çalışırken Plesk kısa süre erişilemez ve 500 hatası görülebilir; bu, bilinen bir Repair Kit davranışı/bug’ıdır ve işlem bitince kaybolur. support.plesk.com

Senaryo A: SQLSTATE[HY000][2002] Connection refused

Belirti:

Neden: MariaDB/MySQL servisinin down olması veya başlayamaması.
Çözüm:

1. Servisi başlatın/yeniden başlatın:

   systemctl restart mariadb
systemctl status mariadb


2. Loglardaki temel sebebi giderin (ör. yapılandırma, port çakışması, izinler).

3. Ardından plesk repair db çalıştırın.
   Kaynak ve aynı hatanın resmi analizi: support.plesk.com

Senaryo B: SQLSTATE[HY000][2002] No such file or directory

Belirti:

Neden: MySQL socket dosyası yok/yanlış yol, servis kapalı veya disk taşması sonucunda soket oluşmuyor.
Çözüm:

1. Servisi yeniden başlatın; /etc/my.cnf içindeki socket yolunu ve /var/lib/mysql/mysql.sock varlığını doğrulayın.

2. Disk doluysa alan açın (bkz. Senaryo D).

3. Gerekirse /tmp izinlerini ve AppArmor/SELinux kısıtlarını kontrol edin.
   Doğrulama: Plesk Forum+1

Senaryo C: Plesk SQL Server Error 1053 (Windows) / Port Çakışması

Belirti: 1053; Event Viewer’da “Bind on TCP/IP port 3306… already in use”.
Neden: Plesk SQL Server servis yapılandırması hatalı ya da 3306 portunu başka bir mysqld kullanıyor.
Çözüm:

1. Hizmetin “Path to executable” ayarını doğru my.ini bilgisiyle güncelleyin.

2. Port çakışması varsa bağlanan diğer MySQL örneğini kapatın/portu değiştirin.
   Kaynak: support.plesk.com

Senaryo D: Disk Dolu (No space left on device)

Belirti: MySQL başlatılamıyor; günlüklerde “No space left on device”.
Çözüm:

1. df -h ile dolu diskleri tespit edin, gereksiz log/backupları temizleyin.

2. MariaDB’yi yeniden başlatın, ardından plesk repair db.
   Resmi Plesk çözüm makalesi: Plesk Forum

Senaryo E: Bozulmuş Plesk Sistem Veritabanları (psa vb.)

Belirti: psa tabloları “crashed”/tutarsız; Plesk arayüzü 500 veriyor.
Çözüm (önce yedek alın):

1. Repair Utility:

   plesk repair db


2. Gerekirse günlük yedekten geri yükleme (Plesk’in otomatik dump’ları):
   Plesk günlük/pre-upgrade dump’tan psa’yı geri yükleme adımları resmi rehberde anlatılır. (Örnek komutlar ve değiştirme notları rehberde mevcut.) plesk.com

3. Alternatif CLI restore notları (ilerseviye): dump’tan apsc/psa geri yükleme pratikleri. (Topluluk deneyimi; dikkatle uygulayın.) The WP Guru

Uyarı: Manuel mysqlcheck --repair veya innodb_force_recovery gibi adımlar verinizi riske sokabilir; önce resmi repair ve resmi geri yükleme yollarını deneyin. docs.plesk.com+1

Senaryo F: Geçici — Repair Çalışırken Plesk İnaccessible

Belirti: plesk repair installation sırasında panel 500 hatası döner.
Çözüm: İşlem tamamlanınca düzelir; bilinen bir davranış/bug kaydı mevcuttur. support.plesk.com

Senaryo G: Eksik/Silinmiş Dosya veya Antivirüs Karantinası (Windows)

Belirti: “500 Internal Server Error – Failed opening required …”
Çözüm: Eksik dosyayı aynı sürüm çalışan bir Plesk’ten geri getirin; antivirüse %plesk_dir% için istisna ekleyin. support.plesk.com

Adım Adım Standart Düzeltme Akışı (Önerilen Playbook)

1. Servisleri kontrol et: systemctl status mariadb → hata varsa log oku. support.plesk.com

2. Disk alanı: df -h → doluysa temizle. Plesk Forum

3. Repair Utility çalıştır: plesk repair db (Linux/Windows). docs.plesk.com+1

4. Socket/Port doğrula: mysql.sock yolu ve 3306 çakışması. (Windows’ta hizmet yapılandırması.) support.plesk.com+1

5. Hâlâ sorun var mı? Plesk sistem DB’lerini dump’tan geri yükle (örn. psa). plesk.com

6. Geçici 500 mi? Repair esnasında oluştuysa görmezden gelebilirsiniz; işlem bitince panel geri gelir. support.plesk.com

SSS

Bu hata neden “genel” gözüküyor?
“500 Plesk\Exception\Database” şemsiye bir hatadır; somut sebep loglarda çıkar. Plesk Forum

Plesk’te veritabanını GUI’den de onarabilir miyim?
Evet; “Websites & Domains → Databases → Check and Repair”. (Sürümünüze göre görünüm değişebilir.) lets-rebuild.com

Repair sırasında 500 görürsem?
Bu beklenen bir davranış olabilir; repair bitince panel geri gelir (EXTPLESK-3451). support.plesk.com

İleri Düzey Notlar ve İpuçları

• Komutları üretimde uygulamadan önce snapshot/backup alın.

• Plesk Repair Utility, tutarsızlık bulursa otomatik dump alıp onarım dener; bu nedenle ilk başvuru aracınız olmalı. docs.plesk.com

• Hata No such file or directory ise socket yolunu ve /tmp izinlerini kontrol edin; Connection refused ise servis gerçekten çalışmıyor demektir. support.plesk.com+1

İlk 5 Dakikalık Teşhis

1. Hata kayıtları: cPanel: Metrics → Errors; Plesk: alan adında Logs; CWP: HTTPD/Nginx, PHP, AutoSSL ve servis log’ları.
2. DNS kontrolü: A/AAAA, MX, TXT (SPF/DKIM/DMARC)
3. SSL/AutoSSL: Let’s Encrypt’i yenile; 80/TCP erişilebilir olmalı (HTTP-01 doğrulaması).
4. PHP limitleri: upload_max_filesize + post_max_size + max_execution_time
5. Mail teslimi: SPF/DKIM/DMARC + rDNS(PTR)

DNS / Alan Adı Hataları

Belirti: Site bazı bölgelerde açılıyor/hiç açılmıyor, e-postalar gelmiyor.

Panel yolları: cPanel: Domains → Zone Editor; Plesk: Websites & Domains → DNS Settings; CWP: DNS Functions.

dig +short example.com A
dig +short example.com AAAA
dig +short example.com MX
dig +short NS example.com

Not: NS değişiminde TTL/propagasyon 24–48 saat sürebilir.

SSL/TLS (HTTPS) ve AutoSSL

Belirti: “Not secure”, “expired”, “hostname mismatch”, LE başarısız.
Kritik: Let’s Encrypt HTTP-01 yalnızca 80/TCP’ten doğrular.

• cPanel/WHM: AutoSSL (sağlayıcı: Let’s Encrypt)
• Plesk: Let’s Encrypt / SSL It! (site + mail + Plesk arayüzü)
• CWP: Loglar → /var/log/cwp/autossl.log, /root/.acme.sh/acme.sh.log

Öneri: HTTP→HTTPS yönlendirmesi kalsın; fakat .well-known/acme-challenge dosyalarına 80’den erişim bozulmasın.

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Web Sunucusu & Uygulama Hataları (500/502/503/504)

İzlenecek yol: cPanel Errors → ip

Hata Nasıl Görünür?

Sunucu Sorunu: STATUS: Internal error occurred. Refer to server log for more information.
(host linux.saviorhost.com[private/dovecot-lmtp] said: 451 4.2.0 Internal error occurred (in reply to end of DATA command))

Bu mesaj, Postfix’in Dovecot LMTP’ye mesajı teslim etmeye çalıştığını, ancak Dovecot’un “internal error” ile yanıt verdiğini gösterir.

Olası Nedenler

• Mailbox izin ya da bozulma: Maildir dizini sahiplik / izin hataları veya bozuk indekler.
• Disk doluluğu ya da kota problemi: Mesaj teslim edilemiyor çünkü yeterli alan yok.
• LMTP / Postfix entegrasyon hatası: Dovecot’un `private/dovecot-lmtp` soketi ya da `mailbox_transport` tanımı yanlış.
• Roundcube SMTP ayarları tutarsız: Yanlış SMTP sunucusu, port ya da bağlantı türü.

Adım Adım Çözüm Rehberi

1. Logları İnceleyin

sudo tail -n 200 /var/log/dovecot.log
sudo tail -n 200 /var/log/maillog
sudo journalctl -u dovecot -u postfix --since "today"

Loglar, hatanın tam nedenini “Permission denied”, “No space left on device”, “lmtp” gibi ifadeleri içererek gösterir.

2. Mailbox İzin/Sahiplik Kontrolü & Onarımı

sudo ls -ld /home/vmail/example.com/iletisim
sudo chown -R vmail:vmail /home/vmail/example.com/iletisim
sudo chmod -R 700 /home/vmail/example.com/iletisim

# Bozuk kutuları yeniden senkronize et
sudo doveadm force-resync -u iletisim@example.com INBOX
sudo doveadm force-resync -u iletisim@example.com '*'

3. Disk Alanı ve Kota Kontrolü

df -h
sudo du -xh /var /home | sort -h | tail -n 20

Kota ya da depolama limiti aşıldıysa, gereksiz dosyaları temizleyin veya kullanıcı kotasını artırın.

4. Postfix → Dovecot LMTP Yapılandırması

Postfix (main.cf):

mailbox_transport = lmtp:unix:private/dovecot-lmtp

Dovecot (10-master.conf):

service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
  process_min_avail = 5
}
protocol lmtp {
  # lmtp_rcpt_check_quota = yes  (Gerekirse aktif edin)
}

5. Roundcube SMTP Ayarları

6. Servisleri Yeniden Başlatın & Test Edin

sudo systemctl restart dovecot
sudo systemctl restart postfix

# Kuyrukta bekleyen mailleri kontrol et
postqueue -p

# Logları yeniden izleyin
sudo tail -n 100 /var/log/maillog

Kontrol Listesi

• Loglarda ilgili saat/dakika ile hata satırlarını buldum.
• Mailbox izinleri (`vmail:vmail`, `700`) doğru.
• Disk alanı/kota kontrolü yapıldı, sorun yok.
• Postfix → LMTP yapılandırması uygun.
• Roundcube SMTP ayarları doğrulandı.
• Gerekirse `doveadm force-resync` ile onarım yapıldı.

SSS – Kısa Sorular & Yanıtlar

“451 4.2.0 neden geçici hata?”

4.x kodları SMTP protokolünde “geçici” hatadır. Sorun giderilirse mail yeniden teslim edilebilir.

Sadece bir kullanıcıda mı hata var?

Muhtemelen o kullanıcının mailbox’ında bozulma ya da izin sorunu vardır. Onarıp tekrar test edin.

Sonuç

“451 4.2.0 Internal Error Occurred (LMTP)” hatası genellikle **izin, LMTP entegrasyonu veya posta kutusu bozulması** kaynaklıdır. Yukarıdaki rehberi adım adım uygulayarak sorunu kalıcı şekilde çözebilirsiniz. Her adımda logları takip etmeyi unutmayın.

Kaynaklar

• Dovecot – Postfix LMTP Entegrasyonu
• Doveadm Force-Resync Komutu
• Dovecot Quota / Kota Eklentisi
• Roundcube Yapılandırma Rehberi