Web Hosting

All-Inkl FTP-Zugang einrichten – Schritt-für-Schritt erklärt

Ich zeige dir Schritt für Schritt, wie ich im All-Inkl-KAS einen eigenen FTP-Nutzer anlege, den Pfad sauber setze und die Verbindung per FTPS absichere. So hast du in kurzer Zeit einen all-inkl ftp zugang, testest ihn direkt im Client und trennst Projekte durch eigene Logins sauber voneinander.

Zentrale Punkte

FTPS aktiv nutzen: verschlüsselte Dateiübertragung
Eigener Nutzer je Domain: klare Rechte
Pfad korrekt setzen: Verzeichniszugriff begrenzen
Ports beachten: 21/990 richtig eintragen
Passwörter stark wählen und dokumentieren

Was ist ein FTP-Zugang und wann nutze ich ihn?

Mit FTP übertrage ich Dateien zwischen Rechner und Server, zum Beispiel Theme-Ordner, Medien oder komplette Projektordner. Bei All-Inkl arbeite ich bevorzugt mit FTPS, damit die Verbindung verschlüsselt läuft und Zugangsdaten geschützt bleiben. Das hilft mir besonders, wenn ich Updates manuell einspiele oder schnell ein Backup vom Webspace ziehe. Für CMS-Installationen wie WordPress brauche ich häufig Zugriff auf die Dateien, um Probleme zu beheben oder Konfigurationen anzupassen. Ein separater Login pro Projekt trennt Zuständigkeiten, minimiert Fehlgriffe und hält die Übersicht schlank.

Vorbereitung im KAS: Struktur und Rechte planen

Bevor ich loslege, melde ich mich im KAS an und öffne die FTP-Übersicht, in der alle Logins gelistet sind. Anschließend prüfe ich die Ordnerstruktur der jeweiligen Domain, damit der Pfad des neuen Kontos exakt auf das richtige Verzeichnis zeigt. So verhindere ich, dass ein Nutzer versehentlich in andere Ordner schreiben kann. Für Projekte mit Staging-Verzeichnissen richte ich eigene Logins ein, die nur dorthin führen. Eine kurze Skizze auf Papier oder im Passwort-Manager spart später Zeit, weil ich Rechte und Ordner klar dokumentiere. Für ergänzende Grundlagen verweise ich bei Bedarf auf diese FTP-Anleitung, wenn ich ein schnelles Auffrischen brauche.

FTP-Nutzer anlegen: Schritt-für-Schritt im KAS

In der FTP-Übersicht klicke ich auf „Neuen Nutzer anlegen“ und fülle das Formular mit einer klaren Beschreibung, etwa der Domain, aus. Als Pfad setze ich das Zielverzeichnis der Website, damit der Zugang sauber begrenzt ist und keine fremden Ordner sichtbar werden. Für das Passwort nutze ich einen Generator und speichere es in meinem Passwort-Manager, um hohe Entropie und Nachvollziehbarkeit zu sichern. Den Benutzernamen erstellt All-Inkl automatisch, wodurch Verwechslungen vermieden werden. Nach dem Speichern steht das Konto sofort bereit und ich starte den Verbindungscheck im bevorzugten Client.

FTPS einrichten und Verbindung testen

Zum Testen öffne ich meinen Client, trage Server, Benutzername und Passwort ein und wähle als Protokoll FTPS. Für unverschlüsseltes FTP gilt Port 21, für FTPS nutze ich Port 990; die verschlüsselte Variante hat Vorrang. Nach dem ersten Login prüfe ich, ob das Root-Verzeichnis stimmt und ob ich Dateien anlegen, umbenennen und löschen kann. Bei wiederholten Fehleingaben sperrt All-Inkl die IP zeitweise, deshalb tippe ich die Daten sorgfältig ein. Falls die Verbindung zickt, hilft oft ein kurzer Wechsel zwischen explizitem und implizitem FTPS in den Client-Einstellungen.

Explizites vs. implizites FTPS und Zertifikate verstehen

