Beiträge von Copro

Zitat von DerRené

Daher wie schon mehrfach vorgeschlagen: teste zunächst einmal, ob du wirklich von außen(!) über deine myfritz-Adresse auf dem Port erreichbar bist. Z.b. mit einem Server wie ich oder einfach einem Online-Tool, zb der hier. Mögliche Fehlerquellen wurden auch bereits genannt (CGNAT, Fritzbox Einstellungen, etc).

Das wurde schon gemacht in #4 - habe ich aber auch übersehen:

connect to ****:****:1000:a1::35cc port 21 failed: Permission denied

Ich musste einen extra Port angeben bzw. mir wurde zufällig der 41584 gesetzt ... daher denke ich dass der Default Port 21 vielleicht das Problem ist.
FB_FTP_DefaultPort.png

Zu finden unter "Internet - Freigaben - Fritz!Box-Dienste" (ein Teil davon also der FTP/S Zugriff ist auch unter "Heimnetz - USB / Speicher" konfigurierbar) aber da ist alles auf einem Blick.

Mit diesen Einstellungen konnte ich jetzt den FTPS korrekt hinzufügen und das sollte mit Deinen Daten auch klappen:

netcup_FTP_BackupManager.png

Hostname oder IP des FTP-Servers: blabla.myfritz.net:<hierDenPortAusDerFritzBoxKonfigurationErgaenzen>

Verzeichnis zum Speichern von Backupdateien: /Volume/Extern/webserver/

(wie im "Zum Beispiel" den Slash zu Beginn angeben was zur Verdopplung der Slashes führt, wie CmdrXay schon angemerkt hat. Das macht zwar nichts also funktioniert in beiden Fällen und schaut nur nicht schön aus. Alle vier Varianten von "16GB_NTFS/netcup" bis "/16GB_NTFS/netcup/" funktionieren und sorgen dafür dass der FTPS als gültiges Backup-Ziel verfügbar ist.)

Ich will Dich nicht entmutigen ... aber das Backup hochladen war aber dann doch nicht möglich wegen folgendem Fehler
Unable to create the remote backup: Transport error: unable to check directory existence: Curl error: (19) FTP: couldn't retrieve (RETR failed) the specified file: Last FTP request: QUIT Last FTP response: 221 Goodbye

Jetzt geht es hier weiter ... da hatte im November 2021 ein anderer netcup Kunde schon einmal das Problem gemeldet:
Backup/Remote-FTP funktioniert nicht mehr - WCP (Webhosting Control Panel) - netcup Kundenforum

Ich habe bevor ich die TCP Dumps von der fritz.box ansehe noch schnell einen ProFTPD auf meinem Pi eingerichtet, eine Portweiterleitung an der Fritz!Box erstellt und dort hat das Ablegen des Backups auf Anhieb geklappt. Wenn also dasselbe Problem oben bei Dir auch auftritt - pack die Festplatte einfach an den Pi als Notlösung
(Ich vermute das Problem mit dem netcup/plesk Backup-Manager muss ich nochmal beim Support melden und das könnte länger dauern bis da ein Fix verfügbar ist wenn es überhaupt einen geben wird.)

Zitat von OlMi1_YT I NETCRAFT

Bei mir war der Grund eher der Unwille, teilweise 20€ im Monat für 1 TB Speicher zu bezahlen und dass ich noch eine externe HDD rumliegen hatte (aber letzendlich reicht jeder USB-Stick aus). Falls du interne Platten rumliegen hast: Adapter von SATA auf USB gibt's für knapp 10€.

Ich hab zu viel Hardware rumliegen
Ein alter HP Proliant Microserver mit Synology Bootimage ist aktuell mein NAS ... an der Fritz!Box hängt aktuell nur ein 16 GB USB 3.0 Stick ... ich werde also eher zum Ausprobieren auf einem Raspi einen FTP Server draufpacken und dort debuggen, was der von Netcup abgesetzte curl Befehl genau macht.

Bei Dir scheint es aber vermutlich eher an der Erreichbarkeit des 21 Ports zu liegen (Timeout was reached). Daher musst Du noch den korrekten Port angeben.

Ich habe die Option "Diese Option ermöglicht den Zugriff auf die Speichermedien an der FRITZ!Box aus dem Internet." jetzt auch gesetzt und musste dann einen eigenen TCP Port angeben. Nicht den Standard FTP Port 21 wie aus Deinen Protokollen.

