SFTP-Datei schreibt nicht auf die Festplatte

Ich habe SFTP auf einer aws-ec2-Instanz eingerichtet. Ein Client, der jeden Abend eine 20 MB - 30 MB-Datei überträgt. Etwa die Hälfte der Zeit funktioniert die Übertragung nicht und ich kann nicht verstehen, warum. Ich habe es von verschiedenen Kunden ausprobiert und habe noch nie gesehen, dass es nicht funktioniert. Heute war ich auf dem Server, während die Dateiübertragung stattfand, und ich habe die Protokolle live beobachtet. Hier ist ein Beispiel der Ausgabe:

Aug 17 09:01:19 internal-sftp[16260]: session opened for local user someuser from [55.66.77.88] Aug 17 09:01:19 internal-sftp[16260]: received client version 4 Aug 17 09:01:19 internal-sftp[16260]: realpath "." Aug 17 09:01:19 internal-sftp[16260]: debug1: request 3294: sent names count 1 Aug 17 09:01:19 internal-sftp[16260]: opendir "/somedir" Aug 17 09:01:19 internal-sftp[16260]: debug1: request 1110: sent handle handle 0 Aug 17 09:01:19 internal-sftp[16260]: debug1: request 3021: readdir "/somedir" (handle 0) Aug 17 09:01:19 internal-sftp[16260]: debug1: request 3021: sent names count 3 Aug 17 09:01:19 internal-sftp[16260]: debug1: request 3021: readdir "/somedir" (handle 0) Aug 17 09:01:19 internal-sftp[16260]: sent status End of file Aug 17 09:01:20 internal-sftp[16260]: closedir "/somedir" Aug 17 09:01:20 internal-sftp[16260]: sent status Success Aug 17 09:01:20 internal-sftp[16260]: open "/somedir/thefile.zip" flags WRITE,CREATE,TRUNCATE mode 0666 Aug 17 09:01:20 internal-sftp[16260]: debug1: request 1383: sent handle handle 0 Aug 17 09:01:20 internal-sftp[16260]: debug1: request 1234: write "/somedir/thefile.zip" (handle 0) off 0 len 32739 Aug 17 09:01:20 internal-sftp[16260]: sent status Success Aug 17 09:01:20 internal-sftp[16260]: debug1: request 1234: write "/somedir/thefile.zip" (handle 0) off 32739 len 32739 Aug 17 09:01:20 internal-sftp[16260]: sent status Success (more of the same...) Aug 17 09:01:54 internal-sftp[16260]: debug1: request 1234: write "/somedir/thefile.zip" (handle 0) off 27238848 len 10072 Aug 17 09:01:55 internal-sftp[16260]: sent status Success Aug 17 09:01:55 internal-sftp[16260]: close "/somedir/thefile.zip" bytes read 0 written 27248920 Aug 17 09:01:55 internal-sftp[16260]: sent status No such file Aug 17 09:01:55 internal-sftp[16260]: debug1: read eof Aug 17 09:01:55 internal-sftp[16260]: session closed for local user someuser from [55.66.77.88] 

Wenn Sie diese Protokolle mit den Protokollen für eine erfolgreiche Dateiübertragung vergleichen, besteht der einzige Unterschied am Ende. Wenn die Dateiübertragung erfolgreich ist, heißt es

Aug 16 09:01:20 internal-sftp[12200]: sent status Success 

Wenn es versagt, heißt es

Aug 17 09:01:55 internal-sftp[16260]: sent status No such file 

Die Übertragung der Datei dauert 20 bis 30 Sekunden. Zum Zeitpunkt der Ausführung lsdes somedirVerzeichnisses war die Datei tatsächlich auf der Festplatte . Wenn die Übertragung erfolgreich war, wurde die Datei sofort auf der Festplatte angezeigt, noch bevor die Übertragung abgeschlossen war. Das Protokoll ist also korrekt, es gibt wirklich keine Datei dort, aber ich kann nicht herausfinden, warum nicht. Wie Sie sehen, schreiben Sie über 27 MB an den Server.

Zu berücksichtigen ist, dass auf dem Verzeichnis ein Tool namens s3fs-fuse ausgeführt wird /somedir. Dieses Tool synchronisiert ein Verzeichnis mit einem AWS S3-Bucket, sodass alles, was in das Verzeichnis geschrieben oder aus diesem gelöscht wird, in den Bucket geschrieben oder gelöscht wird. Ich denke, es könnte mit dem Dateisystem ein paar Dinge auf niedriger Ebene erledigen. Nicht sicher, ob das vielleicht etwas damit zu tun hat.

Irgendwelche Ideen?