Samba Freigabe bei neuen Ordnern

  • Ich betreibe unter Raspbian Buster ein kleines NAS: externe HDD mit ext4, mount unter /media/NAS, Freigabe über Samba inkl. aller Rechte über sudo chmod -R 777 /media/NAS

    Nutzer ist ausschließlich Pi (inkl. eigenem smb Passwort).

    Das Problem:

    Generell Lese- und Schreibzugriff auf alle Dateien & Ordner von Windows und auch Android über Samba. Auf dem Pi läuft nebenbei noch der JDownloader, wenn dieser einen neuen Unterordner in /media/NAS erstellt (bei Download oder auch beim Entpacken), habe ich keine Rechte Dateienn aus diesem Ordner über Samba zu verschieben oder den Ordner zu löschen - es kommt Zugriff verweigert.

    Das Einzige was hilft ist erneut sudo chmod -R 777 /media/NAS auszuführen, dann geht es auch mit den neu erstellten Ordnern ohne Probleme.

    Hier die smb.conf falls es auch an ihr liegen könnte:

    [NAS]

    path = /media/NAS

    browseable = yes

    read only = no

    guest ok = no

    valid user = pi

    Hat jemand eine Idee, woran es liegen könnte? Unter DietPi hatte ich die Probleme vorher nicht, Raspbian ist mir aber irgendwie sympathischer :)

  • Code
    inherit permissions = yes

    bzw. die anderen inherit-Optionen der smb.conf funktionieren nicht mehr?

    Dann bleibt u.a. der Weg über ACLs.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Edited once, last by llutz (December 9, 2019 at 5:47 PM).

  • Hat jemand eine Idee, woran es liegen könnte?

    Bei mir sieht die smb.conf folgendermaßen aus

    Code
    [Raspberry] 
    comment = Raspberry Pi 
    path = /media/raspberry/
    valid users = @users 
    force group = users 
    create mask = 0660 
    directory mask = 0771 
    read only = no

    Hab nie Probleme damit gehabt

    Edit: Der Benutzer muss natürlich in der Gruppe "users" sein

    Edit 2: Ich nutze einen gesonderten User (nicht pi) mit eigenem smb-Passwort

  • es kommt Zugriff verweigert.

    Das hat vermutlich nix mit Samba zu tun. Die m.M.n. schlimmste Urache, was dieses Problem verursachen könnte, wäre der Umstand, dass der JDL mit root-Rechten gestartet wurde. Dann ist es klar, dass neue Verzeichnisse/Dateien mit entsprechenden Rechten eingerichtet sind und normale User keinen Zugriff haben. In diesem Fall würde ich allerdings jetzt die Integrität des Systems massiv anzweifeln, wo der PI läuft.

    Um diese mögliche Problemursache auszuschließen: Wie bzw. von wem wird der JDL gestartet?

  • Interessant wäre ggf. auch die Info, wie, bzw. mit wessen Rechten die HDD gemountet ist. Und ob der User pi per se überhaupt auf die Daten in /media/NAS zugreifen kann, also ohne 777er Gedöns.

    //Edit: Und natürlich wer der Eigentümer von /media/NAS ist.

  • Die m.M.n. schlimmste Urache, was dieses Problem verursachen könnte, wäre der Umstand, dass der JDL mit root-Rechten gestartet wurde.

    Aus diesem Grund wäre es ja interessant zu wissen, wer der owner der neuen Ordner/Dateien ist, bzw. wie die Berechtigungen aussehen.

    Möglich sind allerdimgs auch wie llutz bereits angemerkt hat die directory mask und create mask

    In meiner smb.conf s. #5 sind die gesetzt und es funktioniert problemlos.

  • Das hat vermutlich nix mit Samba zu tun. Die m.M.n. schlimmste Urache, was dieses Problem verursachen könnte, wäre der Umstand, dass der JDL mit root-Rechten gestartet wurde. Dann ist es klar, dass neue Verzeichnisse/Dateien mit entsprechenden Rechten eingerichtet sind und normale User keinen Zugriff haben. In diesem Fall würde ich allerdings jetzt die Integrität des Systems massiv anzweifeln, wo der PI läuft.

    Um diese mögliche Problemursache auszuschließen: Wie bzw. von wem wird der JDL gestartet?

    Ich bin tatsächlich noch ziemlich neu im Thema Debian, daher mag das durchaus sein :( Danke für das Feedback bisher!

    Also der JD wird meiner Meinung nach nicht von root gestartet, aber ganz genau kann ich das nicht sagen:

    Autostart über die /etc/rc.local im headless Modus, Eintrag dort:

    /home/pi/jdownloader/jd-headless.sh &

    die jd-headless.sh sieht so aus:

    Bash
    #!/bin/bash
    java -Djava.awt.headless=true -jar /home/pi/jdownloader/JDownloader.jar

    Ausführbar gemacht mit chmod 755. Passt das?

  • Also von root. ;)

    Ups - das war mir nicht bewusst :( Gibt es eine Alternative ohne Root aber ihn trotzdem bei Systemstart aktiv zu haben ohne ihn manuell über SSH zu starten?

    Achja, die HDD wird über die /etc/fstab eingebunden

    Code
    UUID=XXXXXXXXXXXXXX /media/NAS ext4 defaults 0 2
  • Sorry, hatte irgendwie nicht funktioniert... habs geändert.

    Hätte hierzu vielleicht nochmal jemand einen Zwischenschritt, stehe auf dem Schlauch :-/

    Quote


    systemd service-unit oder ganz platt per sudo -u pi -jdl blabla aus der rc.local heraus

  • Welchen RPi verwendest du?

    Denn eventuell ist es sinnvoller JD2 nicht im headless-Mode laufen zu lassen. Der RPi2 läuft etwas zäh, alles neuere geht.

    Hast du schon viel auf dem RPi konfiguriert oder kannst du ohne grosse "Verluste" neu aufsetzen.? Wenn ja, dann empfehle ich dir mit Desktop zu installieren. In der /boot/config.txt musst du dann nur einen HDMI-Mode einstellen. Später greifst du dann per VNC auf den RPi, du brauchst dadurch keinen Monitor, Tastatur oder Mouse, nur Strom und Netzwerk.

    Glaube ersetzt kein Wissen

  • bombom Wozu denn neu aufsetzten? :conf: Es funktioniert doch so, nur der Zugriff über Samba nicht.

    daaaan4 Ich würde das Skript einfach über die Crontab von pi starten.

    Code
    crontab -e #ohne sudo!

    und dort ans Ende:

    Code
    @reboot /home/pi/jdownloader/jd-headless.sh

    Den Start in der rc.local rausnehmen oder auskommentieren aber nicht vergessen. Dann mal ein reboot um zu sehen, ob es so funktioniert.

  • Danke zusammen!

    hyle ich habe es jetzt doch weiterhin über die rc.local gelöst und zwar über

    Code
    su pi -c "/home/pi/jdownloader/jd-headless.sh &"

    Ich hoffe das ist genauso gut - funktionieren tut es auf jeden Fall jetzt und Schreibrechte auf neue Ordner habe ich zumindest.

    bombom Es ist ein RPI4, ich hatte mich aber eigentlich bewusst für komplett headless - auch den Rest des Systems entschieden, da die Desktop-Variante in dem Fall unnötig scheint und auch unnötig Ressourcen frisst. Derzeit läuft es ja jetzt wieder, daher setze ich das System erstmal nicht neu auf :) Danke trotzdem!

  • Wozu denn neu aufsetzten?

    Ich weiss nicht, ob ich die folgende Code-Zeile richtig interpretiere, ...

    java -Djava.awt.headless=true -jar /home/pi/jdownloader/JDownloader.jar

    ... aber wenn ja und die Steuerung des JDLs erfolgt über das Webinterface "https : //my.jdownloader.org", dann bedeutet das, dass irgend ein fremdes System irgendwo auf der Welt eine fernsteuernde Kontrolle über ein mit root-Rechten laufendes Programm hatte. Ob die Menschen mit Berechtigungen bei der Administration dieses Web-Interfaces einer Compliance-Kontrolle unterliegen, ob der Server dieses Web-GUIs überhaupt die notwendigen Security-Restriktionen vorsieht, ob das Web-Gui professionell gesichert ist, wer namentlich dafür verantwortlich ist, alles das ist nicht bekannt.

    Wenn der PI Zugriff auf sensible Daten hatte oder sogar für Hausautomatisierung eingesetzt wurde, dann würde ich ihn komplett bügeln und alle Codes oder Zugangspasswörter für alles komplett neu vergeben. Wenn er weiterhin headless laufen soll, dann würde ich ihn nur in einem isolierten Netzwerk betreiben, quasi unter quarantäne. Also gerade was solche Tools wie den JDL angeht, die eigentlich in einem eher zweifelhaften Umfeld betrieben werden, habe ich Null Vertrauen.

    Ich wundere mich immer wieder über diese paradoxe Welt.... alle reden über Anti-Virenprogramme, Anonymisierung, kostenpflichtige VPN-Dienstleister, wollen ihre IPs verstecken, ihr surfen, reagieren geradezu hysterisch auf alles was mit Hacken und Überwachung durch NSA, FSB und BND zusammenhängt... und dann wird einfach einem fremden Programm Tür und Tor mit einem fernsteuerbaren Vollzugriff auf alle Ressourcen des Netzwerks eröffnet. Kein Wunder, dass es kaum ernstzunehmende Viren-Probleme in Linux gibt, weil wirklich nur Dummköpfe die Arbeit für die Programmierung von Viren leisten... die cleveren Hacker bedienen sich einfach direkt am offenen System.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!