Und direkt unter der Option steht sowieso nochmals erklärt welche Bedingungen der Benutzer haben muss:
Zugang haben alle FRITZ!Box-Benutzer, denen im Menü "System > FRITZ!Box-Benutzer" die Rechte "Zugang auch aus dem Internet erlaubt" und "Zugang zu NAS-Inhalten" eingeräumt wurden.

Ich berichte gleich, ob es bei mir klappt ...

Die Adressen *.myfritz.net verwenden ja normalerweise die öffentlichen IP-Adressen aber das Auflösen des Hostnamen ist ein guter Hinweis, falls da doch irgendwie eine nicht öffentlich erreichbare IP-Adresse hinterlegt worden wäre. (CGN musste ich selber erstmal nachschlagen)

Mit relativ aktuellem FRITZ!OS 7.29 auf einer 7530 hätte ich die Option ("Internetzugriff auf Ihre Speichermedien über FTP/FTPS aktiviert") nicht gefunden ... allerdings muss bei mir für den eingerichteten Benutzer die Checkbox im Benutzer unter Zugang aus dem Internet gesetzt sein: [ ] Zugang auch aus dem Internet erlaubt

Dass der Benutzer schon den korrekten Zugang zu den NAS Inhalten hat, schließe ich aus dem erfolgreichen Versuch den curl Befehl vom lokalen Pi abzusetzen.

Danke auf jeden Fall an den Fragesteller für den Anreiz das jetzt auch einrichten zu wollen. 😊

H6G Die Zahl kam vor den: (habe ich mir nicht ausgedacht)

badenten.jpg

-40331

Die Frühlingsgefühle erwachen: -40329

Fruehlingsgefuehle_Wochenenten.jpg

Bei einer neuen Domain, (die aktuell mit Dokumentenstamm /domain.de/httpdocs angelegt wurde) und mit weiteren Subdomains testdomain.bestehendedomain.de habe wieder dieselben Problem ... Kontakt mit dem Support wurde schon aufgenommen und mittlerweile an Fachabteilung weiter gegeben.

[UPDATE] Das netcup Team konnte das Problem bereinigen. Es wird aus dem korrekten Dokumentenstamm Ordner ausgeliefert und das SSL Zertifikat ist ein gültiges von Let's Encrypt und nicht das abgelaufene von plesk.

Zur Dokumentation der Zeiten bis zur Bereinigung:

20.03.2022 20:41 Ticket erstellt

21.03.2022 15:24 Weitergabe an Abteilung

24.03.2022 13:57 Bereinigung

Seitdem im WCP die neue Konfigurationsmöglichkeit für SSL also in meinem Fall eines Webhosting 8000 Pakets für LE Zertifikate angezeigt wird, verweist die Hilfe mit dem (?) - "Handbuch lesen" auf die Plesk Obsidian Hilfe in Englisch (US): Securing Connections with the SSL It! Extension | Plesk Obsidian documentation

Die gäbe es auch in Deutsch, da die Sprache im WCP ja auch auf Deutsch (Germany) oder Englisch (United States) gestellt werden kann, falls man das unterschiedlich verlinken kann.
Sichern von Verbindungen mit der Erweiterung SSL It! Erweiterung | Plesk Obsidian documentation

Hier kommen also die ersten Plesk Obsidian Panels durch ... der Rest ist größtenteils ja noch Plesk Onyx.

Änderungen am Dokumentenstamm für Domains sind anscheinend nur noch im CCP möglich - nur für Subdomains muss man noch auf das Plesk (Onyx) Panel im WCP? (Webhosting 1000 - 8000)

Bei der Festlegung des Dokumentenstamms wird man aktuell darauf hingewiesen diese im CCP zu ändern.

Dort angekommen versteckt sich die Option relativ unscheinbar hinter dem Button [Einstellungen bearbeiten] während einen der Bild-Button [Hosting-Einstellungen] nur wieder ins WCP auf das Plesk Panel mit den Hinweisen unten verweist und keine Einstellung mehr möglich ist.

netcup_ccp_dokumentenstamm.jpg

Bei einer Subdomain (weil diese ja nicht im CCP angezeigt werden) ist dies nach wie vor noch im WCP möglich. Allerdings steht da beim Hosting-Typ und Dokumentenstamm jetzt auch der Hinweis direkt drunter was in meinen Augen verwirrend ist:
netcup_wcp_subdomain_plesk_onyx_panel_dokumentenstamm.jpg

