Bugsink: https://bugsink.cytrus.de/issues/issue/f37d37c9-e29a-4a1a-96f2-22afa4d03cd5/event/last/

Typ: NEW issue

Projekt: www-verl-de

Bugsink Alert

ErrorException: Warning: filesize(): stat failed for /srv/www/www.verl.de/pages/public/uploads/tx_powermail/kizivlmtlh

Automatisch erstellt durch n8n

KI-Analyse:

Analyse: filesize(): stat failed für Powermail Upload¶

1. Ursache¶

PHPs filesize() schlägt mit stat failed fehl, weil die Datei /srv/www/www.verl.de/pages/public/uploads/tx_powermail/kizivlmtlh nicht (mehr) existiert oder nicht lesbar ist. Im Powermail-Kontext deutet der Pfad und Dateiname (kizivlmtlh ohne Extension) klar auf einen Dateiupload im Powermail-Formular hin:

• Dateien landen in uploads/tx_powermail/ mit temporären, generierten Namen.
• Wenn zwischen Upload-Phase (Frontend) und Verarbeitung/Validierung (Backend/Mail-Versand) die Datei verschoben, gelöscht oder nie korrekt geschrieben wurde, schlägt filesize() fehl.

Wahrscheinlichste konkrete Ursache:
Das Upload-Feld in Powermail versucht im AfterUpload- / Mail-Dispatch-Schritt die Dateigröße zu bestimmen, bekommt aber einen verwaisten oder geleerten Pfad. Häufige Auslöser:

• Upload schlug im Browser/Server still fehl (zu groß, PHP-Limit, upload_tmp_dir voll)
• Datei wurde bereits durch eine vorherige Validierungs- oder Hook-Operation verschoben/umbenannt
• Pfad wird doppelt verarbeitet oder enthält einen Fehler bei der Zusammensetzung (getUploadPath() o.ä.)
• $_FILES Referenz existiert, aber das TMP-Verzeichnis wurde zwischenzeitlich aufgeräumt

2. Fix (konkret)¶

Sofortmaßnahmen:

1. Upload-Verzeichnis prüfen:

   ls -la /srv/www/www.verl.de/pages/public/uploads/tx_powermail/
   

   Existiert das Verzeichnis? Sind Schreibrechte für den PHP-FPM-User vorhanden?

2. PHP-Upload-Limits prüfen (php.ini / FPM-Pool):

   upload_max_filesize = 50M
   post_max_size       = 50M
   max_file_uploads    = 20
   upload_tmp_dir      = /tmp  ; oder eigener Pfad, beschreibbar
   

   Außerdem: Disk-Quota, open_basedir (darf das TMP-Verzeichnis lesen?).

3. Powermail-spezifischer Fix – den filesize()-Aufruf absichern. In einem Hook oder XClass:

   // Statt:
   $size = filesize($uploadedFilePath);
   
   // Besser:
   if (is_file($uploadedFilePath) && is_readable($uploadedFilePath)) {
       $size = filesize($uploadedFilePath);
   } else {
       // Logging + sauberes Fehlerhandling
       $logger = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(
           \Psr\Log\LoggerInterface::class
       );
       $logger->warning('Powermail upload missing', ['path' => $uploadedFilePath]);
       $size = 0;
   }
   

4. Debug-Hook in ext_localconf.php einer eigenen Extension, um den Pfad zu loggen:

   $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['powermail']['clearCacheAfterMailUpload'][] = function($marker, $request) {
       \TYPO3\CMS\Core\Utility\DebugUtility::var_dump($marker->getUploads());
   };
   

3. Betroffene Extension¶

in2code/powermail (Powermail) – einer der Standard-Formularextensions in TYPO3 v11/v12.

Der Stacktrace zeigt nur Core-HTTP-Middleware, weil der Fehler während des Request-Lifecycle auftritt – das eigentliche filesize() liegt in einer Closure / einem Hook innerhalb von Powermail (vermutlich Utility\BasicFileUtility, Domain\Service\UploadService bzw. im SendingEmailService).

4. Confidence¶

75 %

• Hoch: Pfad-Konvention tx_powermail/ ist eindeutig Powermail.
• Mittel: Genaue Code-Stelle (welcher Hook/Service) ist ohne tieferen Stacktrace / Logfile mit File+Line nur eingrenzbar, nicht sicher.
• Fehlender tieferer Call-Stack (Frames abbrechen in der Middleware) – der filesize()-Call liegt wahrscheinlich in einem Hook, der erst nachfolgend im Response-Build geloggt wurde. Für präzisen Patch: vollständigen Stacktrace holen (z. B. via error_log / Sentry / [SYS][displayErrors] = 1).