Bei explizitem FTPS startest du die Verbindung über den klassischen Kontrollkanal und hebst anschließend die Verschlüsselung per AUTH TLS an. Viele Clients setzen diese Variante auf Port 21 voraus. Implizites FTPS startet dagegen direkt verschlüsselt (typisch Port 990). Funktional bist du mit beiden sicher unterwegs – entscheidend ist, dass dein Client das Serverzertifikat prüft. Ich achte darauf, dass der eingetragene Host-Name zum Zertifikat passt, bestätige es bei der ersten Verbindung bewusst und speichere die Entscheidung. Bei Zertifikatshinweisen (neues Zertifikat, Ablauf) kontrolliere ich die Details statt sie routiniert wegzuklicken.

Aktiver vs. passiver Modus: Firewalls, NAT und Stabilität

In Büros, hinter NAT-Routern oder in streng konfigurierten Firewalls nutze ich konsequent den passiven Modus. Der Server weist dabei den Datenkanal zu, was Verbindungsabbrüche deutlich reduziert. Zeigt der Client Fehler wie „425 Can’t open data connection“, deutet das oft auf einen Blocker im Netzwerk hin. Dann stelle ich auf passiv um, aktiviere falls vorhanden „passive IP ermitteln“ und starte einen frischen Test. Stabilität geht vor Geschwindigkeit – eine dauerhaft saubere Verbindung spart am Ende mehr Zeit als ein paar parallele, aber fehleranfällige Sessions.

Pfad-Strategien: Chroot, Staging und Ordnung

Der gewählte Pfad bestimmt, was der Nutzer überhaupt sieht. Ich arbeite deshalb mit einem chroot-ähnlichen Ansatz: Der Login landet direkt im Projektverzeichnis und sieht darüberliegende Ordner erst gar nicht. Für Staging-Setups lege ich eigene Unterordner an (z. B. /project/stage/) und weise separate Logins zu. So bleibt klar, welche Umgebung bearbeitet wird. Wenn ich später umziehe oder aufräume, genügt es, den Pfad im KAS anzupassen – der Nutzername kann bleiben, die Berechtigungen passen sich am Zielpfad an.

Berechtigungen, Transfer-Modi und Dateikonsistenz

Beim Upload setze ich den Transfer-Modus in meinen Clients standardmäßig auf „Binary“. Automatische ASCII-Erkennung liegt häufig daneben und kann Binärdateien beschädigen. Ich achte außerdem darauf, Zeitstempel zu erhalten, damit Synchronisationen sauber funktionieren. Rechte wie 644/755 sind in vielen Setups solide Voreinstellungen; weiche ich davon ab, dokumentiere ich es im Projekt-Notizfeld meines Passwort-Managers. Trifft eine „Permission denied“-Meldung auf, prüfe ich zuerst Pfad und Rechte im Zielverzeichnis, bevor ich an Client-Fehler denke.

Praktische Client-Workflows: Profile, Vergleiche, Limits

Im Site-Manager von FileZilla lege ich pro Projekt ein Profil mit klarer Bezeichnung an, setze FTPS und den genauen Pfad. Für größere Transfers reduziere ich zugleich die gleichzeitigen Verbindungen (z. B. 2–3), um Timeouts zu vermeiden. Die Funktion Verzeichnisvergleich hilft mir, lokale und serverseitige Ordner optisch zu prüfen, bevor ich synchronisiere. In Cyberduck nutze ich Lesezeichen mit vordefiniertem Protokoll und Pfad, in WinSCP wiederum die Synchronisation im „Spiegeln“-Modus samt Trockenlauf, damit ich sehe, was sich ändern wird. Wann immer möglich, aktiviere ich Keep-Alive, um kurze Unterbrechungen abzufangen, ohne die Session neu aufzubauen.

Automatisieren: wiederholbare Abläufe und Backups

Für wiederkehrende Aufgaben – etwa nächtliche Datei-Backups oder das Ausrollen eines Build-Ordners – setze ich auf automatisierte Sessions. Viele Clients können Profile skriptfähig ansprechen. Ich definiere klare Upload-Ordner, filtere temporäre Dateien (z. B. node_modules, Cache, .map) und protokolliere die Durchläufe. Bei sehr großen Projekten lade ich komprimierte Archive hoch und entpacke sie serverseitig, weil das oft schneller ist als tausende einzelner Dateien zu transferieren. Zusätzlich lasse ich bei kritischen Deployments eine kurze Prüfsumme oder Dateiliste generieren, damit ich sicherstelle, dass wirklich alle Dateien angekommen sind.

