unter Recording file options im Programm TVHEADEND´S diesen Pfad /media/pi/1719-1F7F/tv
USB LW Freigaben vom Raspberry klappen so nicht
-
zitrone07 -
10. Januar 2019 um 17:21 -
Unerledigt
-
-
USB LW Freigaben vom Raspberry klappen so nicht? Schau mal ob du hier fündig wirst!
-
Den Pfad gibts und derNutzer, mit dessen Konto tvheadend gestartet wird, darf da auch schreiben?
-
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.
-
nein Samba ist damit nicht gemeint, die TV Software speichert TV Aufnahmen auf die SD karte, aber soll auf die SSD ausgelagert werden und da speichern.
und was ist mit der Erklärung da geht es doch um Rechte
https://www.shellbefehle.de/befehle/chmod/
ok was ist denn mit dem Automounten der SSD? Raspbian erkennt die SSD von alleine und packt sie eben in /media/pi/
-
- 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
machen, das wird nüscht!
-
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.
-
ok, kann ich den User hts nun in der etc/adduser.conf eintragen?
-
- 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/usboder 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.
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 !
-
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
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 !
-
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:
-
hts:x:111:1000::/var/lib/hts:/bin/bash
in die .conf schaue ich mal
-
User gibt es nur pi
Soviel dazu
-
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!