Haben Sie sich auch schon über die mangelnde Funktionalität und die hakelige Konfiguration des in den IIS enthaltenen FTP-Servers geärgert? Würden Sie gern eine komfortablere Alternative einsetzen, die nicht nur mehr Möglichkeiten bietet, sondern auch noch kostenlos ist? Dann lesen Sie bitte weiter…
Seit rund 10 Jahren betreibe ich neben Linux-basierten Managed-Servern auch einige Windows Rootserver. Nicht etwa, weil ich Windows als Webserverplattform so überzeugend fände, sondern vielmehr, weil ich auf der Basis von Microsoft-Produkten programmiere. Den komplexeren Teil meiner Webprojekte erstelle ich auf der Basis von ASP, respektive ASP.NET. Und dies wiederum nicht, weil ich ASP für besser als PHP hielte, sondern schlicht, weil ich auch Desktop-Anwendungen, die interoperabel zu den Office-Produkten aus dem Hause MS sein müssen, erstelle und von daher das Knowhow einfach da ist. Ich bin kein leidensbereiter Glaubenskrieger, sondern gnadenloser Pragmatiker.
Von Beginn an habe ich allerdings bei den Windows-Servern den IIS ausschließlich als Webserver genutzt. Mailserver (obschon prinzipiell Teil der IIS) war lange Zeit Ipswitch iMail (ein ganz schöner preisintensiver Geselle) und ist jetzt MailEnable. Dieser sogar, weil er nur noch zum scriptgesteuerten Versand von Mails benötigt wird, in der kostenlosen Standardedition. Als FTP-Server verwende ich seit Jahren den Filezilla-Server, den ich Ihnen im weiteren Verlauf dieses Artikels näher bringen möchte.
Warum verwende ich nicht den FTP-Server aus den IIS?
Zu Beginn meiner Windows Rootserver-Karriere gab es einen ganz einfachen Grund, der die IIS als FTP-Server disqualifizierte. Bis einschließlich zur Version 5 war der IIS nicht in der Lage, die Basisverzeichnisse einzelner User voneinander zu isolieren. Im Grunde eine vollkommene Unmöglichkeit, wenn man nicht grenzenloses Vertrauen in seine User setzen will. Erst seit der Version 6, also seit Windows Server 2003, ermöglichen es die IIS die FTP-Benutzer voneinander auf verschiedene technische Weisen zu isolieren. Die potenziell sicherste Methode beruht auf der Authentifizierung mittels Active Directory, woran man bereits erkennen kann, dass die Philosophie von Microsoft in Sachen FTP-Zugriff eher auf Intranet-Lösungen, denn auf FTP-Server in the wild abzielt.
Da die Benutzerverwaltung für den FTP-Server Teil der allgemeinen Benutzerverwaltung des OS ist, schlagen Sicherheitslücken im Betriebssystem natürlich nicht nur auf diesen Dienst durch, sondern es entsteht umgekehrt ein erhöhtes Risiko für die Serversicherheit insgesamt. Immerhin ist FTP vor über 30 Jahren gerade als einfaches System für den lesenden und schreibenden Zugriff auf Serversysteme entwickelt worden. FTP ist quasi per definitionem ein Sicherheitsrisiko. Microsoft selber empfiehlt denn auch, wenig verwunderlich, den FTP-Dienst abzuschalten, wenn er nicht unbedingt benötigt wird.
Ein weiteres Manko des FTP-IIS besteht in der Benutzer-Isolation an sich. Zum einen ist diese wenig komfortabel einzurichten, was verschmerzbar ist. Zum anderen jedoch hat die Isolationsmöglichkeit nicht den Benutzer als Ausgangsgröße vor Augen, sondern die FTP-Site. Vereinfacht ausgedrückt: Ich kann einen „isolierten“ Benutzer nur innerhalb einer FTP-Site einrichten, die auch noch einem bestimmten, ms-vorgegebenem Verzeichnisaufbau genügen muss.
Inwiefern ist Filezilla anders?
Filezilla-Server ist ein kompaktes Progrämmchen mit nur wenigen Einstellmöglichkeiten, die jedoch den FTP-IIS mühelos in den Schatten stellen. Es ist einfach zu installieren und ebenso einfach zu konfigurieren. Da keine Einbindung in die Benutzerverwaltung des Betriebssystems stattfindet, schlagen dortige Sicherheitsprobleme nicht auf Filezilla durch, vice versa.
Das Killerargument ist jedoch, dass Filezilla mit dem Benutzer im Vordergrund an die Sache herangeht. Jeder Benutzer kann Zugriff auf beliebig viele Verzeichnisse nehmen und Basisverzeichnisse (Homedirectories) müssen nicht unter einem gemeinsamen Root liegen, wie im IIS. Durch diese Flexibilität ermöglicht der Filezilla-Server die Definition aller denkbaren FTP-Zugriffskonstrukte. Sogar dem Datenbankprogrammierer Müller geben wir mit Filezilla einen Zugriff auf das Datenbankverzeichnis des Servers, das selbstverständlich aus Sicherheitsgründen völlig außerhalb der Webserver-Hierarchie liegt und dessen Inhalt vollständig per System-DSN verfügbar ist. Nicht auszudenken, was passierte, wenn man den Müller an die Website-Daten ließe oder umgekehrt den Grafiker an die Datenbanken. Der Oberadministrator bekommt einen Komplettzugriff auf das Hauptverzeichnis der Daten-Festplatte und Praktikant Schulte wird auf das Bilderverzeichnis begrenzt, in das er Illustrationen für den CMS-Content hochladen darf. Bislang bin ich auf noch keine Zugangskombination gestoßen, die ich mit Filezilla nicht hätte anbieten können.
Wenn ich jetzt Ihr Interesse an Filezilla geweckt haben sollte, lesen Sie einfach weiter. Im Folgenden erläutere ich kurz, aber ausreichend, denn das Programm ist leicht durchschaubar, Installation und Konfiguration. Haben Sie Bedenken, ob Filezilla auch für Ihren Windows-Server das Richtige ist, möchte ich Sie ermutigen, ihn einfach mal auszuprobieren. Er ist innerhalb von fünf Minuten installiert und konfiguriert und bei Nichtgefallen genauso schnell wieder weg. Für die Testdauer müssen Sie natürlich den FTP-IIS kurzzeitig deaktivieren, was aber ebenso mit zwei Klicks wieder rückgängig gemacht ist.
Eine Zielgruppe habe ich noch vergessen. Nämlich all diejenigen unter Ihnen, die einen FTP-Server aufsetzen wollen, aber kein Windows-Server-Betriebssystem einsetzen. Auch für Sie ist das Produkt interessant, denn Filezilla setzt kein Server-OS voraus, sondern läuft mit der gleichen Funktionalität auch unter Windows Vista, XP und 2000. Dann brauchen Sie nur noch einen Account bei DynDNS, den entsprechenden Updater, sowie eine Portfreigabe in Ihrer Fritzbox und schon sind auch Sie ready to go.
Installation und Konfiguration des Filezilla-Server
Nachdem Sie sich das nur rund 2,5 MB Installationspaket von der Projektsite heruntergeladen haben, starten Sie es mit einem beherzten Doppelklick. Auch wenn die Installation nur wenig Interaktion verlangt, lohnt es sich, nicht einfach gewohnheitsmäßig auf Next zu klicken, obschon die Default-Einstellungen durchweg sinnvoll gewählt sind. Alle Eiligen dürfen also ruhig durchklicken…
Im Normalfall werden Sie wohl eher keinen Wert auf den Sourcecode legen, so dass Sie diese Standardauswahl in der Tat einfach mit „Next“ bestätigen können. Als nächstes treffen Sie die Auswahl, ob auf dem Server das Interface gestartete werden soll, sobald sich ein User anmeldet. Diese Einstellung ist im Grunde Geschmackssache. Soll das Interface nicht automatisch starten, was der Auswahl „Start manually“ gleichkäme, kann man allerdings auch nicht verfolgen, was der per FTP angemeldete User auf dem Server gerade anstellt. Möglicherweise möchte man dies aber, natürlich nur bei Homeservern, doch wissen. Ich installiere standardmäßig die erste Auswahl.
Eine wesentliche Konfigurationsmöglichkeit ergibt sich im folgenden Schritt. Sie müssen entscheiden, ob Filezilla als Windows-Dienst installiert und mit Windows gestartet werden oder ob Filezilla zwar als Dienst, aber nicht automatisch gestartet werden soll. Ein Relikt aus vergangenen Betriebssystemarchitekturen dürfte die dritte Möglichkeit, den Filezilla-Server nicht als Dienst zu installieren, sondern per Autostart-Eintrag als normale Anwendung zu starten, sein.
Ist die Installation gelaufen, wird im Standard das Filezilla-Interface gestartet. Hier haben Sie die Möglichkeit, sich auch mit entfernten Filezilla-Servern zu verbinden. Sie benötigen die Adresse des Remoteservers, sowie das hoffentlich dort vergebene Passwort. Da zur Nutzung dieser Option allerdings auf dem Remotesystem zusätzlich der Port 14147 geöffnet werden muss, empfehle ich diese Vorgehensweise nicht. Jeder offene Port stellt ein zusätzliches Sicherheitsrisiko dar. Verbinden Sie sich per Remote-Desktop-Verbindung mit Ihrem Windows-Rootserver und starten das Filezilla-Interface dann dort lokal. Das ist nicht langsamer, sicherer und die Remote-Desktop-Verbindung haben Sie ohnehin.
Um jetzt den Server sinnvoll in Betrieb zu nehmen, ist es erforderlich, mindestens einen User zu definieren. Haben Sie eine Vielzahl unterschiedlicher User anzulegen, mag es für Sie Sinn machen, zunächst eine oder mehrere Gruppen mit den jeweiligen Zugangsparametern anzulegen und hernach lediglich noch die neuen User den schon vorhandenen Gruppen zuzuordnen. Da der User die Berechtigungsstruktur der Gruppe übernimmt, spart man sich auf diese Weise einiges an Klickarbeit und vermeidet Fehler. Außerdem schlagen spätere Änderungen an der Gruppendefinition automatisch auf alle User durch. Da die Gruppendefinition prinzipiell zur Userdefinition identisch ist, zeige ich hier lediglich die Neuanlage eines Benutzers.
Dieser Vorgang ist nahezu selbsterklärend und unterliegt auch nur wenigen Schritten. Hat man per „Add“ einen Usernamen hinzugefügt, kann man das Konto aktivieren (Enable Account) und ein Passwort vergeben. Verwalter großer User-Mengen notieren sich noch etwas unter Description (Der Picklige aus der Cafeteria zum Beispiel). Interessant mag an dieser Stelle noch der Hinweis auf die Möglichkeit sein, Secure-FTP zu erzwingen (Force SSL for user login). Sind Sie bis hierhin gekommen, sind Sie schon fast durch. Jetzt legen Sie unter „Shared Folders“ noch fest, welche Zugangsberechtigungen und -möglichkeiten der neue Benutzer bekommen soll.
Das zuerst angelegte Verzeichnis wird als Homedirectory, also Startpunkt des Benutzers auf dem FTP-Server definiert, kann aber nach Anlage weiterer Pfade ducrh Klick auf „Set as home dir“ leicht wieder geändert werden. Zu jedem Pfad besteht die Möglichkeit, genau vorzugeben, was der Benutzer darin machen können dürfen soll. Sie entscheiden, ob er Dateien lesen, schreiben, löschen oder erweitern (wichtig bei abgebrochenen Uploads) können soll. Auch bei den Verzeichnisrechten differenzieren Sie nach „Erstellen“, „Löschen“, „Inhalte auflisten“, sowie über die Anwendung dieser Rechtekonstruktionen auf etwaige Unterverzeichnisse.
Wollen Sie einem Benutzer Zugriff auf Verzeichnisse geben, die nicht unterhalb des definierten Home-Verzeichnisses liegen, so stellt auch so etwas Filezilla nicht vor Probleme. Dem frei zu gebenden Verzeichnis wird einfach ein Alias verpasst. Dadurch erscheint das Directory im Virtual Filesystem des Filezilla als Unterverzeichnis zum Homedirectory.
Beispiel:
Das Homedirectory ist d:\upload\
Zusätzlich freigeben wollen Sie aber auch c:\geheimedaten
Dann definieren Sie das in den Shared Folders des Filezilla so: Directory: c:\geheimedaten > Alias: d:\upload\geheimedaten.
Auf diese Weise erscheint der eigentlich auf C: liegende Ordner als ein Unterverzeichnis des Homedirectory.
Das kann man prinzipiell mit beliebig vielen Verzeichnissen so handhaben. Aufpassen sollte man allerdings, dass man dadurch keine rekursiven Freigaben, also Freigaben, die eigentlich schon in anderen Freigaben enthalten sind, erzeugt. Das könnte zwar der Filezilla-Server handlen, aber möglicherweise der FTP-Client Ihres Benutzers nicht.
So, Ihr Filezilla-Server läuft jetzt wie eine Eins und schon bald werden Sie ihn nicht einmal unter Gewaltandrohung oder für Geld gegen den schlappen Gesellen aus den IIS tauschen wollen. Fragen können Sie gern im Kommentarbereich loswerden. Eventuell schreibe ich auch noch einen Beitrag zu den übrigen Konfigurationsmöglichkeiten, sollte sich der Bedarf abzeichnen. Jetzt erst einmal viel Vergnügen mit einem FTP-Server, der diese Bezeichnung tatsächlich verdient. ™
0 Antworten zu „Filezilla-Server als Alternative zu den FTP-Diensten im IIS“
— was ist Deine Meinung?
Hallo,
ich verwende den FfileZilla Server auch schon seit längerem. Allerdigns habe ich seit dem Umstieg auf W2k8 mit IIS7.5 das Problem eine Verbindung von Server zu SErver herzustellen. Konkret: FilZilla-Client auf W2K8 auf FileZilla-Server auf anderem W2K8.
Der Client meldet sich zwar am FTP-server korrekt an, gibt aber die Fehlermeldung zurück, dass das Inahltsverzeichnis nicht lesbar ist (Fehler: 425 Can’t open data connection).
Es ergbit sich auch keine Änderung, wenn ich die Option – Server zu Server Verbindung verbieten deaktiviere.
Auch die FTP-Verbindung über den Datei-Exporer funktioniert mit gleichen Symptomen nicht.
Wenn ich dasselbe von einem Windows-Client-Betriebssystem aus mache (WinXP) funktioniert es wunderbar. Brauche aber eine Server zu Server Verbindung.
Hat jemand eine Idee? Liegt es evtl. am FilZilla-Client. Mit CyberDuck als FTP-Client bekomem ich eine Verbindung hin.
Danke für die Hilfe im Voraus
MfG Wilfried
Hallo!
Das ist eine sehr schöne und ausführliche Anleitung.
Ich habe jedoch eine Frage:
Welche IP-Adresse und welchen Port muss ich angeben, wenn ich auf den Server von einem anderen Gerät in meinem Netzwerk zugreifen möchte??
Ich bin am verzweifeln!
MfG. Simon
Hi,
wir haben auch Filezilla auf einem Windows 2008 R2 Server laufen. Leider haben wir keine Zugriffsrechte auf Dateien die wir per FTP uploaden?!
Es gibt für diese Files & Ordner keine Owner, aber warum? So viel kann man da doch nicht falsch machen?!?! Hast du einen Tipp?
Schöne Grüße,
Manuel
Vielen Dank für die super Erklärung. Habs einfach nicht hingekriegt, Shares von 2 verschiedenen Platten freizugeben. Dank deiner Erklärung hats geklappt! thx
Mich würde interessieren, wie man den FileZilla Server absichert, läuft nach der Installation mit dem User „Lokales System“, was ja nicht so schön ist. Welche Berechtigungen benötigt ein „Filezilla“ User?
Hallo,
erstmal vielen Dank für die Anleitung Herr Petereit!
Die hat mir ja schon geholfen. Auch weil ich ja auf diesem Weg an den Hinweis von Phillip kam. @Phillip: Auch Dir vielen Dank für den Link nach huegele.de! Klappt super dank hervorragender Anleitung!
Danke euch beiden!
@Oliver: Ich sprach nicht von „Vorteil“, ich sprach von „Besonderheit“. Unter Windows halte ich die Vorgehensweise mittels System-DSN für die sicherste, die mir Windows anbieten kann.
Wenn Du es schaffst, den Server entsprechend zu manipulieren, könntest Du Zugriff auf die ODBC-Datenquelle nehmen. Da hast Du Recht. Andererseits. Wenn man es schaftt, irgendwas zu manipulieren, kann man immer Einfluss oder Zugriff auf irgendwas nehmen.
„Wie das bei Windows ist, weiß ich nicht…“ Hehe, der war gut. Wie das bei Windows ist, wissen wir doch alle 😉
Ich sehe übrigens gar keine Meinungsverschiedenheit. Wir reden schlicht über unterschiedliche Aspekte.
Sobald ich es schaffe, eine Datei auf dem Server zu manipulieren und für meine Zwecke zu nutzen, hab ich doch dann automatisch vollen DB Zugriff? Bei mehreren Servern muss die DSN doch auch hin und her geschickt werden.
Auch wenn sie nicht mehr plain auf dem Webspace liegen, kommt man dann doch über die Registry dran!? Bei Apache kann ich ja ganz klar festlegen, dass die Datei von aussen nicht angezeigt werden kann.
Also was ist da jetzt der Vorteil?
Naja und mit den Ports. So lange die Programme sicher sind, können auch beliebig viele Ports offen sein. Ein Nachteil hat das unter „guten“ Betriebssystemen nicht. Wie das bei Windows ist, weiß ich nicht.
@Thomas und Oliver: Sorry, ich hätte exakter sein sollen:
Ich nutze stets System-DSN, so dass in der unter Umständen frei lesbaren 😉 Konfigurationsdatei nur noch der Name des DSN im Klartext übergeben wird. Eine absolute Besonderheit eines Windowsserver ist das.
Mit keinen Port öffnen meinte ich in der Tat, dass kein zusätzlicher Port geöffnet wird. Unter Anwendung der entsprechenden Policy ist der FTP-Port nämlich bei aktiven IIS ohnehin geöffnet. Mein Warnhinweis im Text bezog sich auf die dann zusätzliche Öffnung des Administrationsports 14147. Was ich wie gesagt nicht empfehle.
Ähm, wo soll das DB Passwort denn sonst stehen? Das ist auch kein Sicherheitsrisiko, weil die Daten ja nicht von aussen zugänglich sind.
Andere Methoden wären eine lokale Authentifizierung über den Benutzer oder indem man die DB an localhost bindet. Das ist aber keinesfalls sicherer. Eher im Gegenteil. Wenn ich in ein System einbreche und es schaffe, eine Datei anzulegen habe ich damit auch sofort vollen DB Zugriff, also zwei für eins. DSN ist nur eine andere Schreibweise – Sicherheitstechnisch ist es egal, ob die Zugangsdaten jetzt übereinander oder nebeneinander stehen. Daher versteh ich das Argument nicht. Es gibt auch in PHP die Möglichkeit DSN zu verwenden, macht aber keiner, weil es keinen wirklichen Vorteil bietet.
Das mit dem lauschenden Ports hat mich auch gewundert, aber ich tippe mal, er meinte, dass kein Port zusätzlich geöffnet wird, weil der ja eh schon offen ist. Ein Serverdienst muss an einem offenem Port lauschen, weil FTP lokal zu nutzen ist recht sinnlos. Wenn das Programm, was da dran hängt sicher ist, kann es auch ein Dutzend Ports öffnen, von daher hab ich das Argument im Artikel auch schon nicht verstanden. *schulter-zuck*
Das war keine Häme, ich will auch keinesfals Deinen Artikel schlecht reden. Ein rein lobendes Kommentar würde zwar dem Ego gut tun 😉 aber den etwas unbedarfteren Lesern, die eine Screenshot Anleitung benötigen, vielleicht nicht zum Nachdenken anregen…
Es ist ziemlich üblich, das Webanwendungen DB Passwörter in irgend einem Config File stehen haben. Ich kenne ASP nicht, aber unter PHP wirds schwer, sich auf einen sicher konfigurierten MySQL Server zu connecten ohne diese Daten.
„Ports werden übrigens auf dem Windowsserver durch die Installation des Filezilla nicht geöffnet.“
Da ich mich nicht so mit Windows Server Anwendungen auskenne, würde ich das gerne bißchen besser verstehen.
Ein Server Dienst ohne lauschenden Port?
Uargh. DB-Passwort irgendwo im Quelltext? Jetzt bekomme ICH Pickel 😉 Datenbankanbindung gibt´s bei mir nur per DSN (unter Windows).
Also ich sag es mal so. Wenn die Handelsübliche Webseite eine DB Anbindung hat und das DB Passwort irgendwo im Quelltext steht, dann definitiv JA.
Ich selber benutze seit 4 Jahren nur noch Fish. Aber so viel Luxus gibt es für Windows nicht. 🙁
Ich gebe den Kritischen Recht, dass der Betrieb eines ungesicherten, öffentlichen FTP-Servers ein Risiko ist. Darauf habe ich meines Erachtens sogar mehrfach hingewiesen, auch Secure-FTP als Option ist erwähnt. Aufgrund der üblichen Textlängen konnte eine derart ausführliche Abhandlung speziell zum Thema SSL, wie sie Huegele.de dankenswerterweise liefert, nicht mehr angefügt werden. Andererseits kann aber kein Artikel alle Aspekte eines Produktes abdecken, ohne zum Buch zu werden.
Die Häme hinsichtlich desjenigen, der eine Screenshotanleitung benötigt, kann ich nicht nachvollziehen. Es ist doch sicherlich sinnvoll, zunächst anhand eines Artikels wie diesem hier, den Aufbau der Anwendung und den Ablauf der Installation einschätzen zu können. Ich zumindest kenne niemanden, der den diesbezüglichen Aufwand frei assoziierend nach dem Motto „Handbuch lesen ist feige“ schätzt. Professionell würde man sowas wohl auch nicht bezeichnen dürfen.
Ports werden übrigens auf dem Windowsserver durch die Installation des Filezilla nicht geöffnet.
Nochmal gezielt @Oliver: Ja, sensible Daten ohne was übers Netz zu senden ist unverantwortlich. Ich habe aber dazu auch nicht aufgerufen. Generell könnte man noch mit einiger Berechtigung durchaus die Frage stellen, ob die handelsüblichen Websitedateien sensible Daten sind.Sowas muss jeder für sich selbst entscheiden.
@Helen: Du meinst mit Gewissheit den Filezilla-CLIENT. Hier geht es aber um den Server.
@Thomas: Darum sei auch hier auf eine brauchbare Anleitung verwiesen, wie man o.g. Filezilla absichern kann: http://www.huegele.de/index.php?option=com_content&view=article&id=25:filezilla-ftp-server-mit-tlsssl-absichern&catid=16:sonstiges
Muss mich Oliver anschliessen. Daten per normalem FTP zu verschieben ist jenseits von gut uns böse. Und dann auch noch übers Internet.
Ich weiß nicht so recht, einerseits ein netter Artikel, aber andererseits … wer einen öffentlichen Server betreibt und dann ne Screenshot Anleitung zum Installieren eines Dienstes nutzt/benötigt, der Ports öffnet, dem kann man nur viel Glück beim weiteren Betrieb wünschen.
Zu so einem Artikel gehört meiner Meinung nach zumindest ein Absatz zur Sicherheit in der IT rein.
wir benutzen FZ seit jahren und sind rund um zufrieden.
Ich habe FZ seit kurzem, weil der FTP in Dreamweaver nur noch sporadisch mit dem Server verbinden kann (hat irgendetwas mit dem Ein- und Ausloggen zu tun). Firezilla ist viel viel schneller. Es gibt jedoch ein Problem. Man kann htaccess-Dateien zwar als htaccess.txt hochladen und dann umbenennen, aber von diesem Augenblick an ist sie für Firezilla verschwunden, obwohl sie natürlich noch da ist.
Hm, kein Wort über TLS bzw. SSH Tunnel? Da krieg ich Pickel. Sensible Daten plain übers Netz zu rödeln halte ich für schlichtweg unverantwortlich.
@Philipp: Müsste ich einen reinen, quasi öffentlichen FTP-Server betreiben, würde auch ich Linux vorziehen. Hier geht es mir darum, einen FTP-Zugang für die Mitglieder von Entwicklerteams, die ihre Daten hochbekommen müssen, herzustellen. Also ein System, dass quasi zwingend auf Windows basieren muss, zu verbessern.
Wenn dann nur nicht der miserable Netzwerkcode von Windows wäre, „dank“ dem auch ein Filezilla unter Windows bestenfalls 50% der Performance von einem einigermaßen korrekt eingerichteten FTP-Server unter Linux erreicht. Um Im Heimnetzwerk aber per FTP Daten zu verschieben reicht es aus.
Die in diesem Artikel beschriebenen Erfahrungen kann ich nur bestätigen. Die FTP-Dienste des IIS haben mich schon im Intranet eines Kunden zur Verzweiflung getrieben. Da ich seit geraumer Zeit mit dem Filezilla-Client mehr als zufrieden bin, lag es nahe als Alternative den Filezilla-Server zu testen. Nach ein paar Minuten hatten sich sämtliche Probleme erledigt. Geht doch!