Ändert sich was, wenn Du die Reihenfolge der Aktionen umdrehst? Also zuerst als gelesen markieren und dann verschieben?
Danke, das hat das Problem tatsächlich behoben!
Ist das jetzt Feature oder Bug?
Ändert sich was, wenn Du die Reihenfolge der Aktionen umdrehst? Also zuerst als gelesen markieren und dann verschieben?
Danke, das hat das Problem tatsächlich behoben!
Ist das jetzt Feature oder Bug?
Ich habe auf dem Mailserver meines Shared Hosting Pakets über das Roundcube Webmail Interface Filter eingerichtet. Diese funktionieren auch, bis auf den "gelesen"-Status: Mails werden mit der unten abgebildeten Konfiguration zwar in den "dmarc" Ordner verschoben, aber sind weiterhin als ungelesen markiert.
Was mache ich falsch?
@iaccarino, konntest du VSC Remote zum laufen bringen?
Gelöst! Fürs Protokoll/ andere Ratlose:
Aktivieren des "passiven Modus" in den Backup-Manager Einstellungen hat das Problem behoben.
Hallo!
Ich will mein Webhosting mit dem WCP-Backup Manager über ftp sichern.
Mein Setup:
Der Verbindungaufbau via Filezilla oder Firefox mit
Klappt ohne Probleme.
Das curl Kommando (was wohl auch der Backup-Manager zum testen der Verbindung benutzt)
curl -v -P - --ssl -k -u uuuuuuu 'ftp://xxxxxxxxxxxxxxxxxx.dynv6.net/HDD/backupfolder/'
wirft leider ein Timeout, sowohl im WCP als auch von meinem vServer per SSH:
curl -v -P - --ssl -k -u uuuuuuu 'ftp://xxxxxxxxxxxxxxxxxx.dynv6.net/HDD/backupfolder/'
Enter host password for user 'uuuuuuuuu':
* Trying 37.xxx.xxx.xxx...
* Trying 2a02:xxx:xxx:x:xxxx:xxxx:xxxx:xxxx...
* connect to 37.xxx.xxx.xxx port 22xx failed: Die Wartezeit für die Verbindung ist abgelaufen
* After 86352ms connect time, move on!
* connect to 2a02:xxx:xxx:x:xxxx:xxxx:xxxx:xxxx port 22xx failed: Die Wartezeit für die Verbindung ist abgelaufen
* Failed to connect to xxxxxxxxxxxxxxxxxx.dynv6.net port 22xx: Die Wartezeit für die Verbindung ist abgelaufen
* Closing connection 0
curl: (7) Failed to connect to xxxxxxxxxxxxxxxxxx.dynv6.net port 22xx: Die Wartezeit für die Verbindung ist abgelaufen
Die IPv6-ADresse wird korrekt über die dynDNS Adresse aufgelöst.
Username und Passwort sind auch korrekt (sonst würde es ja per Filezilla nicht gehen)
curl sollte wegen --ssl -k sowohl ftp als auch sftp probieren (sollte auch theoretisch beides funktionieren laut FritzBox)
...
Hat jemand eine Idee wo der Fehler liegen könnte?
Liebe Grüße
Nik
Hey,
also. Ein Umstellen der php-Settings von
FastCGI-Anwendung von apache bedient
auf
FPM-Anwendung von ngnix bedient
hat das Update-Problem gelöst!
Nach dem Umstellen ging das Update plötzlich ohne Probleme im Browser (per OCC habe ich dann natürlich nicht mehr versuchen können). Warum, ist mir leider ein Rätsel.
broda : ja, die config.php war bereits auf den Webhosting Pfad angepasst.
Auch der eigentliche Thread-Topic, also Download-Abbruch bei ~1GB, wurde dadurch, wie von Virinum beschrieben, gelöst (Danke!!)
Leider ergibt sich durch die Umstellung eine Warning im Nextcloud Admin Panel
PHP scheint zur Abfrage von Systemumgebungsvariablen nicht richtig eingerichtet zu sein. Der Test mit getenv("PATH") liefert nur eine leere Antwort zurück. Bitte die Installationsdokumentation ↗ auf Hinweise zur PHP-Konfiguration durchlesen sowie die PHP-Konfiguration Deines Servers überprüfen, insbesondere dann, wenn PHP-FPM eingesetzt wird.
Die Meldung hat bisher keine Auswirkung, die ich sehe. Wenn jemand weiß, wo man die Umgebungsvariablen korrekt konfigurieren kann, freue ich mich über einen Tipp
Probier mal dem PHP-Befehl auf der Kommandozeile den MemoryLimit-Parameter direkt mitzugeben: php -d memory_limit=1024M ...
danke, das elimiert schon mal die Fehlermeldung bzgl. des Limits! cannot create data directory besteht aber weiterhin.
Muss ich da ggf. rekursiv die Rechte für die Unterordner anpassen?
Die Zeile
drwxrwx--- 24 hostingXXXXX psacln 4096 Feb 6 09:32 data
heißt doch eigentlich, dass der Zugriff auf das Verzeichnis für das occ upgrade Script kein Problem sein sollte, oder?
Wieso „sudo -u www-data ...“? Du bist doch bereits als der Hosting-User angemeldet.
ist der Hosting-User also auch der User, unter dem der Webserver läuft? Da war ich mir nicht sicher. Ich habe nun malphp occ upgrade versucht, laufe da aber auch in einen Fehler
The current PHP memory limit is below the recommended value of 512MB.
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Cannot create "data" directory
This can usually be fixed by giving the webserver write access to the root directory. See https://docs.nextcloud.com/server/16/go.php?to=admin-dir_permissions
Die Frage ist nun, warum er beim Upgrade versucht das data-Verzeichnis zu erstellen, da das ja bereits vorhanden ist. Der Link bringt mich leider nicht weiter.
Die Rechte sind, so wie ich das verstehe, aber korrekt, wenn der hosting-user den Webserver ausführt:
bash-4.3$ ls -l
total 148
[....]
drwxr-xr-x 54 hostingXXXXX psacln 4096 Apr 6 21:50 apps
drwxr-xr-x 2 hostingXXXXX psacln 4096 Apr 6 23:11 config
-rw-r--r-- 1 hostingXXXXX psacln 4986 Sep 1 2019 cron.php
drwxrwx--- 24 hostingXXXXX psacln 4096 Feb 6 09:32 data
-rw-r--r-- 1 hostingXXXXX psacln 283 Sep 1 2019 occ
drwxr-xr-x 2 hostingXXXXX psacln 4096 Sep 1 2019 updater
Die Fehlermeldung zum Memorylimit ist aus meiner sicht auch seltsam, weil das laut WCP auf 1024M steht und damit ja über 512M sein sollte.
Danke schon mal für die Hinweise. Ich dachte, das ein Update auf die aktuellste 16er Nextcloud Version (16.0.9) sinnvoll ist, um einen Bug auszuschließen. Leider hänge ich da aktuell: Da der Updater einen Timeout beim Backup wirft, habe ich, wie in der Nextcloud-Doc beschrieben, ein manuelles Update durchgeführt:
Leider auch wieder ein Timeout. Upgrade per SSH ist nicht möglich, da logischerweise keine Rechte für Befehlsudo -u www-data php occ upgrade
Wenn ich das gelöst habe (jemand einen Tipp?), gehe ich wieder an das Size-Limit Problem
Passiert das wirklich immer exakt an der geichen Stelle? Unabhängig von der verwendeten Internetverbindung?
Hast Du zufällig mal einen öffentlichen Testlink für eine Datei, mit dem man das nachvollziehen kann?
ja, passiert immer bei 1.08 GB, habe es von mehreren Rechnern mit verschiedenen Dateien versucht. Ergebnis siehe Anhang.
Einen Testlink generiere ich gerne, wenn ich das Update durch habe (s.o.)
Genau das Problem hatte ich auch: https://forum.netcup.de/anwend…cloud-download-bricht-ab/
Meine Lösung war auf FPM served by nginx umzustellen.
Das scheint bei PHP 7.3 nicht mehr möglich zu sein. Dort kann man nur noch auswählen "FastCGI von Apache bedient". Evtl. müsste ich dann zurück auf PHP 7.2
Hallo,
ich komme leider trotz einiger Recherche nicht weiter:
In meinem Webhosting-Paket habe ich eine Nextcloud-Installation (16.0.2) in Betrieb. Downloads über das Web-Frontend scheitern bei 1.08GB.
Ein naheliegender Grund wäre, dass der nginx-Proxy proxy_max_temp_file_size auf den Default-Wert, also 1GB, gesetzt hat. Allerdings ist im WCP in den Einstellungen für Apache & nginx für die Subdomain nginx-Caching deaktiviert. Also bin ich da vermutlich auf dem Holzweg?!?
Könnte doch die PHP-Konfiguration das Problem sein? Ich bin auf PHP 7.3. In der .htaccess im Nextcloud-Verzeichnis finde ich keine
In den Server Logs erscheinen folgende Warnungen:
(70007)The timeout specified has expired: mod_fcgid: ap_pass_brigade failed in handle_request_ipc function
(104)Connection reset by peer: mod_fcgid: ap_pass_brigade failed in handle_request_ipc function
Über einen hilfreichen Tipp dazu würde ich mich sehr freuen und bedanke mich schon im Vorraus.
* steht für alle undefinierten Subdomains und @ steht für die Domain ohne Subdomain. Also einfach * auf die IP des Servers, und @ sowie die bereits bestehenden Subdomains auf die die IP des Webhosting setzen.
Perfekt! Ich gehe davon aus, dass @ dann für die Domain ohne Subdomain steht, also auch bei den MX- und AAAA-Records
Danke dir!
Liebes Forum,
Ich habe folgende Hosting Situation:
Webhosting-Paket 1.0.0.1 | Datenbank 1.0.0.2 | Mailserver 1.0.0.3 | vServer 2.0.0.1 |
Website: example.de Nextcloud: nexcloud.example.de |
db.example.de | mail.example.de | Docker mit verschiedenen Diensten hinter nginx Reverse Proxy Dienst A: a.example.de Dienst B: b.example.de Dienst C: c.example.de Dienst D: d.example.de .... |
Der vServer kam gerade erst dazu. Ich habe bisher die Subdomains händisch in den DNS-Eintrag von example.de eingetragen. Gerne würde ich per Wildcard alle Subdomains, außer die anderweitig definierten (nexcloud,db, mail) an den vServer weiterleiten, aber der * leitet meines Wissens nach auch die (Haupt-)Domain weiter. Bei anderen Anbieter meine ich mich erinnern zu können, dass ich einen A-Record mit leerem Hostfeld für die Hauptdomain anlegen konnte.
Wie konfiguriere ich meinen DNS, damit er alle Subdomains und nicht die Domain weiterleitet?
Ich könnte natürlich auch allen Traffic zum vServer schicken und von dort an die Domain weiterleiten. Da ich aber auf dem vServer viel rumexperimentiere, wäre die Website nicht erreichbar, wenn nginx down ist.
Würde mich über einen Tipp von den DNS-Experten sehr freuen!
Wenn ich ein Nicht-Google-Postfach zum Senden und empfangen benutze, tritt dieses Phänomen nicht auf. Es scheint also eine seltsame Einstellung bei Google zu sein. Wenn jemand eine Erklärung für diesen Effekt hat, gerne raus damit
Wie gesagt, mit einem anderen, von mir verwalteten, Postfach (Domain auch bei netcup) funktionierte der "Zirkelversand" (Versuch #3).
Ich habe es auch noch mal mit web.de versucht (#6), funktioniert auch.
Interessant ist aber, dass #7 auch nicht funktioniert. Google weist also nicht nur weitergeleitete Mails ab, die vom gleichen Account verschickt wurden, sondern auch, wenn vorher, in diesem Fall bei web.de, eine Zirkelweiterleitung stattgefunden hat.
Mails direkt an sich selbst , also ohne Weiterleitung, funktionieren aber (#8) .
Hier noch mal alle Versuche:
Versuch #1: SMTP Google an kontakt@beispielseite.de -> Postfach Beispielseite -> Weiterleitung an Postfach Google
kommt NICHT an
Versuch #2: SMTP Google an kontakt@beispielseite.de -> Postfach Beispielseite -> Weiterleitung an Postfache Beispielseite2
kommt an
Versuch #3: SMTP Beispielseite2 an kontakt@beispielseite.de -> Postfach Beispielseite -> Weiterleitung Postfach Google
kommt an
Versuch #4: SMTP Universitäts-Adresse an kontakt@beispielseite.de -> Postfach Beispielseite -> Weiterleitung Postfach Universitäts-Adresse
kommt an
Versuch #5: SMTP Universitäts-Adresse an kontakt@beispielseite.de -> Postfach Beispielseite -> Weiterleitung Postfach Google
kommt an
Versuch #6: SMTP Web an kontakt@beispielseite.de -> Postfach Beispielseite -> Weiterleitung an Web Postfach
kommt an
Versuch #7: SMTP Web an kontakt@beispielseite.de -> Postfach Beispielseite -> Weiterleitung an Web Postfach -> Weiterleitung an Google Postfach
kommt NICHT an
Versuch #8: SMTP Google an mailadresse@gmail.de -> Google Postfach
kommt an
In allen Fällen #1 bis #7 kommen die Mails im Postfach der Beispielseite an. Problem ist also der unterschiedliche Umgang der Sende/Ziel-Postfächer.
Wenn man's weiß, ist das ja kein Problem, praktisch hat das wahrscheinlich auch keinen Anwendungsfall, aber man sollte halt nicht versuchen auf diesem Weg eine Weiterleitung an Google testen
EDIT: Was ich noch nicht getestet habe ist, ob es einen Unterschied macht, ob man die Mails im Webmailer anschaut, oder per POP/IMAP abruft.
Thunderbird (meinname@gmail.com) -> google-SMTP -> beispielseite.de-SMTP -> kontakt@beispielseite.de (fwd: mainame@gmail.com) geht nicht?
Thunderbird (meinname@web.de) -> web.de-SMTP -> beispielseite.de-SMTP -> kontakt@beispielseite.de (fwd: mainame@gmail.com) geht?
Der Weg ist soweit korrekt, bis auf, dass ich nicht weiß, was google oder web mit der Mail macht (kontaktiert der Google/Web-Mailserver wirklich den SMTP meiner Beispielseite?), aber ja, sie wird in allen Fällen korrekt in das @beispielseite-Postfach gespeichert.
Ist die Adresse "kontakt@..." als Alias in Gmail eingestellt? Dann tauchen über Gmail versendete Mails nur im Gesendet-Ordner auf, und nicht erneut im Posteingang. Zumindest war das meine Erfahrung. Zu Testen am besten ein komplett unabhängiges Postfach bei einem anderen Anbieter verwenden.
Nein, die Adresse ist nicht als Alias eingestellt, google "weiß nichts" von meiner Identität als kontakt@beispielseite.de. Die Identifizierung und anschließende Löschung (?!?) der ankommenden Mail als Duplikat der gesendeten Mail, erfolgt wohl anhand anderer Kriterien.
Wenn ich ein Nicht-Google-Postfach zum Senden und empfangen benutze, tritt dieses Phänomen nicht auf. Es scheint also eine seltsame Einstellung bei Google zu sein. Wenn jemand eine Erklärung für diesen Effekt hat, gerne raus damit
Hallo,
Der Titel ist vielleicht etwas kryptisch. Folgendes Phänomen ist mir aufgefallen und ich würde es gerne verstehen.
Ich habe eine Mailadresse für meine Website-Domain angelegt (kontakt@beispielseite.de) und dort eine direkte Weiterleitung an meine private Mailadresse (meinname@gmail.com) eingerichtet.
Um zu testen, ob die Weiterleitung funktioniert, sende ich aus meinem Mailprogramm (Thunderbird) über den gmail-SMTP eine Mail an kontakt@beispielseite.de. Die Mails meines gmail-Postfachs rufe ich per IMAP ab. Die Test-Mail kommt aber nicht an.
Wenn ich für die Testmail einen anderen SMTP benutze (z.B. meinname@web.de), bekomme ich die Mail korrekt an meinname@gmail.com zugestellt.
Hängt das ggf. mit Header-Informationen in der Mail zusammen, die die ankommende Mail als Duplikat der gesendeten identifizieren? Ist das ein google spezifisches Problem?
Kann mir jemand erklären, woran das liegt oder mir einen Link zu einer Erklärung spendieren?
Danke!
Liebe Grüße
Niklas