Hallo,

füge doch einmal Deiner proftpd.conf folgendes hinzu:

UseReverseDNS off
IdentLookups off
RequireValidShell off

Das beschleunigt nicht nur den Login-Prozess, sondern verhindert
schon im Vorfeld einige möglich werdene Schwierigkeiten.

mfg.
  VolGas

Au wei...

Ich vermute einmal, daß es mit dem vielen Mounten nicht geklappt hat und die
FTP-User nun nur die Verzeichnisse, die als Mount-Point dienen sollten, sehen.
Und die sind i.d.R. nun einmal leer.

Normalerweise läßt man statische Dateisysteme gleich via "/etc/fstab" mounten
oder man hat ein Startscript, daß das im Serverbetrieb nachträglich tut.

Ich würde Dir eine andere Lösung vorschlagen, die ich gerade vor ein paar
Tagen einem anderen Hilfesuchenden vorgeschlagen habe: nutze das Rechte-
system des Filesystems richtig und vollständig aus!

Konkretes Beispiel: die User werden nicht in ihrem Verzeichnis "eingesperrt"
(chroot), sondern eine Ebene darüber und werden dann aber gleich nach dem
Einloggen in ihr Homeverzeichnis "gebeamt". Da das Verzeichnis jeden Users
je eine eigene UID hat, ist dieses vor dem Zugriff anderer geschützt -
vorausgesetzt natürlich, daß die Zugriffsrechte stimmen...

In die profptd.conf könnte man z.B. folgendes reinschreiben:

DefaultRoot /home/user
DefaultChdir ~
umask 0077

<Directory /home/user>
    HideNoAccess on
</Directory>

Nachdem sich ein User eingeloggt hat, befindet er sich also zuerst in seinem
eigenen Home-Verzeichnis, kann dann aber in das übergeordnete Verzeichnis
wechseln, wo er anschließend die öffentlichen Dinge vorfindet.

In das Verzeichnis "/home/user" kannst Du nämlich weitere Verzeichnisse anlegen,
die Du durch ensprechende Zugriffsrechte für alle freigeben (oder sperren) kannst.
(IMHO würde ich dort aber keine umständlich verschachtelte Verzeichnisstruktur
aufbauen, das ist alles andere als anwenderfreundlich.
Also nicht: "~/../alle/alles/demos", sondern einfach nur: "~/../demos")

Mit "HideNoAccess on" werden die Dinge erst gar nicht angezeigt, zu denen
der User keine Zugriffsrechte hat - also nur öffentlich zugängliches und natürlich
sein eigenes Verzeichnis: fertig. Was keiner weiß, macht auch keinen heiß!

Das Ganze funktioniert gänzlich ohne Kaskade von (um)gemounteten Verzeichnissen.
Nur die zweite Festlatte muß -wie üblich- in das Filesystem "eingehängt" werden.

Zu Deiner proftp.conf: scheint soweit ok, könnte aber noch etwas optimiert werden.
Ich würde mir z.B. gründlich überlegen, ob "ServerType inetd" wirklich sein
muß und würde noch "RequireValidShell" auf "off" setzen.

Ich hoffe, Du kommst damit weiter.

mfg.
  VolGas

Tut mir leid, ich kann dem Ganzen nicht folgen.
Was wurde (warum) wohin gemountet?

Hat jeder User ein eigenes Verzeichnis (in das er "eingesperrt" werden soll),
aber jeder User soll gleichzeitig auch noch auf die zweite Festplatte, die am
Mountpoint "gamemovies" anliegt, zugreifen können?

Wozu -um Himmels willen!!!- sind die Home-Verzeichnisse mit Mount alle auf
einen einzelnen Mountpoint gelegt? Wozu soll das gut sein - außer um massen-
haft Resourcen zu binden und das System einen Stresstest zu unterziehen?

Vielleicht kannst Du Deine momentane Struktur einmal schematisch darstellen?

