Beiträge von kameleon1er

  • Storage optimization required - unexpected snapshot deletion

    ### RESOLVED ####

    Netcup team answer :

    Code
    If this message is shown in your SCP (ServerControlPanel) then this action must be taken, but should you not have any noticeable problems on this server, then you can delay this to a later date. If you decide to delay this, be aware, that the downtime can be longer when you then decide to do this.
You can download your snapshots before proceeding with the optimization, as you can upload and implement them again should you need to.
Why this must be done, is to also optimize the data on the host system, which can improve the read- and write-speed.
If you have any further questions, please do not hesitate to contact us.
Have a nice day.
Mit freundlichen Grüßen,
netcup Team

    So I did it : download my last snapshot > Stop & Optimize > in fact = less of 1 minute for the process… > done ! Server is back… Simple but still question; why ? …

  • Storage optimization required - unexpected snapshot deletion

    Ich habe nicht den Eindruck, dass das Problem bei mir liegt... /

    I don't feel that the problem is on my end...

  • Storage optimization required - unexpected snapshot deletion

    VPS : RS 1000 G11 iv

    Hello everyone,

    I'm experiencing a situation with my VPS and would appreciate some community feedback.

    My Netcup panel indicates that storage optimization is necessary. When checking the dedicated section, I discovered that all my snapshots will be deleted during this operation, including recent critical snapshots (09oct2025, 21oct2025).

    This VPS hosts an important Docker environment for me.

    Has anyone experienced this situation before?

    • Is it normal for all snapshots to be deleted?
    • Are there alternatives to preserve some snapshots?
    • Do you have any advice to best prepare for this migration?

    I'm open to all best practices! Thank you in advance for your help."

    --------------

    Speicheroptimierung erforderlich - unerwartete Snapshot-Löschung

    Hallo zusammen,

    ich stehe vor einer Situation mit meinem VPS und würde gerne Erfahrungsberichte aus der Community hören.

    Mein Netcup-Panel zeigt an, dass eine Speicheroptimierung notwendig ist. Bei der Überprüfung des entsprechenden Bereichs habe ich festgestellt, dass alle meine Snapshots während dieses Vorgangs gelöscht werden, einschließlich kürzlicher kritischer Snapshots (09oct2025, 21oct2025).

    Dieser VPS hostet eine wichtige Docker-Umgebung für mich.

    Hat jemand bereits diese Situation erlebt?

    • Ist es normal, dass alle Snapshots gelöscht werden?
    • Gibt es Alternativen, um einige Snapshots zu erhalten?
    • Habt ihr Ratschläge, um diese Migration optimal vorzubereiten?

    Ich bin für alle Best Practices offen! Vielen Dank im Voraus für eure Hilfe."


  • CRITICAL and RECURRING Issue: Total Network Connectivity Loss on KVM VPS (SSH "Connection refused" / Ping Fails) – Identical to June 26th, 2025 Problem – Connectivity remains cut even after Snapshot Restoration!

    Ich melde mich bezüglich des Problems, das ich kürzlich mit meinem VPS srv-hosting.democrasite.com (IP: 152.53.118.225) hatte. Dieser war blockiert, per SSH unerreichbar und hatte keine externe Netzwerkverbindung mehr.

    Nach einer gründlichen Analyse und mit Hilfe eines technischen Assistenten konnten wir die Ereigniskette rekonstruieren und die Hauptursache identifizieren, die auf meine eigenen Handlungen zurückzuführen ist, wahrscheinlich verursacht durch eine gewisse Übereilung.

    Zunächst möchte ich meine Fehler im Management eingestehen, die mich dazu veranlasst haben, aus Sicherheitsgründen einen Snapshot wiederherzustellen, da ich die Situation anfänglich nicht vollständig verstanden hatte.

    Hier ist die detaillierte Diagnose und der Zeitplan der Ereignisse:

    Kontext meines srv-hosting VPS:

    • Der Server lief unter Ubuntu und verwendete iptables mit aktivem Fail2Ban zum Schutz vor Brute-Force-Angriffen über SSH.
    • Die sshd-Konfiguration (/etc/ssh/sshd_config) sah wie folgt aus und erlaubte unter anderem den root-Login sowie die Passwort- und Public-Key-Authentifizierung:
      Code
      PubkeyAuthentication yes@@@WCF_PRE_LINEBREAK@@@PasswordAuthentication yes@@@WCF_PRE_LINEBREAK@@@PermitRootLogin yes@@@WCF_PRE_LINEBREAK@@@UsePAM yes@@@WCF_PRE_LINEBREAK@@@

    Die zum Problem führenden Aktionen (am 16. Juli):

    1. "Hot"-Installation und Aktivierung von UFW: Ich habe UFW auf srv-hosting installiert und konfiguriert (insbesondere durch Anpassung von /etc/ufw/before.rules für die Kompatibilität mit Fail2Ban). Der entscheidende Fehler war hier, UFW (sudo ufw enable) zu aktivieren, ohne danach einen vollständigen Systemneustart durchzuführen. Diese "Hot"-Aktivierung führte potenziell zu einer instabilen Umgebung oder Konflikten in der iptables-Verwaltung.
    2. Mehrere, fehlerhafte SSH-Authentifizierungsversuche: Unmittelbar nach der UFW-Aktivierung versuchte ich, mich über SSH zu verbinden:
      • Von meinem MacBook Air: Ich versuchte SSH-Zugriffe (als root und/oder als mein Standardbenutzer via sudo) unter Verwendung von SSH-Schlüsseln mit einer falschen Passphrase. Darüber hinaus ist es möglich, dass der Public Key dieses MacBook Air nicht korrekt konfiguriert oder von srv-hosting erkannt wurde.
      • Der "Gnadenstoß" erfolgte, als ich dasselbe von meinem iMac, meinem gewohnten Arbeitsgerät, versuchte. Obwohl der Public Key des iMacs korrekt auf srv-hosting installiert ist, gab ich erneut wiederholt und schnell eine falsche Passphrase ein.

    Folgen und Problem manifestierung:

    Die schnelle Abfolge dieser Aktionen führte zu einer kritischen Kettenreaktion:

    1. Massive Fail2Ban-Aktivierung: Jeder fehlgeschlagene SSH-Authentifizierungsversuch, der von zwei verschiedenen Client-IPs stammte und mehrere Benutzer/Methoden ansprach, wurde von Fail2Ban erkannt. Fail2Ban begann daraufhin, dynamisch und schnell Sperrregeln in die iptables des Servers für meine IPs hinzuzufügen.
    2. sshd-Sättigung und Absturz: Die Kombination aus einer neu aktivierten Firewall (UFW), die mit einem dynamischen Regelverwaltungssystem (Fail2Ban) interagierte, und dem Stress, der durch einen intensiven Fluss fehlgeschlagener Authentifizierungsversuche erzeugt wurde, hat den sshd-Dämon wahrscheinlich gesättigt und/oder korrumpiert.
      • Der sshd-Dienst wurde für neue Verbindungen unerreichbar. Obwohl systemctl status sshd möglicherweise "active (running)" anzeigte (wahrscheinlich durch meine bestehende Cockpit-Sitzung am Leben gehalten), reagierte er nicht.
      • Ein Befehl wie which sshd gab "command not found" zurück, was auf einen korrumpierten oder eingefrorenen Prozesszustand hindeutete.
    3. Völliger Verlust der externen Netzwerkverbindung: Infolge dieser Instabilität auf Firewall- und SSH-Dienstebene kam es zu einem vollständigen Verlust der externen Netzwerkverbindung für srv-hosting. Der Server konnte keine externen Ziele (wie Google) mehr anpingen oder Pakete herunterladen (sudo apt install --reinstall openssh-server schlug aus diesem Grund fehl), was eine Remote-Fehlerbehebung unmöglich machte.

    Ausschluss von Netcup-Infrastrukturproblemen:

    Um sicherzustellen, dass das Problem nicht mit der Netcup-Infrastruktur zusammenhing, führten wir Konnektivitätstests durch:

    • Ich konnte meinen anderen VPS (srv-hosting.democrasite.com, IP: 152.53.118.225) von srv-apps.democrasite.com (mein anderer Netcup VPS, IP: 152.53.180.152) aus mit 0% Paketverlust anpingen. Dies beweist, dass die Netzwerkverbindung zwischen meinen eigenen VPS innerhalb der Netcup-Infrastruktur einwandfrei funktionierte.
    • Im Gegensatz dazu zeigte der ping an 37.67.114.10 (ein früherer Test, den ich geteilt hatte) auch von einem gesunden Server aus immer noch 100% Paketverlust, was bestätigt, dass diese IP kein zuverlässiger Referenzpunkt ist.

    Zusammenfassend:

    Der Ausfall von srv-hosting war das direkte Ergebnis einer komplexen "Selbst-Sperrung" und Systeminstabilität, verursacht durch die Kombination einer neuen Firewall-Konfiguration (UFW) ohne Neustart, eines sehr aktiven Fail2Ban und eines intensiven Flusses fehlgeschlagener SSH-Authentifizierungsversuche (aufgrund meiner falschen Passphrasen).

    Vielen Dank für Ihre Geduld und die Unterstützung der Netcup-Community. Diese Erfahrung hat mich gelehrt, wie entscheidend wichtig es ist:

    1. Immer einen Systemneustart durchzuführen nach größeren Installationen oder Neukonfigurationen sensibler Elemente wie Firewalls oder SSH-Diensten.
    2. Passphrasen und SSH-Schlüsselkonfigurationen sorgfältig zu überprüfen, insbesondere bei den ersten Verbindungen von neuen Geräten.

    Ich hoffe, diese detaillierte Diagnose kann anderen Benutzern in ähnlichen Situationen nützlich sein.

    Moral von der Geschichte: Nicht in Panik geraten, nicht überstürzt handeln und immer daran denken, Ihren VPS nach jeder sensiblen Konfiguration oder Installation von sensiblen Softwarepaketen, wie zum Beispiel der Firewall, neu zu starten.


    Mit freundlichen Grüßen.


    Sincerely, :) :thumbup:


    [attach=15296]English Version[/attach]


  • CRITICAL and RECURRING Issue: Total Network Connectivity Loss on KVM VPS (SSH "Connection refused" / Ping Fails) – Identical to June 26th, 2025 Problem – Connectivity remains cut even after Snapshot Restoration!

    ich melde mich erneut bei Ihnen nach Ihrem Feedback und den Analysen, die ich meinerseits durchgeführt habe, um die Situation zu klären. Vielen Dank für den Vorschlag bezüglich tcpdump; das ist in der Tat ein ausgezeichnetes Tool, das ich sicherlich eingesetzt hätte, wenn die Situation so unklar geblieben wäre.

    Als ich an mein Problem vom 26. Juni dachte, das zu einer vollständigen Neuinstallation führte (und diese "schreckliche" VNC-Erfahrung!), zog ich es diesmal vor, zu einem früheren Snapshot meines VPS srv-hosting.democrasite.com (152.53.118.225) zurückzukehren, den ich etwa eine Stunde vor Beginn der Probleme erstellt hatte.

    Und wider Erwarten funktionierte die SSH-Verbindung nach der Wiederherstellung, und meine Websites sowie mein Mailserver sind wieder voll funktionsfähig. Mein anderer VPS, srv-apps.democrasite.com (152.53.180.152), war von diesem Vorfall überhaupt nicht betroffen und lief währenddessen normal weiter.

    Um so präzise wie möglich zu sein, was auf srv-hosting vor der Wiederherstellung geschah:

    1. Ich hatte UFW installiert und seine Regeln konfiguriert (einschließlich der Integration bestehender iptables-Regeln und der Änderung einer Direktive von DROP auf ACCEPT in den before.rules), und es dann aktiviert. Es gab zu diesem Zeitpunkt keinen Server-Neustart.
    2. Nach diesen Änderungen und Versuchen, eine SSH-Schlüsselverbindung (mit einem passphrase-Problem meinerseits) herzustellen, reagierte der SSH-Dämon (sshd) auf srv-hosting nicht mehr.
    3. Von diesem Zeitpunkt an konnte ich mich nicht mehr per SSH mit der Maschine verbinden, und schlimmer noch, der Server srv-hosting konnte nicht einmal mehr externe Ziele (ping-en (z.B. Google-Server), was auf einen totalen Verlust des Zugangs zum Netcup-KVM-Netzwerk für diesen VPS hindeutete.

    Meine zentrale Frage bleibt daher: Gibt es nach Ihrem Kenntnisstand einen Mechanismus auf Seiten der Netcup-Infrastruktur, der den Zugriff auf das externe Netzwerk eines KVM-VPS vorübergehend "isolieren" oder "einsperren" kann? Insbesondere nach einem als abnormal eingestuften internen Verhalten (wie vielen fehlgeschlagenen SSH-Verbindungsversuchen, möglicherweise im Zusammenhang mit Fail2Ban, oder einer Instabilität des SSH-Dienstes selbst)?

    Sollte dies nicht der Fall sein, weiß ich zumindest, dass das Problem vollständig auf meine Fehlkonfiguration zurückzuführen war, und ich entschuldige mich natürlich für die Unannehmlichkeiten. Ziel ist es, das Problem zu verstehen, um eine Wiederholung zu vermeiden.

    Vielen Dank im Voraus für Ihre Zeit und Hilfe.

    Mit freundlichen Grüßen,

    --------
    Thank you for the tcpdump suggestion; it is indeed an excellent tool that I would have used if the situation had remained unclear.

    Recalling my problem on June 26th, which resulted in a complete reinstallation (and that "horrible" VNC experience!), this time I preferred to revert to the last snapshot I had made on my VPS srv-hosting.democrasite.com (152.53.118.225) about an hour before the issues began.

    Unexpectedly, the SSH connection worked after the restoration, and my websites, as well as my mail server, are fully operational again. My other VPS, srv-apps.democrasite.com (152.53.180.152), was not affected at all by this incident and continued to function normally throughout.

    To be as precise as possible about what happened on srv-hosting before the restoration:

    1. I had installed UFW and configured its rules (including integrating existing iptables rules and changing a DROP to ACCEPT directive in the before.rules), and then I enabled it. There was no server reboot at that time.
    2. Following these modifications and attempts to establish an SSH key connection (with a passphrase issue on my part), the SSH daemon (sshd) on srv-hosting became unresponsive.
    3. From that point, I could no longer connect to the machine via SSH, and more seriously, the srv-hosting server could not even ping external targets (e.g., Google's servers), indicating a total loss of access to the Netcup KVM network for this VPS.

    My central question therefore remains: To your knowledge, is there a mechanism within the Netcup infrastructure that can temporarily "isolate" or "jail" a KVM VPS's access to the external network? Particularly after an internal behavior deemed abnormal (such as numerous failed SSH connection attempts, possibly related to Fail2Ban, or an instability of the SSH service itself)?

    If this is not the case, I will at least know that the problem was entirely due to my misconfiguration, and I would, of course, apologize for the inconvenience. The goal is to understand the issue to prevent it from recurring.

    Thank you in advance for your time and assistance.

    Sincerely

    :)

  • CRITICAL and RECURRING Issue: Total Network Connectivity Loss on KVM VPS (SSH "Connection refused" / Ping Fails) – Identical to June 26th, 2025 Problem – Connectivity remains cut even after Snapshot Restoration!

    Hello everyone and Netcup support, linked to Same June 2025 issue

    I am facing an extremely severe and recurring issue on my KVM VPS instances, which is jeopardizing the stability of my services, particularly my mail server.

    Problem Description: I have suddenly lost all external connectivity (SSH, HTTP(S), etc.) to my KVM VPS: srv-apps.democrasite.com (IP 152.53.180.152). From my client machine (iMac), any attempt to SSH via the IP results in a "Connection refused."

    Confirmed on the VPS side (via Cockpit):

    • The SSH daemon (sshd) is running and listening correctly on port 22 (IPv4 and IPv6).
    • The UFW firewall is active and configured to ALLOW IN Anywhere on port 22 (as well as all necessary ports for my web and mail services).
    • SSH logs show that the server is listening and even recorded connection attempts from an older IP, but none from my current public IP.
    • Most alarming: From the VPS, I am unable to "ping" my current public IP address (37.67.114.10). I get 100% packet loss.

    Context of the Issue's Onset and Recurrence: This problem appeared while I was configuring SSH connectivity between two Netcup VPS instances (for Cockpit Master/Slave setup). It's important to note that no VPS reboot was performed after the UFW configuration before the blocking occurred. My iMac was initially able to connect via SSH using a password/passphrase, but subsequent unsuccessful attempts from my MacBook Pro (possibly due to a passphrase issue or an unconfigured SSH key pair) followed, and then connectivity was cut off for all my machines.

    This problem is an exact recurrence of the one I encountered on June 26th, 2025, on another Netcup KVM VPS (see this forum thread for reference: [Link to your old forum thread]). On that occasion, the same lack of ping response and network blockage occurred, and the only solution was to completely reinstall the KVM from a fresh image to regain connectivity.

    Why this is a Netcup Infrastructure Issue (according to my analysis):

    • The SSH daemon is active and UFW is open, so the problem is not OS-side.
    • The ping failure from the VPS to my IP proves that the connection is blocked upstream, even before reaching my VPS.
    • Most critically: I restored a snapshot of my VPS (taken just before these configurations, when everything was working). EVEN AFTER THE SNAPSHOT RESTORATION, THE PROBLEM PERSISTS! This definitively rules out any software configuration error on the VPS and confirms an external blockage.

    Consequences and Urgency: I have spent several days configuring this VPS to migrate my websites and, most importantly, my mail server onto it. Such network instability, which is recurring identically, is unacceptable for such a critical service. It implies the loss of days of work if I have to completely reinstall everything again.

    Questions to the community and Netcup support:

    • Have other users experienced this type of "mysterious" network disconnection where ping fails and the only solution is a complete reinstallation?
    • Does Netcup have network-level firewall or monitoring systems that might automatically block IPs or isolate VPS instances in case of "suspicious" behavior (e.g., repeated SSH attempts, dynamic UFW configurations)? Is the absence of a reboot after such operations a known trigger?
    • What are the precise policies regarding this, and how can stable network connectivity be ensured for critical VPS instances? How can this be prevented from happening again?
    • How can I regain reliable connectivity without having to redo days of work?

    The stability and predictability of your infrastructure are vital. I look forward to your urgent clarification and a lasting solution.

    Thank you in advance for your help.

    Sincerely,

    ------ DE version :

    KRITISCHES und WIEDERKEHRENDES Problem: Totaler Netzwerk-Konnektivitätsverlust auf KVM VPS (SSH "Connection refused" / Ping-Fehler) – Identisch mit dem Problem vom 26. Juni 2025 – Konnektivität bleibt auch nach Snapshot-Wiederherstellung unterbrochen!

    Hallo zusammen und Netcup-Support,

    Ich stehe vor einem äußerst schwerwiegenden und wiederkehrenden Problem mit meinen KVM-VPS-Instanzen, das die Stabilität meiner Dienste, insbesondere meines Mailservers, gefährdet.

    Problembeschreibung: Ich habe plötzlich die gesamte externe Konnektivität (SSH, HTTP(S) usw.) zu meinem KVM VPS: srv-apps.democrasite.com (IP 152.53.180.152) verloren. Von meinem Client-Rechner (iMac) führt jeder SSH-Versuch über die IP zu einem "Connection refused".

    Auf der VPS-Seite bestätigt (über Cockpit):

    • Der SSH-Daemon (sshd) läuft und lauscht korrekt auf Port 22 (IPv4 und IPv6).
    • Die UFW-Firewall ist aktiv und so konfiguriert, dass sie ALLOW IN Anywhere auf Port 22 zulässt (sowie alle notwendigen Ports für meine Web- und Mail-Dienste).
    • SSH-Logs zeigen, dass der Server lauscht und sogar Verbindungsversuche von einer älteren IP protokolliert hat, aber keine mehr von meiner aktuellen öffentlichen IP.
    • Am alarmierendsten: Vom VPS aus kann ich meine aktuelle öffentliche IP-Adresse (37.67.114.10) nicht anpingen. Ich erhalte 100% Paketverlust.

    Kontext des Problembeginns und Wiederauftretens: Dieses Problem trat auf, während ich die SSH-Konnektivität zwischen zwei Netcup-VPS-Instanzen (für das Cockpit Master/Slave-Setup) konfigurierte. Es ist wichtig zu beachten, dass kein VPS-Neustart durchgeführt wurde, nachdem die UFW-Konfiguration vorgenommen wurde, bevor die Blockade auftrat. Mein iMac konnte sich zunächst über SSH mit Passwort/Passphrase verbinden, aber nachfolgende erfolglose Versuche von meinem MacBook Pro (möglicherweise aufgrund eines Passphrase-Problems oder eines nicht konfigurierten SSH-Schlüsselpaares) folgten, und danach wurde die Konnektivität für alle meine Rechner unterbrochen.

    Dieses Problem ist eine exakte Wiederholung des Problems, das ich am 26. Juni 2025 auf einem anderen Netcup KVM VPS erlebt habe (siehe diesen Foren-Thread als Referenz: [Link zu Ihrem alten Foren-Thread]). Damals kam es zu derselben fehlenden Ping-Antwort und Netzwerkblockade, und die einzige Lösung war eine komplette Neuinstallation des KVM von einem frischen Image, um die Konnektivität wiederherzustellen.

    Warum dies ein Netcup-Infrastrukturproblem ist (gemäß meiner Analyse):

    • Der SSH-Daemon ist aktiv und UFW ist geöffnet, daher liegt das Problem nicht auf der OS-Seite.
    • Der Ping-Fehler vom VPS zu meiner IP beweist, dass die Verbindung vorgeschaltet blockiert wird, noch bevor sie meinen VPS erreicht.
    • Am kritischsten: Ich habe einen Snapshot meines VPS wiederhergestellt (aufgenommen kurz vor diesen Konfigurationen, als alles funktionierte). AUCH NACH DER SNAPSHOT-WIEDERHERSTELLUNG BLEIBT DAS PROBLEM BESTEHEN! Dies schließt definitiv jeglichen Software-Konfigurationsfehler auf dem VPS aus und bestätigt eine externe Blockade.

    Konsequenzen und Dringlichkeit: Ich habe mehrere Tage damit verbracht, diesen VPS zu konfigurieren, um meine Websites und vor allem meinen Mailserver darauf zu migrieren. Eine solche Netzwerkinstabilität, die sich identisch wiederholt, ist für einen so kritischen Dienst inakzeptabel. Sie bedeutet den Verlust von tagelanger Arbeit, falls ich wieder alles von Grund auf neu installieren muss.

    Fragen an die Community und den Netcup-Support:

    • Haben andere Benutzer diese Art von "mysteriöser" Netzwerk-Trennung erlebt, bei der Ping fehlschlägt und die einzige Lösung eine komplette Neuinstallation ist?
    • Verfügt Netcup über netzwerkbasierte Firewall- oder Überwachungssysteme, die IPs automatisch blockieren oder VPS-Instanzen bei "verdächtigem" Verhalten (z.B. wiederholte SSH-Versuche, dynamische UFW-Konfigurationen) isolieren könnten? Ist das Fehlen eines Neustarts nach solchen Vorgängen ein bekannter Auslöser?
    • Wie sehen die genauen Richtlinien hierzu aus und wie kann eine stabile Netzwerkkonnektivität für kritische VPS-Instanzen gewährleistet werden? Wie kann dies zukünftig verhindert werden?
    • Wie kann ich eine zuverlässige Konnektivität wiederherstellen, ohne tagelange Arbeit wiederholen zu müssen?

    Die Stabilität und Vorhersagbarkeit Ihrer Infrastruktur sind von entscheidender Bedeutung. Ich erwarte dringend eine Klärung und eine dauerhafte Lösung.

    Vielen Dank im Voraus für Ihre Hilfe.

    Mit freundlichen Grüßen,

  • token NOT SENT to my saved email address to complete MYr login

    Hallo zusammen,

    es muss ein Problem geben, ich erhalte meinen Token nicht mehr, um mich mit meinem Kundenbereich zu verbinden.

    Ich habe es mehrere Male versucht, aber nichts... Ich habe eine Adresse @google.fr registriert und Google ist nicht down.

    Handelt es sich um ein vorübergehendes Problem, das nur ein paar Minuten dauert?

    Ich danke Ihnen für Ihre Hilfe. =O


    ------------

    Hi everyone,

    There must be a problem, I don't receive my Token anymore to connect to my customer area.

    I've tried several times, but nothing... I've registered an address @google.fr and Google isn't down.

    Is this a temporary problem lasting a few minutes? :/

    Thank you

  • No ping after reboot by terminal

    After a long struggle, especially with this horrible VNC torture, no copy/paste, no scrollbars, incompatibility with my physical keyboard; forced to use my virtual keyboard (yes, I'm on MacOs with a Dell keyboard :) )...

    In short, we'll never know what happened? I reinstalled Debian fresh install, but still keyboard problems... Failure...

    Finally the ubuntu installer is nicer, I reinstalled a clean server, re-imported my Docker and apps backups, didn't forget to reboot between each important step and everything works fine.

    But really guys, do something about your VNC, I have other VPS at LWS and their virtual console is a hundred times better.

    Thanks to everyone who advised me.

    ::: Closed ::::

    Nach einem langen Kampf, vor allem mit diesem schrecklichen Folter-VNC, ohne Kopieren/Einfügen, ohne Aufzüge, Inkompatibilität mit meiner physischen Tastatur; gezwungen, meine virtuelle Tastatur zu benutzen (ja, ich bin auf MacOs mit einer Dell-Tastatur :) )...

    Kurz gesagt, wir werden nie erfahren, was passiert ist? Ich habe Debian fresh install neu installiert, aber immer noch Probleme mit der Tastatur... Fehlgeschlagen...

    Schließlich ist der Ubuntu-Installer netter, ich habe einen sauberen Server neu installiert, meine Docker-Backups und Apps neu importiert, den Neustart zwischen jedem wichtigen Schritt nicht vergessen und alles funktioniert korrekt.

    Aber wirklich, Leute, tut etwas für euren VNC, ich habe andere VPS bei LWS und ihre virtuelle Konsole ist hundertmal besser.

    Danke an alle, die mir Ratschläge gegeben haben.

    ::: Geschlossen ::::

    Übersetzt mit DeepL.com (kostenlose Version)

  • No ping after reboot by terminal

    @MickaelOF

    Yes, that's what I decided to do, having received no reply from Netcup all day :)

    What was bothering me was that I'd installed a number of docker applications, one in particular: docker::docmost, and that I already had quite a few articles written in there that I didn't want to lose.

    It took me a long time to configure all that.

    But thanks to Gemini, I went into rescue mode, backed up my entire docker installation + apps + docker volumes => scp -rp ... => one of my other vps and restarted a fresh install.

    Now I'll remember to reboot after each step and check that the network hasn't jumped.

    So, another day lost, but not totally, because I learned a lot in the end.

    Thanks for the help.

  • No ping after reboot by terminal

    NaN @MickaelOF @Virium

    Hi NaN, I can see that the server is refusing all connections.

    The inability to ping the gateway (152.53.180.1), even though the eth0 interface is configured correctly and the OUTPUT string in iptables is set to ACCEPT, indicates a deeper problem. The RTNETLINK answers: File exists error when starting the network service is the key here. It suggests that the network interface cannot be fully initialized by the kernel.

    This is way beyond my skills, I'm sending a verification request to Netcup, something has a problem above my instance.

    Thanks for your help :)

    ------ Translation -------

    Hallo NaN, ich sehe, dass der Server alle Verbindungen ablehnt.

    Die Unfähigkeit, das Gateway (152.53.180.1) anzupingen, obwohl die eth0-Schnittstelle korrekt konfiguriert ist und die OUTPUT-Kette von iptables auf ACCEPT steht, deutet auf ein tiefer liegendes Problem hin. Der Fehler RTNETLINK answers: File exists beim Start des Netzwerkdienstes ist hier der Schlüssel. Er deutet darauf hin, dass die Netzwerkschnittstelle nicht vollständig vom Kernel initialisiert werden kann.

    Das übersteigt meine Fähigkeiten bei weitem, ich sende eine Überprüfungsanfrage an Netcup, da etwas über meiner Instanz nicht stimmt.

    Vielen Dank für Ihre Hilfe an alle :)