»mount --bind«: Keine Berechtigung

  • Hallo,


    im FTP-Server (bei mir ist vsftpd im Einsatz) habe ich die einzelnen Benutzer jeweils in ihr Homeverzeichnis eingesperrt. Da es jedoch außerhalb des selbigen noch Ordner gibt, auf die manche FTP-User Zugriff bekommen sollten, wollte ich diese via »mount --bind /var/www /home/benutzer/www« einbinden, jedoch bekomme ich - obwohl als root angemeldet - die Meldung: »mount: Keine Berechtigung«.


    Über Hilfe oder Alternativen, wie ich das Problem ohne besagtes Mounten lösen könne, wäre ich sehr dankbar.


    Mit freundlichem Gruß,
    WebR

  • Auf netcup vservern kann man generell nicht mounten, weil ein gemeinsamer Kernel verwendet wird. Soweit ich weis müsste es aber reichen wenn du einen symbolischen Link in /home/benutzer/www auf /var/www erstellst, und die Berechtigungen für /var/www so einstellst das der Benutzer dort schreiben kann.

  • vsftpd verbietet aus Sicherheitsgründen das Verfolgen von symbolischen Links, die außerhalb des chroots liegen. Eine Möglichkeit, das zu umgehen, gibt es scheinbar auch nicht - zumindest habe ich nach einiger Zeit Googlebenutzung nichts dergleichen gefunden, außer eben die mount-Lösung.
    Das das Mounten auf vServern nicht geht, wusste ich nicht. Habe mir über die interne Funktionsweise der Virtualisierung bis jetzt kaum Gedanken gemacht und das virtuelle Linux so behandelt wie jedes andere auch. Deine Erklärung macht aber wohl durchaus Sinn, danke :)


    Naja, dann werde ich wohl nicht umhin können, mir einen anderen FTP-Server zu suchen. Soweit ich weiß, hat ProFTPd ja beispielsweise keine Probleme mit Symlinks.


    Ich bedanke mich und verbleibe
    mit freundlichem Gruß,
    WebR

  • Zitat

    Das das Mounten auf vServern nicht geht, wusste ich nicht.

    Mounten ist auf vServern grundsätzlich möglich. Nur eben hier nicht. ;)

    Zitat

    Habe mir über die interne Funktionsweise der Virtualisierung bis jetzt kaum Gedanken gemacht

    Auch an der Virtualisierung liegt es nicht. Ich habe einen anderen openVZ-vServer, bei dem ich tun/tap-Devices benutze, per sshfs meinen netcup-Server mounte, die Netzwerk-Verbindungen überwache und mit iptables fröhlich Ports und Hosts blocke und masquerade. Alles eine Frage dessen, was der Provider erlaubt. ;)


    Zurück zum Thema:
    Kannst du nicht einfach die Apache-vHosts anpassen? Warum /var/www nutzen?

    Mein Server:
    v(olks)Server 1. Serie: 2,5GHz, 1024MB RAM, 1024MB Swap, 2x60GB-Raid1-HDD, Traffic-Flat
    Node:
    78.46.117.9x | hos-tr2.ex3k4.rz7.hetzner.de

  • Zitat


    Zurück zum Thema:
    Kannst du nicht einfach die Apache-vHosts anpassen? Warum /var/www nutzen?


    Jop, habe ich jetzt auch gemacht - nachdem ich feststellen musste, dass auch ProFTPd symbolischen Links offenbar nicht folgen mag :confused: Dabei war ich da so überzeugt von ...


    Ich bedanke mich bei allen, die mir geholfen haben :)

  • Liegt es auch am geteilten Kernel, dass »uname -i«, obwohl ein 32bit CentOS installiert ist, »x86_64« ausgibt (und deshalb in neuen .repo-Dateien wohl auch die Variable $basearch von Hand durch i386 ersetzt werden muss)?

  • Zitat von Artimis;21486

    Mounten ist auf vServern grundsätzlich möglich. Nur eben hier nicht. ;)
    Auch an der Virtualisierung liegt es nicht. Ich habe einen anderen openVZ-vServer, bei dem ich tun/tap-Devices benutze, per sshfs meinen netcup-Server mounte, die Netzwerk-Verbindungen überwache und mit iptables fröhlich Ports und Hosts blocke und masquerade. Alles eine Frage dessen, was der Provider erlaubt. ;)


    Zurück zum Thema:
    Kannst du nicht einfach die Apache-vHosts anpassen? Warum /var/www nutzen?

    Schon etwas älter, aber openVZ ist nicht das gleiche wie OpenVCP (webinterface für linux-vserver)

  • Zitat von Artimis;21486

    Mounten ist auf vServern grundsätzlich möglich. Nur eben hier nicht. ;)


    Das ist grundsätzlich falsch. Es liegt nicht an Netcup, sondern an der Virtualisierungslösung.


    Es ist sehr wohl möglich auch bei Netcup zu mounten, hierfür müsste der Support aber die Hände anlegen, was nicht gerade billig sein dürfte, falls es überhaupt gemacht wird.

    Ich biete gratis Remotehands (SSH) für alle Netcup Kunden - von Kunde zu Kunde!
    Dazu einfach eine an mich .

  • Zitat

    Das ist grundsätzlich falsch. Es liegt nicht an Netcup, sondern an der Virtualisierungslösung.

    Das Problem an meiner Aussage liegt hier:

    Zitat

    Schon etwas älter, aber openVZ ist nicht das gleiche wie OpenVCP (webinterface für linux-vserver)


    Vertan sprach der Igel und sprang von der Bürste.
    Ich habe einfach nicht daran gedacht, dass netcup mit linux-vserver virtualisiert.

    Mein Server:
    v(olks)Server 1. Serie: 2,5GHz, 1024MB RAM, 1024MB Swap, 2x60GB-Raid1-HDD, Traffic-Flat
    Node:
    78.46.117.9x | hos-tr2.ex3k4.rz7.hetzner.de

  • Zitat von Artimis;22064

    Ich habe einfach nicht daran gedacht, dass netcup mit linux-vserver virtualisiert.


    Ist ja nicht schlimm ;)

    Ich biete gratis Remotehands (SSH) für alle Netcup Kunden - von Kunde zu Kunde!
    Dazu einfach eine an mich .