USB LW Freigaben vom Raspberry klappen so nicht

  • den Pfad gibt es ist ja die SSD habe ich ja nun Vollzugriff per Windows im Netzwerk.

    Tja, der Nutzer? Habe die Pakete im Terminal installieren lassen. Auch das Programm möchte user und pw und wird halt per Webbrowser aufgerufen.

    ich kann die SSD auch nur 0755 Rechte aktiv sehen. Änderung in 0777 nicht möglich

    bei dem Versuch alle user gruppen für ssd zu erlauben (chmod 1777 /media/pi/1719-1F7F kommt das eben raus:

    chmod: Beim Setzen der Zugriffsrechte für '/media/pi/1719-1F7F': Die Operation ist nicht erlaubt

    sehe gerade, dass das TV Programm als Besitzer hts Ordner anlegt. Also besteht die Möglichkeit nun zu sagen User hts darf auf SSD schreiben?

    • Offizieller Beitrag

    Also erstens erlaubst Du mit chmod keiner Gruppe etwas,

    b) werden Rechte im Mountbefehl gesetzt,

    3.) geht es hier noch um einen Zugriff über Samba oder das Dateisystem?

    https://wiki.ubuntuusers.de/Benutzer_und_Gruppen/

    https://wiki.ubuntuusers.de/Rechte/

    //Edit Bitte nicht mehrere Beiträge nacheinander posten, solange noch keiner geantwortet hat. Du kannst Deine Beiträge auch bearbeiten und darauf hinweisen.

    • Offizieller Beitrag

    Bitte lies meinen Beitrag nochmals und beachte das Edit! Und auch den Link https://wiki.ubuntuusers.de/Benutzer_und_Gruppen/

    Wenn der User hts nicht auf externe Laufwerke zugreifen darf, dann sind die Rechte total egal. Da kannst Du

    Code
    sudototalwichtig chmod 777777777777777777777777777 /irgendwas/anstellen 

    machen, das wird nüscht! :lol:

  • hier mal die Infos der Rechte Struktur:

    der pi

    Spoiler anzeigen

    drwxr-xr-x 2 pi pi 4096 Nov 13 15:25 Desktop

    drwxr-xr-x 2 pi pi 4096 Nov 13 15:25 Documents

    drwxr-xr-x 2 pi pi 4096 Jan 11 21:09 Downloads

    drwxr-xr-x 2 pi pi 4096 Nov 13 14:45 MagPi

    drwxr-xr-x 2 pi pi 4096 Nov 13 15:25 Music

    drwxr-xr-x 2 pi pi 4096 Nov 13 15:25 Pictures

    drwxr-xr-x 2 pi pi 4096 Nov 13 15:25 Public

    drwxr-xr-x 2 pi pi 4096 Nov 13 15:25 Templates

    drwsrwsrwt 2 pi pi 4096 Jan 11 17:00 test

    drwxr-xr-x 2 pi pi 4096 Nov 13 15:25 Videos

    und bei /media

    Spoiler anzeigen

    insgesamt 4

    drwxrwxrwx+ 4 pi pi 4096 Jan 11 21:28 pi


    bei /media/pi

    Spoiler anzeigen

    insgesamt 36

    drwxr-xr-x 9 pi pi 32768 Jan 1 1970 1719-1F7F

    drwxrwxr-x 2 hts video 4096 Jan 11 21:28 2019-01-11

    man sieht oberhalb des SSD /media/pi konnte die TV Sofware einen Ordner anlegen und darin auch die Datei speichern. Wie kann ich nun sagen, hts darf auch in 1719-1F7F schreiben. Wie ich hts in pi ändere weiß ich nicht.

    • Offizieller Beitrag

    Nochmals... Bitte lies meinen Beitrag nochmals und beachte das Edit!!! Ich habe keine Lust ständig Deine Beiträge zusammenfügen zu müssen.

    Und Du solltest auch den Link https://wiki.ubuntuusers.de/Benutzer_und_Gruppen/ mal lesen!

  • Und wenn ich den Aufnahmepfad z.B. auf /home/pi/test setze, kann die TV Software sehr wohl alles schreiben. Es legt Ordner mit Besitzer hts an.

    Vielleicht muss ich Automount deaktivieren und mit

    Spoiler anzeigen


    sudo mount -t vfat -o utf8,uid=0,gid=46,noatime /dev/sda5 /media/usb

    oder auch

    Spoiler anzeigen

    sudo mount -t vfat -o utf8,uid=pi,gid=pi,noatime /dev/sda5 /media/usb <br>

    <br>

    bringen aber keine Besserung. Die TV Software kann nicht drauf schreiben. <br>

    <br>

    also der User hts ist laut Befehl vorhanden, nur das einbetten in die Gruppe pi kommt dann<br>

    Spoiler anzeigen

    sudo adduser hts --ingroup pi

    adduser: Der Benutzer »hts« existiert bereits.

    die probiererei geht weiter....

    ja den Edithinweis habe ich leider überlesen ;(

  • das ist ja das merkwürdige. im Vergleich sind die Anzeigen identisch. Root bzw. pi Benutzer von Karte 1 und 2

    Hier einmal die Anzeigen der jeweiligen wieso Karte noch den Ordner raspberry aufweist, weiß ich nicht.

    bild-6c0d9a-1547221495.jpg.html

    Die Karten 1 ind 2 sind überhaupt nicht gleich.

    Karte 1 enthält die Originalkonfiguration, die automount bei angemeldetem User pi erstellt:

    /media root root drwx r-x r-x

    /media/pi root root drwx r-x --- + [ACL für user pi]

    /media/pi/1719-1F7F pi pi drwx r-x r-x

    Da könnte der user hts dieselben Rechte wie der User pi (rw) auf die SSD bekommen, wenn in der ACL von /media/pi auch ihm user:rw Rechte erteilt werden.

    Auf der Karte 2, in deren Filesystem ab /media (inclusive) alles zer"hackt" wurde, würde das nur mehr zufällig funktionieren.

    < sudo setfacl -m u:hts:rx /media/pi >

    Dasselbe Gerät kann mehrmals im Filesystem auch mit verschiedenen Optionen gemountet werden.


    Sevus !

    RTFM = Read The Factory Manual, oder so

    Einmal editiert, zuletzt von RTFM (12. Januar 2019 um 16:29)

  • RTFM

    Zitat

    Auf der Karte 2, in deren Filesystem ab /media (inclusive) alles zer"hackt" wurde, würde das nur mehr zufällig funktionieren.

    und kann ich da was zurücksetzten? Kann ich die Datei für Bootoption von Karte 1 nicht auf Karte 2 ersetzen? beides die selben Bauteile (SD Kartengröße)

    und eben der USB SSD

  • getfacl /media/pi

    @llutz

    der Befehl ist unbekannt. Wo sollte diese erweiterte Sicherheitssperre sein?

    Die Sicherheitssperre beim "Automount" besteht darin, als im Verzeichnis /media für den angemeldeten (aktuellen) User pi ein Verzeichnis pi angelegt wird, das dem User root gehört und dessen Verzeichnisrechte auf rwx --- --- eingeschränk werden. D.h. nur der User root darf das Verzeichnis /media/pi betreten/auflisten (x), Dateien erstellen/umbenennen (w) und Dateien lesen (r).

    Automount erkennt am soeben angeschlossenen Gerät eine vfat Partition und legt mit dessen Partitions-ID den Mountpoint im Verzeinis /media/pi an, auf den der vfat-Mount mit der uid=1000 (=pi). gid=1000 (=angemeldeter Iser pi )ausgeführt wird.

    Damit der User pi (für den der Mount automatisch ja erstellt wurde) auch seine Dateien lesen und schreiben kann, wird ihm am Verzeichnis /media/pi mit einer ACL das Recht eingeräumt, so wie der Verzeichniseigentümer root das Verzeichnis zu betreten/aufzulisten (x) und Dateien zu lesen (r). Dadurch kommt der User pi auf den Mountpoint und wenn das Filesystem rw gemountet ist, hat er Lese- und Schreibrechte auf alle Dateien und Verzeichnisse (mit den FAT32 Einschränkungen in den Dateinamen).

    Wenn aber schon getfacl nicht funktioniert, dann ist setfacl genauso unbekannt, obwohl automount den schon einmal verwendet hat. Dann bestünde noch die Möglichkeit mit chown und chmod die Verzeichnisse /media und /media/pi auf den Zustand der ersten SD zurückzuisetzen.

    Servus !

    RTFM = Read The Factory Manual, oder so

  • und kann ich da was zurücksetzten? Kann ich die Datei für Bootoption von Karte 1 nicht auf Karte 2 ersetzen? beides die selben Bauteile (SD Kartengröße) und eben der USB SSD

    Und warum legst Du nicht einfach händisch einen Mountpoint mit den entsprechenden Rechten (auch für den Nutzer hts) an und mountest Deine SSD selbst statt des Gehampels mit dem Automount?

  • STF ja, dass hatte ich doch schon gemacht, aber die unter /media/pi/test zu mounten klappt ja, aber schreiben darf die TV karten immer noch nicht.

    User gibt es nur pi und unter diesem habe ich auch die TV Karten installiert. Das Programm Tvheadend nennt seinen angelegten Ordern hts.

    Meine Tests die ich jetzt gemacht hatte verlaufen ohne Erfolg.

    So habe ich die SSD in Home/pi/neuer Ordner gemountet. TV kann nicht schreiben.

    habe die SSD in das Verzeichnis der TV Karte /var/lib/hts gemountet TV kann nicht schreiben umount danach nicht mehr möglich System busy (reboot)

    habe eine nfs Freigabe vom NAS gemountet TV kann nicht schreiben.

    und wie weiter? nfs sollte alle Rechte frei haben.

    wie kann ich denn hts explizit Rechte einraümen und warum ist das sowieso nicht pi? Liegt das an der TV Karte auf dem gpio Steckplatz?

  • Was sagt:

    getent passwd hts

    Früher konnte man in der tvheadend.conf festlegen, als welcher User/Group tvheadend lief.

    Zitat

    # What user to run as

    setuid tvheadend

    # What group to run as

    setgid tvheadend

    Checke die Doku ob das auch heute noch so ist.

    https://tvheadend.org/projects/tvhea…d_initial_setup

    //Edit /etc/default/tvheadend:

    Code
    OPTIONS="-u hts -g video"

    Wenn du nichts zu sagen hast, sag einfach nichts.

    3 Mal editiert, zuletzt von llutz (13. Januar 2019 um 17:49)

  • die tvheadend.con sieht so aus:

    Spoiler anzeigen

    #

    # Default configuration for tvheadend

    #

    # TVH_ENABLED

    # set to 0 to disable upstart job

    TVH_ENABLED=1

    # TVH_USER

    # if set to "" will run as root

    TVH_USER="hts"

    # TVH_GROUP

    # if set to "" will run as root

    TVH_GROUP="video"

    # TVH_CONF_DIR

    # if set to "" will use ~TVH_USER/.hts/tvheadend

    TVH_CONF_DIR=""

    # TVH_ADAPTERS

    # if set to "" will use all available adapters

    # for select adapters use comma seperated list of adapter

    # numbers, i.e. to use /dev/dvb/adapter0 and /dev/dvb/adapter1 only

    # set as "0,1"

    TVH_ADAPTERS=""

    # TVH_IPV6

    # if set to 1 will enable IPv6 support

    TVH_IPV6=0

    # TVH_HTTP_PORT

    # if set to "" will use binary default

    TVH_HTTP_PORT=""

    # TVH_HTTP_ROOT

    # if set to "" will use binary default

    # else will change the webui root context, useful for proxied

    # servers

    TVH_HTTP_ROOT=""

    # TVH_HTSP_PORT

    # if set to "" will use binary default

    TVH_HTSP_PORT=""

    # TVH_DEBUG

    # if set to 1 will output debug to syslog

    TVH_DEBUG=0

    # TVH_ARGS

    # add any other arguments

    TVH_ARGS=""

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!