Bitte gib Dir mit der Sprache ein wenig mehr Mühe - ich habe echt Schwierigkeiten
Deinen Ausführungen zu folgen. Und schreibe Verzeichnisnamen etc. in Anführungs-
zeichen, damit man diese auch als solche gleich erkennen kann.

Auf jeden Fall kannst Du auch einmal Deine proftpd.conf mitposten.

mfg.
  Volgas

Nicht nur das Verzeichnis muß die richtigen Zugriffsrechte haben, sondern
jede einzelne Datei und jedes einzelnes Unterverzeichnis.

Mache doch einfach einmal (als root):
chmod -R a=rwX /home/alle/alles/gamemovies
und probiere es noch einmal...

mfg.
  VolGas

Hallo,

Du hast ein ProFTPD ohne die zugehörigen SQL-Module (mod_sql, mod_sql_mysql).
Compiliere den ProFTPD mit den Modulen neu.

mfg.
  VolGas

@Stonki: Danke - so macht das schon fast Spaß...

@mace:

In meinen ersten drei Antworten wäre eigentlich schon alles zu entnehmen gewesen.
Man hätte eben nur alles miteinander kombinieren müssen. (=Denken, probieren...)
Nix für ungut, gell?   

Dem Filesystem ist es völlig schnuppe, ob es zu den jeweiligen UID's/GID's eingetragene
Systemuser bzw. -gruppen gibt. Nur so kann das mit den virtuellen Usern funktionieren.
Und die kannst Du gut von einem Script anlegen lassen - das minimiert Deinen Aufwand.

Ich weiß nicht, ob die Direktiven, so wie von mir oben angegeben, tatsächlich funktionieren.
Das sollten sie aber - viel Erfolg damit!

mfg.
  VolGas

So, wieder da und habe auch eine Idee: benutze das Rechtesystem des Filesystems
und gib jedem User seine eigene UID (z.B. user001 = 10001, user002 = 10002, ...)
und allen Usern die gleiche Gruppe.

Dann den User nach dem Einloggen in sein Verzeichnis "beamen", aber die "Einsperrung"
erfolgt (in diesem Fall) zwei Ebenen höher. Versuche das Ganze doch einmal mit:

DefaultRoot /var/ftp
DefaultChdir ~
Umask 0077

Dadurch, daß jeder User sein eigenes Verzeichnis mit seiner eigenen UID hat, können
sich die User nicht gegenseitig in den Verzeichnissen herumfummeln (keine Gruppenrechte!),
sehr wohl aber in den übergeordneten Verzeichnissen stöbern, deren User- und Gruppenrechte
entsprechend gesetzt sind.

Das Ganze ohne irgendwelche zusätzlichen Module, -zigfaches Mounten oder Tricks.

Ist das die Lösung, die Du gesucht hast?

mfg.
  VolGas

der user nur sein eigenes Verzeichniss öffnen, beschreiben, usw kann

? ? ?

Gut, wenn Die User nicht in ihr Verzeichnis eingesperrt sein sollen, dann fünktioniert
vielleicht "DefaultChdir ~" so wie Du das möchtest...

Eine Quelle der "Inspiration" kann übrigens die Liste der Direktiven sein...

mfg.
  VolGas

Scheint doch nicht ganz so klar zu sein: jeder User hat sein eigenes Verzeichnis,
sein Home-Verzeichnis. Dafür stellvertretend schreibt man ein "~", also "beamt"
"DefaultRoot ~" den User zuerst in sein Verzeichnis und "sperrt" (chroot) ihn
dann dort ein.

Du must nur jedem User sein richtiges Verzeichnis als Homedir zuweisen:

user001 -> var/ftp/user001
user002 -> var/ftp/user002
user003 -> var/ftp/user003
...

Jedes Auth-Modul kann das; evtl. kann man sich mit einem Script die Daten
einpflegen lassen.

mfg.
  VolGas

Hi!

