Probleme bei Direktaufnahme
-
- Neugieriger
- Beiträge: 7
- Registriert: Freitag 14. März 2003, 16:09
Probleme bei Direktaufnahme
Hallo zusammen,
ich habe auf einer dbox ein JTG-Image 10.12.2005 V 2.1.0.
Beim Versuch einer Direktaufnahme zu einem Linux-Rechner mit NFS-server, kommt leider die Fehlermeldung
"Das Aufnahmeverzeichnis nicht beschreibbar...."
Das Verzeichnis wird gemountet, die Schreibrechte sind vorhanden
ein Aufnahmeverzeichnis für Direktaufnahme ist angegeben. Soweit so gut.
Mit dem Befehl touch /mnt/filme/testfile auf der dbox kommt allerdings die Meldung: Read-only file system.
Beim Durchstöbern im Forum und Wiki bin ich auf entsprechende
Hinweise zu der Beschreibbarkeit der Filesysteme cramfs, jffs gestoßen.
Bevor ich jetzt ein anderes Image flashe meine Frage,
ist ein JTG-Image für die Direktaufnahme geeignet
oder brauch ich ein anderes??
Hier zur Sicherheit noch mal meine configs falls ich einen Fehler reingebaut habe.
Auf der dbox2:
JTG-Image 10.12.2005 V 2.1.0.
Typ: NFS
Server ip: IP-des NFS-servers
Verzeichnis/Freigabe: /dbox
lokales Verzeichnis: /mnt/filme
Beim Start mounten: nein
Mount-Optionen: rw,soft,udp
Mount-Optionen: nolock, rsize=8192,wsize=8192
Benutzername: -
Passwort: -
Mac Adresse: -
Direktaufnahme Einstellungen
Aufnahmeverzeichnis /mnt/filme
Verzeichnisrechte 777
NFS-Server
linux Debian
etc/exports:
/dbox dbox-IP/255.255.255.0(rw, sync, no_wdelay)
Verzeichnisrechte:
drwxrwxrwx root root 4096 Datum dbox
mit mount auf dbox kommt:
box-IP:/dbox on /mnt/filme type nfs
(rw,v2,rsize=8192,wsize=8192,soft,udp,nolock,addr=IP-des NFS-servers)
Danke
ich habe auf einer dbox ein JTG-Image 10.12.2005 V 2.1.0.
Beim Versuch einer Direktaufnahme zu einem Linux-Rechner mit NFS-server, kommt leider die Fehlermeldung
"Das Aufnahmeverzeichnis nicht beschreibbar...."
Das Verzeichnis wird gemountet, die Schreibrechte sind vorhanden
ein Aufnahmeverzeichnis für Direktaufnahme ist angegeben. Soweit so gut.
Mit dem Befehl touch /mnt/filme/testfile auf der dbox kommt allerdings die Meldung: Read-only file system.
Beim Durchstöbern im Forum und Wiki bin ich auf entsprechende
Hinweise zu der Beschreibbarkeit der Filesysteme cramfs, jffs gestoßen.
Bevor ich jetzt ein anderes Image flashe meine Frage,
ist ein JTG-Image für die Direktaufnahme geeignet
oder brauch ich ein anderes??
Hier zur Sicherheit noch mal meine configs falls ich einen Fehler reingebaut habe.
Auf der dbox2:
JTG-Image 10.12.2005 V 2.1.0.
Typ: NFS
Server ip: IP-des NFS-servers
Verzeichnis/Freigabe: /dbox
lokales Verzeichnis: /mnt/filme
Beim Start mounten: nein
Mount-Optionen: rw,soft,udp
Mount-Optionen: nolock, rsize=8192,wsize=8192
Benutzername: -
Passwort: -
Mac Adresse: -
Direktaufnahme Einstellungen
Aufnahmeverzeichnis /mnt/filme
Verzeichnisrechte 777
NFS-Server
linux Debian
etc/exports:
/dbox dbox-IP/255.255.255.0(rw, sync, no_wdelay)
Verzeichnisrechte:
drwxrwxrwx root root 4096 Datum dbox
mit mount auf dbox kommt:
box-IP:/dbox on /mnt/filme type nfs
(rw,v2,rsize=8192,wsize=8192,soft,udp,nolock,addr=IP-des NFS-servers)
Danke
-
- Erleuchteter
- Beiträge: 760
- Registriert: Freitag 14. Januar 2005, 12:42
Re: Probleme bei Direktaufnahme
Lass das mal weg (Macht AFAIK auch so keinen sinn).oxylos hat geschrieben:etc/exports:
/dbox dbox-IP/255.255.255.0(rw, sync, no_wdelay)
BTW: Der NFS Server des Servers ist gestartet?
cu
usul
-
- Neugieriger
- Beiträge: 7
- Registriert: Freitag 14. März 2003, 16:09
-
- Erleuchteter
- Beiträge: 760
- Registriert: Freitag 14. Januar 2005, 12:42
- Ping von Server nach Box und von Box nach Server geht?
- Irgendwelche IPFiltering/Forewarding Sachen bei Linux aktiviert?
- /dbox ist ein Verzeichnis im root Filesystem (da war doch was mit: Mountpints verfolgen braucht ne extra Option in den Exports)?
- Ansonsten mal in /var/log die Logs durchstöbern. IIRC sollte da in einem zumindest der Verbindungswunsch der Box auftauchen.
So damit verlassen mich meine LINUX Fähigkeiten ;-)
cu
usul
- Irgendwelche IPFiltering/Forewarding Sachen bei Linux aktiviert?
- /dbox ist ein Verzeichnis im root Filesystem (da war doch was mit: Mountpints verfolgen braucht ne extra Option in den Exports)?
- Ansonsten mal in /var/log die Logs durchstöbern. IIRC sollte da in einem zumindest der Verbindungswunsch der Box auftauchen.
So damit verlassen mich meine LINUX Fähigkeiten ;-)
cu
usul
-
- Neugieriger
- Beiträge: 7
- Registriert: Freitag 14. März 2003, 16:09
Problem gebannt
es läuft
und zwar mit
/dbox dbox-IP(rw,async,no_root_squash)
in der exports
no_root_squash:
root-Account auf dem Client wird dem auf dem Server gleichgestellt. Hier ist der root-User des Client-Rechners auch root auf dem Server!
http://wiki.tuxbox.org/NAS:Buffalo_Linkstation_II
http://www.linux-user.de/ausgabe/2002/0 ... ml?print=y
man muß nur lange genug suchen...
nochmal danke usul1
meine Linux-Kenntnisse waren auch am Ende
root ist nicht gleich root
cu
oxylos
und zwar mit
/dbox dbox-IP(rw,async,no_root_squash)
in der exports
no_root_squash:
root-Account auf dem Client wird dem auf dem Server gleichgestellt. Hier ist der root-User des Client-Rechners auch root auf dem Server!
http://wiki.tuxbox.org/NAS:Buffalo_Linkstation_II
http://www.linux-user.de/ausgabe/2002/0 ... ml?print=y
man muß nur lange genug suchen...
nochmal danke usul1
meine Linux-Kenntnisse waren auch am Ende
root ist nicht gleich root
cu
oxylos
-
- Erleuchteter
- Beiträge: 760
- Registriert: Freitag 14. Januar 2005, 12:42
Hm,
Meines sieht so aus:
/storrage phobos(rw,async,anonuid=1000,anongid=1000)
Ich dachte das anonuid/anongid wäre nur damit die Dateinen auf dem Server gleich die richtigen Rechte bekommen und man könnte auch darauf verzichten.
Und schon bin ich wieder einwenig schlauer
BTW: Mit no_root_squash gehören die Dateien dann ja Root. Ist das nicht ungünstig um dann dort wieder heranzukommen (Im Netzt von einem anderen Rechner aus)?
cu
usul
Meines sieht so aus:
/storrage phobos(rw,async,anonuid=1000,anongid=1000)
Ich dachte das anonuid/anongid wäre nur damit die Dateinen auf dem Server gleich die richtigen Rechte bekommen und man könnte auch darauf verzichten.
Und schon bin ich wieder einwenig schlauer
BTW: Mit no_root_squash gehören die Dateien dann ja Root. Ist das nicht ungünstig um dann dort wieder heranzukommen (Im Netzt von einem anderen Rechner aus)?
cu
usul
-
- Neugieriger
- Beiträge: 7
- Registriert: Freitag 14. März 2003, 16:09
hi,
also mit der entsprechenden Samba-Freigabe
kommt man schon wieder ran an die Daten
Bei mir im Moment public, writable, chmod=777
(also auf gut deutsch "Scheunentor")
Ich muß mir das mit den Optionen in der exports noch mal genau anschauen.
Ob das mit dem no_root_squash richtig/nötig ist..
Mir gings erst darum das überhaupt funktioniert, ich hatte ja anfangs das
Image in Verdacht, jetzt geht es an Feintuning.
cu
oxylos
also mit der entsprechenden Samba-Freigabe
kommt man schon wieder ran an die Daten
Bei mir im Moment public, writable, chmod=777
(also auf gut deutsch "Scheunentor")
Ich muß mir das mit den Optionen in der exports noch mal genau anschauen.
Ob das mit dem no_root_squash richtig/nötig ist..
Mir gings erst darum das überhaupt funktioniert, ich hatte ja anfangs das
Image in Verdacht, jetzt geht es an Feintuning.
cu
oxylos
-
- Erleuchteter
- Beiträge: 760
- Registriert: Freitag 14. Januar 2005, 12:42
Schön zu wissen das das geht (hate mich mit dem Samba Kram noch nicht so sehr befasst). Im Moment muß ich da immer per Telnet erstmal die Rechnte ändern da ich von zwei Rechnern mit unterschiedlichen Benutzernamen da ran will.oxylos hat geschrieben:also mit der entsprechenden Samba-Freigabe
kommt man schon wieder ran an die Daten
Bei mir im Moment public, writable, chmod=777
(also auf gut deutsch "Scheunentor")
Werde mich bei gelegenheit mal durch die Sambo Config wühlen müssen
cu
usul
-
- Einsteiger
- Beiträge: 328
- Registriert: Freitag 9. Mai 2003, 09:55
Aus der Fibel:
http://www.linuxfibel.de/nfs_srv.htm
root_squash, no_root_squash
Root erhält die UserID des Pseudobenutzers »nobody«, womit der Root-Benutzer des Client-Rechners keine Root-Rechte auf dem vom Server importierten Verzeichnis erhält (Voreinstellung); mit »no_root_squash« bleiben die Root-Rechte auf Clientseite auf dem Verzeichnis erhalten.
all_squash, no_all_squash
Alle Zugreifenden erhalten die Nobody-UID; Voreinstellung ist »no_all_squash«, womit die Nutzerkennungen erhalten bleiben
anongid=gid
Squashing der Gruppe; die Gruppen-ID wird auf »gid« gesetzt. Bei dieser Option kann Root entscheiden, mit welcher Server-GID die Client-Benutzer arbeiten sollen, sobald sie Zugriff auf den Server haben
anonuid=uid
Squashing des Benutzers. Die zugreifenden Benutzer bekommen die UID »uid« verpasst
http://www.linuxfibel.de/nfs_srv.htm
root_squash, no_root_squash
Root erhält die UserID des Pseudobenutzers »nobody«, womit der Root-Benutzer des Client-Rechners keine Root-Rechte auf dem vom Server importierten Verzeichnis erhält (Voreinstellung); mit »no_root_squash« bleiben die Root-Rechte auf Clientseite auf dem Verzeichnis erhalten.
all_squash, no_all_squash
Alle Zugreifenden erhalten die Nobody-UID; Voreinstellung ist »no_all_squash«, womit die Nutzerkennungen erhalten bleiben
anongid=gid
Squashing der Gruppe; die Gruppen-ID wird auf »gid« gesetzt. Bei dieser Option kann Root entscheiden, mit welcher Server-GID die Client-Benutzer arbeiten sollen, sobald sie Zugriff auf den Server haben
anonuid=uid
Squashing des Benutzers. Die zugreifenden Benutzer bekommen die UID »uid« verpasst
-
- Erleuchteter
- Beiträge: 865
- Registriert: Dienstag 12. März 2002, 21:40
Im Detail zu Majors Hinweis:
Wenn man die uid und gid in der /etc/exports detailiert beschreibt, werden die angelegten Dateien (Streams) mit dem gewünschten Benutzer/Gruppe geschrieben.
Dann ist keine Rechteänderung per telnet nötig.
Die entsprechenden user-id findet man in der
Die entsprechenden Gruppen-id findet man in der
Beispiel:
Gruß
Frockert
Wenn man die uid und gid in der /etc/exports detailiert beschreibt, werden die angelegten Dateien (Streams) mit dem gewünschten Benutzer/Gruppe geschrieben.
Dann ist keine Rechteänderung per telnet nötig.
Die entsprechenden user-id findet man in der
Code: Alles auswählen
more /etc/passwd
Code: Alles auswählen
more /etc/group
Code: Alles auswählen
/daten 192.168.0.0/255.255.0.0(async,rw,anonuid=1000,anongid=1000)
Gruß
Frockert
---------------------------
2.6.11-kanotix-3 KDE 3.3.2
http://www.frockert.de
http://www.eifel-forum.de
2.6.11-kanotix-3 KDE 3.3.2
http://www.frockert.de
http://www.eifel-forum.de
-
- Erleuchteter
- Beiträge: 760
- Registriert: Freitag 14. Januar 2005, 12:42
Nunja. Ich mache es so das die gestreamten Dateien mir (Der Account unter meinem Namen auf dem Server) gehören.Frockert hat geschrieben:Wenn man die uid und gid in der /etc/exports detailiert beschreibt, werden die angelegten Dateien (Streams) mit dem gewünschten Benutzer/Gruppe geschrieben.
Dann ist keine Rechteänderung per telnet nötig.
Greife ich per Samba von einem anderen Rechner darauf zu (anderer username da nicht mein Rechner) muß ja auch auf dem Linux Rechner ein Account für diesen Benutzer sein (ist auch).
Dann kann ich aber nicht die Dateien die unter meinem Benutzernamen abgelegt wurden über Samba mit einem Rechner der unter einem anderen Namen angemeldet ist zugreifen.
Ist natürlich auch unüblich es so zu machen. Soll heißen Linux macht das schon richtig so.
Es fehlt mir halt noch ein anongid/anonuid für ein Verzeichnis unter Samba (egal wer darauf zugreift uid/gid wird immer xxx).
Besser wäre noch: Das mit dem Rechten wie gerade beschrieben aber beim Zugriff auf das Verzeichnis fordert Windows nochmal zur Eingabe eines Passwortes auf (welches nicht das Passwort des Benutzers ist). Halt so wie man unter Windows (hier 98SE bald XP) auch ein Verzeichnis mit Extra schreib/lese Kennwort freigeben kann.
Dann könnte nur ich meine Filme sehen und nicht der Besitzer des Rechners (und vorallem könnte er sie nicht ausversehen löschen).
Wie gesagt. Mus ich mich noch mal reinlesen. Aber falls jemand zufällig gerade die config Einträge dafür zur Hand haben sollte...
cu
usul