Zitat

Diese Funktionalität können Sie ab sofort in unserem Customercontrolpanel (CCP) bei dem jeweiligen Tarif anpassen. Weitere Informationen finden Sie in unserem Wiki.

P.S. Der Link zum Wiki verweist auf die URL bzw. den Abschnitt "Wie kann ich Änderungen an zwischenzeitlich deaktivierten Einstellungen im Hostingpanel vornehmen?":
Plesk Onyx Panel Webhosting – netcup Wiki (netcup-wiki.de)

Entschuldige, dass ich so plötzlich hier reinfrage. Kam die E-Mail von plesk bei Dir auch von noreply@webhosting.systems aber noch im Namen von "Felix Preuß" dem ehemaligen Geschäftsführer von Netcup vor 2021?

(Ich schreibe mal dem Support, ob man da was offizielles eintragen kann wie z.B. "netcup Plesk Noreply", da ich das schon als Spam aussortieren wollte und erstmal nicht mit netcup in Verbindung brachte.)

Neuer Versuch der ebenfalls nicht klappt - jetzt bleibt es bei der Anzeige des Standard index.html ohne LE Zertifikat:
Domain noch nicht zugewiesen / in Zuweisung

0. Neues Unterverzeichnis im www Ordner angelegt mit frischer index.html und statischem Inhalt vorbefüllt.

1. Neues Subdomain-Hosting angelegt mit Zuweisung des angelegten Ordners

2. Zuerst das LE-Zertifikat aktivieren ohne www Subdomain

3. Dann die 301-Weiterleitung aktivieren (Dauerhafte, für SEO geeignete 301-Weiterleitung von HTTP zu HTTPS )

4. Test und Prüfung erneut nach 24 Stunden -> Anzeige ohne LE Zertifikat wie oben: Domain noch nicht zugewiesen / in Zuweisung

--> Ticket beim Support eröffnet

[UPDATE] Support konnte das Problem bereinigen.

Zur Dokumentation der Zeiten bis zur Bereinigung:

07.03.2022 12:57 Ticket erstellt

08.03.2022 19:43 Weitergabe an Abteilung

10.03.2022 13:42 Bereinigung

Mit einem Ticket beim Support konnte das Problem dann wieder einwandfrei bereinigt werden.

Ich wiederhole mal die Schritte von DerRené mit einer Subdomain, weil ich kann mir auch vorstellen kann, dass es nur die unglückliche Reihenfolge ist die das Problem auslöst.

1. Neues Subdomain-Hosting angelegt

2. 301-Weiterleitung aktivieren (Dauerhafte, für SEO geeignete 301-Weiterleitung von HTTP zu HTTPS )

3. Danach erst das LE-Zertifikat aktivieren mit der unnötigen www Subdomain (-> www.sub.domain.de)

4. Test und Prüfung erneut nach x Stunden (Direkt nach Anlage: Domain noch nicht zugewiesen / in Zuweisung)

Bisher hat das immer nicht geklappt:

1. Neues Subdomain-Hosting angelegt

2. Zuerst das LE-Zertifikat aktivieren mit der unnötigen www Subdomain (-> www.sub.domain.de)
3. Dann die 301-Weiterleitung aktivieren (Dauerhafte, für SEO geeignete 301-Weiterleitung von HTTP zu HTTPS )

4. Test und Prüfung erneut nach x Stunden

Also bei mir tritt das bei jeder neu registrierten Domain im Webhosting auf. Meine Vermutung geht in die Richtung, dass ich die Aufteilung der Stammverzeichnisse nicht aus dem httpdocs Ordner heraus nutze, sondern einen anderen Stammordner wie www verwende. Generell scheint es da irgendwo bei der Änderung der Stammverzeichnisse zu hapern, die z.B. nicht beim nginx ankommen.

Hat mich gerade auch gefuxxxt ... sollte dringend ins Handbuch bzw. ins Wiki:
https://www.netcup-wiki.de/wiki/Plesk_Ony…ew&locale=de-DE

Sieht nicht aus als ob das Netcup Wiki auch für Kunden bearbeitbar wäre ... das müsste also ein Mitarbeiter hinzufügen?
Danke dass die Lösung hier auf dem Forum veröffentlicht wurde

