Posts by niklasdahlheimer

    Hallo!

    Ich will mein Webhosting mit dem WCP-Backup Manager über ftp sichern.

    Mein Setup:

    • FritzBox Cable (DSlite IPv6) mit USB-Festplatte
    • FTP auf Port 22xx ist aktiviert und konfiguriert
    • dynv6.net Adresse ist eingerichtet und funktioniert
    • Let's Encrypt Zertifikat ist auf der FritzBox aktiviert und installiert


    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:


    Code
    1. curl -v -P - --ssl -k -u uuuuuuu 'ftp://xxxxxxxxxxxxxxxxxx.dynv6.net/HDD/backupfolder/'
    2. Enter host password for user 'uuuuuuuuu':
    3. * Trying 37.xxx.xxx.xxx...
    4. * Trying 2a02:xxx:xxx:x:xxxx:xxxx:xxxx:xxxx...
    5. * connect to 37.xxx.xxx.xxx port 22xx failed: Die Wartezeit für die Verbindung ist abgelaufen
    6. * After 86352ms connect time, move on!
    7. * connect to 2a02:xxx:xxx:x:xxxx:xxxx:xxxx:xxxx port 22xx failed: Die Wartezeit für die Verbindung ist abgelaufen
    8. * Failed to connect to xxxxxxxxxxxxxxxxxx.dynv6.net port 22xx: Die Wartezeit für die Verbindung ist abgelaufen
    9. * Closing connection 0
    10. 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

    Code
    1. The current PHP memory limit is below the recommended value of 512MB.
    2. Nextcloud or one of the apps require upgrade - only a limited number of commands are available
    3. You may use your browser or the occ upgrade command to do the upgrade
    4. Cannot create "data" directory
    5. 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:


    Code
    1. bash-4.3$ ls -l
    2. total 148
    3. [....]
    4. drwxr-xr-x 54 hostingXXXXX psacln 4096 Apr 6 21:50 apps
    5. drwxr-xr-x 2 hostingXXXXX psacln 4096 Apr 6 23:11 config
    6. -rw-r--r-- 1 hostingXXXXX psacln 4986 Sep 1 2019 cron.php
    7. drwxrwx--- 24 hostingXXXXX psacln 4096 Feb 6 09:32 data
    8. -rw-r--r-- 1 hostingXXXXX psacln 283 Sep 1 2019 occ
    9. 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:

    • neue Nextlcoud-Version auf den Server laden und als "nc_new" entpacken
    • Maintenance Mode auf true
    • config.php und data Verzeichnis hinein kopieren
    • altes NC-Verzeichnis in"nc_old" umbenennen, neues Verzeichnis in "nc"
    • Maintenance Mode auf false
    • NC-Seite aufrufen. Updater ausführen

    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.

    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