Beiträge von Gamezoner

    Mit Deinem Mountbefehl rufst Du die zuvor eingetragene Zeile in der /etc/fstab auf. Natürlich sucht die dann in /root danach. Weil pi aber im Normalfall dort nichts darf, funktionierts auch nicht. Erst durch Deiner Zerstörung der Eigentümerrechte kann pi darauf zugreifen.

    Da ist kein Bug!

    also entweder die anmeldedaten in die fstab eintragen oder nicht mit mount mounten?

    Soll heißen:

    Wenn in der /etc/fstab die Option user oder users benutzt wird, muss dafür /bin/mount das SUID-Bit gesetzt haben (rwsr-xr-x), damit ein Benutzer != root /bin/mount benutzen darf. Das ist idR der Default.

    Für dein Problem egal.

    Danke... Also hab ichs eh richtig verstanden, dass das user/users bewirkt, dass der normale mount /home/pi/meinwebspace als User pi funktioniert (zumindest wenn ich die anmeldedaten in der fstab eintrage)?

    Aber per curlftpfs domain.de/verzeichnis /home/pi/ftp wird das doch gemountet? :conf:

    ja, eben!

    Aber nicht per

    mount /home/pi/meinwebspace

    wenn ich meine fstab nun ändere und meine anmeldedaten direkt dort eintrage, dann funktioniert dieser Befehl aber...

    das ist es ja, was mich hier etwas sehr verwirrt... "mount" schaut also in /root/ nach der .netrc datei, unabhängig davon welcher benutzer den mount-befehl absetzt...

    Ist das am ende einfach ein bug?

    jo, das klappt bei mir auch so und ist auch alles gleich...

    aber eben mounten über mount /home/pi/meinwebspace als user pi klappts nicht...

    und damit auch nicht das Mounten via klick im pcmanfm

    /bin/mount root root rwsr-xr-x (rws statt rwx !)

    hat zwar das setuid Bit gesetzt, dennoch kann ein anderer User als root nur dann den Mountbefehl erfolgreich ausführen, wenn er vom user root dafür in den mount Optionen (z.B. in /etc/fstab) ausdrücklich ermächtigt wird

    "ein anderer user kann [...] nur dann den mountbefehl erfolgreich ausführen"... bei verwendung von .netrc oder wie? weil eben wenn ich die anmeldedaten direkt in die fstab eintrage, funktioniert (auch als user pi) der mount-Befehl

    mount /home/pi/meinwebspace als benutzer "pi" funktioniert nicht wenn ich die credentials über die .netrc auslese (also in der fstab NICHT eingebe...)

    allerdings, wenn ich (testweise) chown pi:pi /root -R eingebe und dann (als user pi) mount /home/pi/meinwebspace eingebe, dann klappts...

    das heisst für mein verständnis, dass der mount-befehl, auch wenn er als user pi ausgeführt wird, (bei mir) trotzdem auf die /root/.netrc zugreift und nicht auf die /home/pi/.netrc...

    meine fstab-zeile sieht so aus:

    curlftpfs#meinftpserver.com /home/pi/meinwebspace fuse ssl,allow_other,users,uid=1000,gid=1000,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.idle-timeout=300 0 0

    RTFM hat zu beginn des Threads schon was gepostet (siehe Zitat), aber daraus werd ich nicht schlau...

    Webspace, der nur FTP als Zugangslösung bietet?

    Das hat niemand behauptet, aber schön dass mal endlich wieder jemand seinen (unnötigen) Senf dazu gibt, einfach nur um seinen Beitragscounter zu erhöhen...

    Ich habe schon immer nur welchen gebucht, auf den man per SSH und Zertifikat rauf kommt

    Dann freu dich, zieh dich damit in ein ruhiges eckchen zurück und mach dir mit Ihm ein Schäferstündchen... :bravo2:

    Dummerweise enden meine Ideen dazu nun - keine Ahnung warum curlftpfs die netrc nicht nutzt bzw. evtl. am falschen Ort sucht oder whatever.

    Hab grade was festgestellt:

    mount /home/pi/meinwebspace greift als user pi auf die .netrc im ordner root zu und liest von dort aus...

    bin/mount root root rwsr-xr-x (rws statt rwx !)

    hat zwar das setuid Bit gesetzt, dennoch kann ein anderer User als root nur dann den Mountbefehl erfolgreich ausführen, wenn er vom user root dafür in den mount Optionen (z.B. in /etc/fstab) ausdrücklich ermächtigt wird.

    Hat das was damit zu tun? Leider werd ich weder aus der Aussage als solches noch aus <man mount> diesbezüglich schlauer. Und der mount-befehl als solches funktioniert ja, sofern die credentials direkt in die fstab eingetragen werden... Nur über die .netrc klappts nicht...

    und auf meine frage ob dies denn nun die option "user" sei bzw. was ich denn nun (um dieses Verhalten zu ändern) in meine fstab einfügen soll, kam leider nix mehr...

    Hast du (oder gern auch jmd. anders, wenns jmd. weiss) dazu eine weitere idee oder einen Tip oder gar die fertige Lösung?

    :)

    Siehe Edit oben, /root/.netrc mit "default" statt "machine host"

    auch mit erster zeile auf "default" geändert klappts nicht...

    bzw. präziser: sudo mount... klappt auch hier

    mount... also ohne sudo klappt nicht (geändert hab ich aber natürlich beide .netrc dateien...

    hab grad versucht:

    sudo echo $NETRC

    und

    echo $NETRC

    geben beide nur eine leerzeile aus...

    ist "echo" hier falsch? Würde diese Variable gerne erst sehen/wissen bevor ich sie ändere...

    Grade was gefunden, das mir aber so direkt noch nicht weiterhilft:

    Zitat

    The .netrc file contains login and initialization information
    used by the auto-login process. It generally resides in the user’s
    home directory, but a location outside of the home directory
    can be set using the environment variable NETRC.
    Both locations are overridden by the command line option -N.
    The selected file must be a regular file, or access will be denied.

    Kann das irgendwas damit zu tun haben? wo seh ich die "environment variable NETRC" des users Pi bzw. des befehls "mount" wenn ohne "sudo" ausgeführt? wie kann ich mir die ausgeben/anzeigen lassen und ggfs. ändern?

    Das heisst, es werden weder aus /home/pi noch aus /root/ die credentials geholt, oder?! wo muss ich die Datei dann hinpacken, um nicht meine Anmeldedaten in der fstab liegen zu lassen?!

    kann/muss ich irgendwie einen Pfad angeben credentials=pfad/zur/datei wie bei einem Automout von SMB hab ich schon versucht, klappt aber auch nicht...;(

    Das darf sie gerade nicht sein. chmod 600 ~/.netrc (read-write für Owner, Owner muss Benutzer sein)

    das war sie ursprünglich auch...

    hab in irgendeinem tutorial gelesen, das sollte man aus sicherheitsgründen machen um die zugangsdaten ggfs. vor fremden blicken zu schützen, und hab es auf "lesbar für jedermann" gesetzt um eventuelle Rechtefehler beim Auslesen zu vermeiden.

    Hab ich aber grade wieder zurückgeändert:

    in /home/pi/:

    -rw------- 1 pi pi 79 Mai 5 00:05 .netrc

    in /root/:

    -rw------- 1 root root 79 Mai 5 00:05 .netrc

    Kein erfolg, selbes ergebnis...

    Error connecting to ftp: Access denied: 530

    hat zwar das setuid Bit gesetzt, dennoch kann ein anderer User als root nur dann den Mountbefehl erfolgreich ausführen, wenn er vom user root dafür in den mount Optionen (z.B. in /etc/fstab) ausdrücklich ermächtigt wird.

    Das wär die Option "user" in der fstab, oder was müsst ich dafür genau zu meiner Zeile hinzufügen?

    Hier nochmal meine Zeile der fstab

    curlftpfs#meinwebserver.com /home/pi/meinwebspace fuse ssl,allow_other,user,uid=1000,gid=1000,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.idle-timeout=300 0 0

    Hast Du mal nach dem FTP-Fehler 530 gesucht, der beim Mountversuch ausgegeben wird?

    Jo, auf die Idee bin ich auch schon gekommen...

    Je nach Quelle: "login incorrect" oder "login authentication failed"

    Das heisst, es hat wohl was mit den login-Daten zu tun...

    Daher auch meine Frage, wieso ich diesen Fehler bei zwei identischen .netrc Dateien bekomme, welche für jedermann lesbar einmal im /root/ und einmal im /home/pi Verzeichnis liegen.

    Und deshalb auch meine Frage, wie ich curlftpfs dazu bringen kann, mir seine Verbose-Ausgaben auch auszugeben, wenn es via fstab bzw. mount angestossen wird um zu sehen, welche Anmeldedaten verwendet werden und so dem Problem auf die Schliche zu kommen...

    Beantwortet das Deine Frage?

    Leider nein...

    Muss die .netrc (wenn via fstab/mount verbunden wird) woanders liegen als in /home/pi bzw. /root/ ?

    Coole sache...

    Hat aber auch in jeder menge anderer Tutorials 3 Zeilen...

    Aber guckst du Hier, Hier, Hier, Hier und noch bei vermutlich ebensovielen anderen Seiten hat sie nur eine...

    Die Frage ist nun, inwieweit mir das deiner Meinung nach bei meinem Problem helfen soll, wo die Datei ja scheinbar prinzipiell funktioniert, so wie sie ist...

    sudo mount /home/pi/meinwebspace --> Klappt wunderbar, sehe alles, kann alles bearbeiten, so wie es sein soll...

    curlftpfs meinwebserver.com /home/pi/meinwebspace -o ssl-->klappt ebenfalls

    Schade, nun hätt ich mich schon gefreut...

    Dein User ist Mitglied der Gruppe "fuse"?

    Nein, war er noch nicht, die Gruppe gabs bisher aber auch noch garnicht...

    Ist der Benutzer root immer automatisch in allen Gruppen, auch wenns die Gruppe noch garnicht gibt?

    Und hätte dann nich auch schon

    curlftpfs meinwebserver.com /home/pi/meinwebspace -o sslseinen Dienst versagen müssen?

    Nun denn:

    Gruppe wurde erstellt mit

    sudo groupadd fuse

    ist die GID wichtig (ist jetzt 1001)?

    Danach user pi der Gruppe fuse hinzugefügt mit:

    sudo usermod -aG fuse pi

    Das Ergebnis ist leider das selbe wie vorher...

    Mein Passwort enthält übrigens ein Ausrufezeichen (was mir zu Anfang auch Probleme gemacht hat), dieses Problem hatte sich allerdings durch das Erstellen und Benutzen der .netrc eigentlich erstmal erledigt und das Benutzen von curlftpfs als normaler Benutzer pi funktioniert ja.

    Hab ich irgendeine Möglichkeit, curlftpfs via fstab soweit zu bringen, mir die selben Ausgabe auszugeben, die ich auch bekomme wenn ich curlftpfs aus der Konsole mit der option -v starte (z.B. in ein Logfile)?

    Das hatte mich nämlich bei meinen ersten Problemen (falscher Zielordner am FTP-Server und eben das Ausrufezeichen im Passwort) enorm weitergebracht...

    -v beim aufruf von mount bzw. das Hinzufügen der Option debug oder ftpfs_debug in der fstab hat das leider nicht bewirkt (oder ich find das ensprechende logfile nicht)...

    Hallo zusammen...

    Folgendes Problem, mit dem ich nun einfach nicht mehr weiterkomme.

    Wie es der Titel schon andeutet, ist mein Plan, eine FTP-Verbindung (zu meinem Webspace) in das Verzeichnis /home/pi/meinwebspace/ zu mounten.

    Durch einige viele Versuche und mit Hilfe von Dr. Google und div. Foren und HowTo`s und dem -v Anhängsel bin ich, so denke ich, eigentlich auch schon relativ weit gekommen.

    Hier Eintrag in meiner fstab:

    curlftpfs#meinwebserver.com /home/pi/meinwebspace fuse ssl,allow_other,user,uid=1000,gid=1000,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.idle-timeout=300 0 0

    meine .netrc datei hat nur eine Zeile:

    machine meinwebserver.com login meinftpusername password meinftppasswort

    nun hab ich auch schon rausgefunden, dass ein Eintrag a la "credentials=/Pfad/zur/.netrc" nicht zu funktionieren scheint sondern diese Datei muss im Home-Verzeichnis jenes Nutzers liegen, welcher mountet und sollte auch nur für diesen lesbar sein (aus Sicherheitsgründen).

    mittlerweile liegt (zu Testzwecken, um dahinterzukommen wie es funktioniert und warum) eine (vom Dateiinhalt her) identische Kopie im Verzeichnis /root/(Besitzer: root) und eine im Verzeichnis /home/pi/ (Besitzer: pi)...

    Beide Dateien dürfen (ebenfalls für Testzwecke) von jedem gelesen werden.

    nun mein eigentliches Problem:

    sudo mount /home/pi/meinwebspace --> Klappt wunderbar, sehe alles, kann alles bearbeiten, so wie es sein soll...

    curlftpfs meinwebserver.com /home/pi/meinwebspace -o ssl-->klappt ebenfalls

    ABER:

    mount /home/pi/meinwebspace-->Error connecting to ftp: Access denied: 530 und ein -v drangehängt bringt mich in dem fall auch nicht weiter...

    ;(

    in /etc/fuse.conf mount_max = 1000 sowie user_allow_other hab ich auch aktiviert


    Was mach ich da falsch ?

    Wo ist mein Denkfehler?

    Was überseh ich?

    Oder geht das über fstab für einen normalen user tatsächlich so garnicht?

    Das hier hab ich nämlich auch schon gefunden, aber die Lösung mit einem Cronjob funktioniert zwar, ist für mich aber erstmal eine "ich habs leider nicht anders hinbekommen" Lösung und sowas find ich unbefriedigend, wenns dann doch auch so ginge, wie ich mir das vorstelle (Der Weg ist manchmal das Ziel).