Teamarbeit: Naming, temporäre Zugänge und Rotation

In Teams vergebe ich sprechende Nutzernamen und Beschreibungen („projektA-dev“, „projektA-agentur“), damit klar bleibt, wer wo arbeitet. Externe erhalten temporäre Zugänge, die ich nach Abschluss wieder lösche. Passwörter rotiere ich bei Rollenwechseln oder verdächtigen Aktivitäten. Dokumentation ist Pflicht: Ich halte pro Zugang fest, wem er gehört, welches Verzeichnis er sieht und wann er zuletzt aktualisiert wurde. So lassen sich Fragen schnell klären und Zugriffe gezielt entziehen, ohne andere Projekte zu beeinträchtigen.

Typische Fehlerbilder tiefer analysiert

Viele Probleme wiederholen sich in Varianten. Bei 530 Login authentication failed prüfe ich Benutzername/Passwort und ob der Account im KAS wirklich aktiv ist. Meldet der Client 421 Too many connections, reduziere ich parallele Verbindungen oder warte, bis alte Sessions sauber beendet sind. Ein TLS-Handshake-Fehler deutet oft auf ein blockierendes Sicherheitsprogramm hin – hier hilft es, die FTPS-Optionen zu prüfen oder testweise den Gegenmodus (explizit/implizit) zu wählen. Bei 425/426-Meldungen wechsle ich in den passiven Modus. Das klassische 550 Permission denied löse ich durch Pfadkorrektur und Rechtecheck. Treten Zertifikathinweise auf, vergleiche ich Hostname und Gültigkeitszeitraum und bestätige nur, wenn beides stimmig ist.

FTP-Client auswählen: FileZilla, Cyberduck, WinSCP

Ich arbeite oft mit FileZilla, weil ich damit mehrere gleichzeitige Transfers steuern und Server-Profile sauber speichern kann. Cyberduck punktet mit einer aufgeräumten Oberfläche und solider FTPS-Unterstützung, was für Einsteiger angenehm ist. Wer Windows nutzt und gerne skriptet, fühlt sich mit WinSCP wohl, da Automatisierungen und Synchronisationen leicht gelingen. SFTP nutze ich bei All-Inkl in der Regel nicht, da FTPS vorgesehen ist und zuverlässig läuft. Wichtig ist am Ende, dass der Client Zertifikate prüft und Verzeichnisse korrekt synchronisiert, ohne versehentliche Überschreibungen zu riskieren.

Domain-spezifische Zugänge: Sicherheit und Ordnung

Ich erstelle je Domain einen eigenen Zugang, damit Rechte sauber getrennt bleiben und ich Änderungen gezielt nur am richtigen Projekt vornehme. Getrennte Logins senken das Risiko, Dateien versehentlich in ein anderes Projekt zu kopieren. Zusätzlich protokolliere ich, welcher Zugang welchem Teammitglied gehört, damit ich bei Nachfragen schnell reagieren kann. Für E-Mail-Setups ziehe ich manchmal parallel den Webmail-Leitfaden heran, um Konten konsistent zu verwalten; dafür nutze ich diese Seite zu Webmail einrichten. So bleibt die Übersicht klar, und ich kann Zugänge bei Bedarf gezielt sperren, ohne andere Projekte zu berühren.

Performance und Stabilität bei großen Transfers

Um lange Uploads stabil zu halten, arbeite ich mit Warteschlangen und setze Limits für parallele Transfers. Eine moderate Anzahl gleichzeitiger Verbindungen belastet den Server weniger und verhindert Timeouts. Ich aktiviere das automatische Wiederaufnehmen unterbrochener Übertragungen und lasse fehlerhafte Dateien am Ende der Queue erneut versuchen. Wenn Bandbreite knapp ist, aktiviere ich im Client eine leichte Drosselung, damit die Verbindung nicht kollabiert. Außerdem achte ich auf die Reihenfolge: erst Strukturen (Ordner) anlegen, dann kritische Dateien, zuletzt große Assets – so bleibt die Seite während eines Deployments möglichst lange funktionsfähig.

