Das verstehe ich nicht so recht. Bei Verzeichnissen kann man es festlegen (Ist ja schon in den Settings auswählbar) und bei Dateien nicht?hvkls hat geschrieben:Das geht mit NFS anders nur, wenn auf dem Client die umask einstellbar, bei der dbox also in die busybox hineinkompiliert, ist.
Samba kann man, wenn es mit root-Rechten laeuft, allerdings instruieren, die Datei-und Verzeichnisrechte (du brauchst beides) fuer den Share nach Gusto zu setzen.
Jo - genau diese Parameter habe ich gesetzt (s.Eisfair Config). Dateien/ Verzeichnisse, die ich unter Windows speichere bekommen auch genau diese Rechte. Speichere ich einen Film via NFS von der Box hat er 644 und ich von Windows aus dementsprechend nur Lesezugriffhvkls hat geschrieben:
In der smb.conf kann man mit force-Parametern die Maske bestimmen, IIRC.
Code: Alles auswählen
SAMBA_SHARE_5_ACTIVE = yes ▒
│ SAMBA_SHARE_5_NAME = HD2 #
│ SAMBA_SHARE_5_COMMENT = public directory on %h ▒
│ SAMBA_SHARE_5_RW = yes ▒
│ SAMBA_SHARE_5_BROWSE = yes ▒
│ SAMBA_SHARE_5_PATH = /mnt/HD2 ▒
│ SAMBA_SHARE_5_USER = +heim ▒
│ SAMBA_SHARE_5_PUBLIC = no ▒
│ SAMBA_SHARE_5_READ_LIST = ▒
│ SAMBA_SHARE_5_WRITE_LIST = ▒
│ SAMBA_SHARE_5_FORCE_CMODE = 0666 ▒
│ SAMBA_SHARE_5_FORCE_DIRMODE = 0777 ▒
│ SAMBA_SHARE_5_FORCE_USER = ▒
│ SAMBA_SHARE_5_FORCE_GROUP = ▒
│ SAMBA_SHARE_5_VSCAN = no Also die Eisfair Doku will ich hier nicht posten aber falls Du Interesse hast hier ein Direktlink http://www.eisfair.org/fileadmin/eisfai ... xFORCEUSERhvkls hat geschrieben:Wenn force user/group keine Alternative ist, bleibt es wohl bei umask (clientseitig). Ich lasse mich gerne eines Besseren belehren.
nein, Force_User bedeutet bezogen auf das share alles unter der ownership des angegebenen users gespeichert wird.hvkls hat geschrieben:Ein fluechtiger Blick sagt mir, dass das etwas fuer dich sein koennte. Versuch macht kluch.
Code: Alles auswählen
chmod 666 /mnt/video/*.ts
chmod 666 /mnt/video/*.xml
Code: Alles auswählen
Index: apps/tuxbox/neutrino/src/driver/stream2file.cpp
===================================================================
RCS file: /cvs/tuxbox/apps/tuxbox/neutrino/src/driver/stream2file.cpp,v
retrieving revision 1.28
diff -u -p -r1.28 stream2file.cpp
--- apps/tuxbox/neutrino/src/driver/stream2file.cpp 7 Sep 2007 02:10:38 -0000 1.28
+++ apps/tuxbox/neutrino/src/driver/stream2file.cpp 19 Dec 2007 16:46:02 -0000
@@ -186,11 +186,15 @@ void * FileThread(void * v_arg)
if (remfile == 0)
{
char filename[FILENAMEBUFFERSIZE];
+ int flags;
sprintf(filename, "%s.%3.3d.%s", myfilename, ++filecount, ((struct filenames_t *)v_arg)->extension);
if (fd2 != -1)
close(fd2);
- if ((fd2 = open(filename, use_o_sync ? O_WRONLY | O_CREAT | O_SYNC | O_TRUNC | O_LARGEFILE : O_WRONLY | O_CREAT | O_TRUNC | O_LARGEFILE, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH)) < 0)
+ flags = O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE;
+ if (use_o_sync)
+ flags |= O_SYNC;
+ if ((fd2 = open(filename, flags, S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH)) < 0)
{
perror("[stream2file]: error opening outfile");
exit_flag = STREAM2FILE_STATUS_WRITE_OPEN_FAILURE;
@@ -472,7 +476,7 @@ stream2file_error_msg_t start_recording(
// write stream information (should wakeup the disk from standby, too)
sprintf(buf, "%s.xml", filename);
- if ((fd = open(buf, O_SYNC | O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH)) >= 0)
+ if ((fd = open(buf, O_SYNC|O_WRONLY|O_CREAT|O_TRUNC, S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH)) >= 0)
{
write(fd, info, strlen(info));
fdatasync(fd);
Gut - man kanns auch übertreiben. 644 (was jetzt Standard ist) bedeutet Leserechte für Welt. Das ist natürlich in der Form sicherer als das ein Eindringling auf meinem ungeschützten im Internet verfügbarem Server die Dateien zwar lesen und auch kopieren kann aber nicht löschen und ändern darfhvkls hat geschrieben: @Tommy, was du zu Hause treibst, ist deine Sache. Auch Sicherheitskonzepte deiner eigenen Bequemlichkeit zu opfern. Verschon aber bitte die Oeffentlichkeit damit.
Was hat b) " Feature Request auf Erweiterung eines bestehenden Menüpunkts" mit der Doku zu NFS zu tun?hvkls hat geschrieben:
Was b) betrifft, empfehle ich die Dokumentation zu NFS.
meine Buildumgebung (unter VMware) tuts momentan nichtseife hat geschrieben:
Mein Patch sollte 0664 draus machen. Hat's denn mal jemand getestet? Ich nicht
habe im startscript umask 0002 gesetzt. An der Konsole erhalte ich auch auf umask -> 0002 (im Original 0022). Files werden aber nach wie vor mit 644 geschrieben.seife hat geschrieben:
Und ja, einfach gar keinen modus angeben und vor dem starten von Neutrino die umask entsprechend im Startskript setzen halte ich auch für eleganter und flexibler.
Ja, weil umask nur bits wegnehmen kann, keine hinzufügen, wenn ich das richtig in der manpage zu open() lese. Sprich: wir sollten die Dateien mit 00666 erzeugen, und den Rest von der umask erledigen lassen. "00666" liest sich übrigens IMVHO auch leichter als "S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH", das könnte man auch mal aufräumen... :-)Tommy hat geschrieben:habe im startscript umask 0002 gesetzt. An der Konsole erhalte ich auch auf umask -> 0002 (im Original 0022). Files werden aber nach wie vor mit 644 geschrieben.seife hat geschrieben:
Und ja, einfach gar keinen modus angeben und vor dem starten von Neutrino die umask entsprechend im Startskript setzen halte ich auch für eleganter und flexibler.
Nun, der beste Feature-Request ist natürlich der, an dem ein Patch dranhängt :-)@All:
Mittlerweile wird es unangenehm Feature Requests zu äußern :cry:
@seife:seife hat geschrieben:Nun, der beste Feature-Request ist natürlich der, an dem ein Patch dranhängt@All:
Mittlerweile wird es unangenehm Feature Requests zu äußern
Ich habe noch nie einen Hehl draus gemacht, daß ich nur an den Sachen rumschraube, die mich selbst betreffen oder zumindest interessieren. Dieses Thema interessiert mich sogar (sonst würde ich jetzt nichts schreiben), aber halt nicht so stark, daß ich es jetzt auch unbedingt selbst ausprobieren muß. Zumindest nicht, solange ich noch andere Sachen zu fixen habe, und da sind noch ein paar...
. Ich finde es blos blöd, das Ideen von vornherein mit Argumenten zerredet werden die zwar durchaus aber nicht in unserer Umgebung relevant sind. Wer seinen Server ans öffentliche Netz hängt sollte wissen was er tut und dafür sorgen, dass der Server sicher ist. Die Dateirechte spielen bei externem Zugriff über Samba, FTP, SSH sowieso nur eine untergeordnete Rolle, da man im jeweiligen Daemon den Zugriff konfigurieren kann. Und über NFS sollte bei entsprechneder exports von außen auch keiner Zugriff haben (selbst wenn der Port offen wäre). und vermutlich wird ein Admin das auch als Titel unter meinen Nick pinnen. 
Jo - bin hart im nehmenhvkls hat geschrieben:@Tommy: War nicht boes gemeint, tut mir leid.
Ich wollte nur sagen, dass es grundsaetzlich funktioniert.
# cd nfsshare
# umask 00022 ; touch test ; ls -l test
-rw-r--r-- 1 1000 1000 0 Dec 20 12:31 test
# rm test
# umask 00002 ; touch test ; ls -l test
-rw-rw-r-- 1 1000 1000 0 Dec 20 12:33 test
Sehr gut! :-)Tommy hat geschrieben:Ich muß da aber sowieso ran da ich mir unbedingt mal ein image mit 2.6er Kernel bauen will.
gestern Abend schon per Post bekommen - THX 4 Thatseife hat geschrieben:So, ein fix ist committed (mit 0666).