Nach der Antwort an den Support hat der Hostmaster das gestern Abend noch unkompliziert gelöst und die Beeinträchtigung bereinigt.
Das LE Zertifikat wird seit der Korrektur gestern Abend korrekt ausgeliefert und die statischen Dokumente liefert jetzt der nginx auch korrekt aus.
Solltet Ihr also auf eurem Webhost ähnliche Probleme haben und etwas Wartezeit das nicht lösen, am Besten freundlich beim Support nachfragen und das dringendste Problem - also am Besten das mit dem nicht korrekt ausgelieferten Zertifikat melden.

Nach der Antwort an den Support hat der Hostmaster das gestern abend noch unkompliziert gelöst und die Beeinträchtigung bereinigt.
Ich vermute mal dass der First Level nur von meinem Wordpress Geschwafel sofort zum Satzbaustein gegriffen hat.
Das LE Zertifikat wird seit der Korrektur gestern abend korrekt ausgeliefert und die statischen Dokumente liefert jetzt der nginx auch korrekt aus.

Der betroffene Webhost ist a2e5e und nach dem Bestellen einer neuen Domain oder Erstellung einer Subdomain wird nach dem Beantragen eines Let's Encrypt Zertifikats über das WCP nur das selbst signierte Plesk Zertifikat ausgeliefert. Anfrage beim Support wurde leider bis jetzt noch nicht bearbeitet.

Weil das in dem anderen Thread zum Problem bei der Verlängerung genannt wurde - das Problem tritt auch auf wenn die Option "Dauerhafte, für SEO geeignete 301-Weiterleitung von HTTP zu HTTPS" nicht ausgewählt wird.

Zitat

Sie besitzen bei uns einen Webhosting-Tarif. Wir stellen Ihnen hierbei die Laufzeitumgebung bereit. Auf Ihre Inhalte haben wir keinen Einfluss und können keinen Support leisten.

Leider habe ich dieses Mal nicht soviel Glück, dass das Problem sofort bearbeitet wird. Mal schauen, ob jemand über den Feiertag / Sonntag auch Dienst schiebt.

Hallo Lukas,

ich glaube nicht dass dein Browser spinnt - aber gibt doch mal etwas mehr Details zu Deinem Webhosting Paket und was Du genau gemacht hast,

Ich habe dasselbe Problem bei neuen Domains nachdem ich diese NICHT aus /httpdocs heraus anbiete, weil der nginx anscheinend falsch konfiguriert wird. Damit klappt auch trotz erfolgreicher Ausstellung des Let's Encrypt Zertifikats keine Verschlüsselung und alle Browser meckern ein selbst-signiertes Zertifikat an das stattdessen ausgeliefert wird. Leider ist mir kein Workaround bekannt und vermutlich müsstest Du auch ein Ticket aufmachen, falls das noch nicht geschehen ist.

Aus dem April 2020 der Beitrag bei dem das schon mal passiert:
https://forum.netcup.de/anwendung/ccp-…t-ausgeliefert/

VG,

Michael

Wurde schon gemeldet nachdem ich genau das Problem im April 2020 ja auch schon hatte. Ich dachte nur dass würde sich mit dem Workaround bzw. dem Warten erledigen. Ich melde mich wieder falls der Support das lösen konnte. Hier war der alte Thread zum documentroot Durcheinander:
https://forum.netcup.de/anwendung/wcp-…0389#post140389

Zusammenhängend damit das Problem mit dem nicht ausgelieferten Let's Encrypt Zertifikat das stattdessen mit einem selbst signierten Zertifikat geliefert wird:
https://forum.netcup.de/anwendung/ccp-…t-ausgeliefert/

Noch kein Ticket aufgemacht ... aber kann ich gerne probieren. Jetzt hat es ja ein gutes Jahr gedauert ;-]

Die Domains liegen alle in extra Verzeichnissen, aber nicht unter /httpdocs, damit bei neuen Domains nicht automatisch Zugriff darauf stattfinden kann.
Mit dieser eigentlich ganz sinnigen Aufteilung die ich auch hier aus dem Forum hatte handelt man sich aber möglichweise ein anderes Problem bei der Konfiguration des nginx bzw. der Ausstellung der Let's Encrypt Zertifikate ein.

domain1.tld - /www/website1 (Wordpress 1) [wird doppelt angezeigt]

domain2.tld - /www/website2 (Wordpress 2)

domain3.tld - /www/website3 (Wordpress 3)