Typische Fehler und schnelle Lösungen

Fehlt die Verbindung, prüfe ich zuerst Host, Port und Protokoll, denn falsche Einträge sind der Klassiker. Stimmt der Pfad nicht, sehe ich leere Ordner oder unerwartete Inhalte, weshalb ich den eingestellten Root sofort nachbessere. Erhalte ich eine „Permission denied“-Meldung, liegt meist ein falscher Pfad oder ein fehlendes Schreibrecht im Zielordner vor. Bei zu vielen Fehlversuchen greift oft eine temporäre IP-Sperre, also warte ich kurz oder korrigiere die Zugangsdaten sorgfältig. Zeigt der Client Zertifikats-Hinweise, bestätige ich das richtige Zertifikat dauerhaft, damit Folgeverbindungen reibungslos laufen.

FTP und WordPress: Updates, Backups, Notfälle

Für WordPress sichere ich vor größeren Änderungen stets die Dateien via FTP, damit ich bei Problemen schnell zurückrollen kann. Auch ein manuelles Theme-Upload oder ein Plugin-Update erledige ich zügig, wenn das Dashboard streikt. In Notfällen ersetze ich fehlerhafte Dateien direkt auf dem Server und nehme die Seite rasch wieder online. Parallel brauche ich oft Datenbankzugriff; Details dazu hole ich mir im Leitfaden zu Datenbank-Zugang mit phpMyAdmin. So kombiniere ich Backup, Dateiupload und Datenbankpflege zu einem schlanken Rettungsplan.

Vergleich: FTP-Bedienung bei gängigen Hostern

Um die Bedienung einzuordnen, schaue ich auf Einrichtung, Sicherheit und Handhabung bei beliebten Anbietern. All-Inkl wirkt ausgewogen, weil FTPS flott läuft und die KAS-Maske übersichtlich bleibt. Viele schätzen klare Pfadvorgaben, damit ein Login nicht zu weitreichende Rechte erhält. Der folgende Überblick zeigt Stärken bei Übertragungsschutz und Komfort, damit du die Einordnung schneller vornehmen kannst. Ich nutze die Tabelle als grobe Orientierung, entscheide aber am Ende nach eigenen Anforderungen und Workflows.

Anbieter	Übertragungsschutz	Bedienung	Hinweis
webhoster.de	★★★★★	★★★★★	Schnelle Einrichtung, klare Rechte
All-Inkl.com	★★★★☆	★★★★☆	FTPS zuverlässig, KAS übersichtlich
SiteGround	★★★★☆	★★★★☆	Gute Clients-Profile, flotte Transfers

Best Practices: Passwörter, Protokolle, Dokumentation

Starke Passwörter mit hoher Länge und gemischten Zeichen sind Pflicht, ich generiere sie und speichere sie sicher. Für kritische Projekte rotiere ich die Kennwörter in festen Abständen und protokolliere Änderungen sauber. Wo verfügbar, aktiviere ich 2FA für das KAS, damit unbefugte Logins blockiert bleiben. In den Clients setze ich FTPS konsequent und vermeide unverschlüsseltes FTP, damit Protokolle keine Klartextdaten schicken. Außerdem halte ich ein kurzes Änderungslog fest, damit ich später genau weiß, wann ich welche Datei ersetzt habe.

Kurze Zusammenfassung für Eilige

Ich lege im KAS pro Projekt einen FTP-Zugang an, setze den Pfad exakt auf das Domain-Verzeichnis und sichere die Verbindung mit FTPS. Der Test im Client zeigt mir sofort, ob Rechte, Ports und Zertifikat passen. Bei Fehlern prüfe ich zuerst Host, Protokoll und Zugangsdaten, bevor ich weitere Ursachen abklopfe. Für WordPress halte ich Dateien und Datenbank im Blick, damit Backups und Rollbacks jederzeit möglich bleiben. Mit getrennten Logins, starken Kennwörtern und sauberer Dokumentation bleibt die Pflege übersichtlich und sicher.