Die Benutzerrechte sind falsch. Korrigieren, dann geht's.
BTW: Gibt es auf Deiner Tastatur kein Punkt und Komma?

mfg.
  VolGas

Hallo!

Wenn man für jeden User die proftpd.conf ändern müßte - Wahnsinn!

Über ein Auth-Modul wird der User identifiziert und dessen Home-Verzeichnis definiert.
Mittels "DefaultRoot ~" wird dann der User in sein Verzeichnis "eingesperrt" - fertig!

Als Auth-Modul kann man das Standard Unix System nutzen, aber auch diverse andere wie
z.B. auch mySQL. Ein Beispiel dazu findest Du unter ->Support->Beispiel Konfigurationen
und zwei Doku's unter ->Support->Docs

Lesen, denken und ausprobieren mußt Du dann aber schon selber...  

mfg.
  VolGas

Hallo!

Siehe ->Support->FAQ Thema: "ProFTPD startet nicht !"

mfg.
  VolGas

Nein, richtig - und vielleicht auch gleichzeitig falsch...

Man kann bei den virtuellen Auth-Methoden ja jedem User beliebig eine UID/GID zuteilen.
In Deinem Fall hast Du wohl dem virtuellen User "gast" die selbe UID wie dem Systemuser
"nobody" zugeteilt. Das kann aber auch ganz von Deiner Konfiguration abhängen, dazu
müßte ich einmal Deine proftpd.conf sehen - vielleicht postest Du diese einfach einmal hier.

mfg.
  VolGas

Hallo!

Ich arbeite auch mit OS X, allerdings ohne ProFTPD darauf - das muß nur auf unseren Linux-Servern laufen.
Das auf dem Mac aber im "Untergrund" auch ein Unix läuft, kommt auf das Gleiche heraus.

Mit dem Unix-Rechtesystem scheinst Du ein paar generelle Verständnisporbleme zu haben.
Ich versuche es kurz zu fassen, denn hier ist eingentlich nicht das Medium, um prinzipielle
Unixprobleme zu erklären - das wird im Internet taußendfach angeboten.

Du mußt Dir vorstellen, daß das Filesystem jeder Datei eine User-ID und eine Gruppen-ID (UID/GID)
zuweist. Dabei ist es dem Filesystem völlig schnuppe, ob zu den jeweiligen ID's ein User / eine Gruppe
im System eingetragen ist. Dabei wird den ID's nur ein Name (und div. andere Dinge) zugewiesen -
also für das Filesystem unerheblich. Nur daher ist es möglich, auch mit virtuellen Usern zu arbeiten:
in Deinem Fall "mod_auth_file".

Den ProFTPD mußt Du wie eine Benutzershell sehen: nach dem Einloggen hat er die selbe UID/GID
wie der angemeldete User und damit auch dessen Rechte und Beschränkungen.

Es gibt zwar einen User "nobody", aber der ist auch nur ein ganz normaler Systemuser und keine
"Sonderkonstruktion", die alles abfängt. (UID: 65534 bzw. -2)

Vielleicht kannst Du nun so langsam nachvollziehen, weshalb Dein Benutzer "gast" nur deshalb
eine Chanche hatte, wenn Du das/die Verzeichnis(se) world-readable gesetzt hattest. Damit der
User in dem Verzeichnis "schalten & walten" kann wie er möchte, muß er Eigentümer oder
zumindest in einer berechtigten Gruppe sein.

Eine gemeinsame Gruppe wird sowieso notwendig sein, wenn Du später auf dessen Dateien
ebenfalls Zugriff haben möchtest...

Ich hoffe, ich konnte Dir ein Stück weiterhelfen.

mfg.
  VolGas

Hi,

wenn Stonki nicht mehr antwortet, leigt es wohl daran, daß Du die FAQ's nachlesen solltest.
Vielleicht aber auch daran, daß gerade Sonntag Abend war...

mfg.
  VolGas