Hallo, vielleicht stelle ich mich ja blöd an, aber ich kriege folgendes nicht gebacken: Auf einem Susi 8.1 Server gibt es neben den /home/user mehrere Storage Platten an einem DAC 960. Diese habe ich "früher", also <= 8.0 mit Softlink als Verzeichnis ("DOSE" oder "MACFILES") in die Homes verlinkt, so daß man als User sowohl unter Linux wie auch Mac oder Win via Samba drauf zugreifen kann. Jetzt sehe ich das Verzeichnis zwar auf dem Server, kann lesen, schreiben usw., aber auf den Clients erscheint es im "serverhome" als "link to unknown" mit "?", aber richtigem Namen und Rechten, linkt also nicht. Weiß jemand, wo da mein Denkfehler steckt? Peter Baumgartner
Am Die, 2003-02-25 um 17.21 schrieb Peter Baumgartner:
Auf einem Susi 8.1 Server gibt es neben den /home/user mehrere Storage Platten an einem DAC 960. Diese habe ich "früher", also <= 8.0 mit Softlink als Verzeichnis ("DOSE" oder "MACFILES") in die Homes verlinkt, so daß man als User sowohl unter Linux wie auch Mac oder Win via Samba drauf zugreifen kann. Jetzt sehe ich das Verzeichnis zwar auf dem Server, kann lesen, schreiben usw., aber auf den Clients erscheint es im "serverhome" als "link to unknown" mit "?", aber richtigem Namen und Rechten, linkt also nicht. Weiß jemand, wo da mein Denkfehler steckt?
Hi, sind die Link-Ziele in /etc/samba/smb.conf freigegeben? Gruss, Wolfgang
Hallo Peter, Peter Baumgartner schrieb: [...]
mit Softlink als Verzeichnis ("DOSE" oder "MACFILES") in die Homes verlinkt, so daß man als User sowohl unter Linux wie auch Mac oder Win via Samba drauf zugreifen kann. Jetzt sehe ich das Verzeichnis zwar auf dem Server, kann lesen, schreiben usw., aber auf den Clients erscheint es im "serverhome" als "link to unknown" mit "?", aber richtigem Namen und Rechten, linkt also nicht.
Ist möglicherweise der Parameter "follow symlinks" in der smb.conf auf "no" gesetzt? [...] Gruß Raimund
Hallo Raimund, Am Dienstag, 25. Februar 2003 18:42 schrieb Raimund Hölle:
Hallo Peter,
Ist möglicherweise der Parameter "follow symlinks" in der smb.conf auf "no" gesetzt?
Gute Frage, trifft aber nicht ganz mein Problem, ich hatte das wohl nicht klar formuliert: 1.) "follow symlinks" war nicht vorhanden (hatte swat wohl "vergessen"). Manuell ingefügt und samba funct! Danke! 2.) Nur auf dem Linux Client sehe ich im Konqueror immer noch das "?" Icon vom Typ "Verknüpfung mit unbekannt, Größe 0B, Rechte Lrwxrwxrwx". Auf dem Server funktioniert der Link. Ich hoffe, das ist hier wenigstens richtig gequotet, damit kein Flamewar ausbricht ;-) Gruß Peter
Peter Baumgartner schrieb:
Hallo Raimund,
Am Dienstag, 25. Februar 2003 18:42 schrieb Raimund Hölle:
Hallo Peter,
Ist möglicherweise der Parameter "follow symlinks" in der smb.conf auf "no" gesetzt?
Gute Frage, trifft aber nicht ganz mein Problem, ich hatte das wohl nicht klar formuliert: 1.) "follow symlinks" war nicht vorhanden (hatte swat wohl "vergessen"). Manuell ingefügt und samba funct! Danke!
Allerdings ist der Default (bei nicht angegebener Option) bereits "yes", es kann allerdings nichts bringen.
2.) Nur auf dem Linux Client sehe ich im Konqueror immer noch das "?" Icon vom Typ "Verknüpfung mit unbekannt, Größe 0B, Rechte Lrwxrwxrwx". Auf dem Server funktioniert der Link.
Wichtig bei einem Link ist, daß auch das "gelinkte" Verzeichnis, also "DOSE", den korrekten Benutzer hat (nicht nur der Link, dessen Rechte sind mehr oder weniger uninteressant. Bei einem Mount-Point Besitzer & Rechte _vor_ und _nach_ dem mounten prüfen). Wenn die Rechte auf dem UNIX-Server stimmen, fällt mir allerdings nichts ein, da ich genau das von dir beschriebene Szenario auf meinem Server auch habe (und es funktioniert). Sende doch mal exaktere Angaben (ls -l, smb.conf, Samba-Version), dann kann ich mal versuchen, mit meiner Konf. zu vergleichen.
Ich hoffe, das ist hier wenigstens richtig gequotet, damit kein Flamewar ausbricht ;-) :-)
Gruß Raimund
Am Mittwoch, 26. Februar 2003 11:36 schrieb Raimund Hölle:
Peter Baumgartner schrieb:
Hallo Raimund,
Am Dienstag, 25. Februar 2003 18:42 schrieb Raimund Hölle:
Hallo Peter,
Allerdings ist der Default (bei nicht angegebener Option) bereits "yes", es kann allerdings nichts bringen.
OK, logisch
2.) Nur auf dem Linux Client sehe ich im Konqueror immer noch das "?" Icon vom Typ "Verknüpfung mit unbekannt, Größe 0B, Rechte Lrwxrwxrwx". Auf dem Server funktioniert der Link.
Wichtig bei einem Link ist, daß auch das "gelinkte" Verzeichnis, also "DOSE", den korrekten Benutzer hat (nicht nur der Link, dessen Rechte sind mehr oder weniger uninteressant. Bei einem Mount-Point Besitzer & Rechte _vor_ und _nach_ dem mounten prüfen). Wenn die Rechte auf dem UNIX-Server stimmen, fällt mir allerdings nichts ein, da ich genau das von dir beschriebene Szenario auf meinem Server auch habe (und es funktioniert). Sende doch mal exaktere Angaben (ls -l, smb.conf, Samba-Version), dann kann ich mal versuchen, mit meiner Konf. zu vergleichen.
Ich hoffe, das ist hier wenigstens richtig gequotet, damit kein Flamewar ausbricht ;-)
:-)
Gruß Raimund
hier ls -l: --------------------------snip------------------ drwxr-xr-x 3 peter users 4096 2003-01-12 22:08 OpenOffice.org1.0.1 lrwxrwxrwx 1 peter users 10 2003-02-14 19:26 dose -> /data/dose drwxr-xr-x 2 peter users 4096 2003-02-26 12:04 download drwxr-xr-x 4 root root 1024 2003-02-26 14:05 boot drwxrwxrwx 3 peter users 4096 2003-02-14 19:26 data drwxr-xr-x 28 root root 61440 2003-02-26 12:49 dev --------------------------snap--------------------- und smb.conf, V# ist 2.2.5-124: # Samba config file created using SWAT # from 0.0.0.0 (0.0.0.0) # Date: 2003/01/10 18:33:18 # Global parameters [global] log file = /var/log/samba/%m character set = ISO8859-15 socket options = SO_KEEPALIVE TCP_NODELAY IPTOS_LOWDELAY hosts equiv = etc/hosts.allow domain master = true username map = /etc/samba/smbusers encrypt passwords = yes veto files = /.AppleDesktop/.AppleDouble/Network Trash Folder/TheVolumesettingsFolder/TheFindByContentFolder/.*/ keepalive = 120 wins support = true netbios name = yello printing = cups kernel oplocks = No follow symlinks = yes path = /data/DOSE default = global workgroup = ARBEITSGRUPPE os level = 33 comment = winstore security = share log level = 3 [homes] oplocks = no browseable = no writable = yes path = /home sync always = yes create mask = 0640 directory mask = 0750 comment = Home Directories veto files = /.AppleDesktop/.AppleDouble/Network Trash Folder/TheVolumesettingsFolder/TheFindByContentFolder/ [printers] create mask = 0600 browseable = no comment = All Printers printable = yes path = /var/tmp [pcguest] guest ok = Yes comment = free4all hosts allow = all writable = yes path = /home/pcguest [phaser] printer = lp comment = Farblaser printable = yes path = /var/spool/cups/tmp Aber wie gesagt, der Windoze Client sieht das Verzeichnis, der Linux-Client nicht, nur bei "pcguest" scheint das leere Passwort nicht zu funktionieren. Ich habe allerdings in den letzten Tagen versucht, einen Postfix/Cyrus Mailserver aufzusetzen, wobei ich mich etwas an die "Wollmilchsau" angelehnt habe. Ich glaube aber nicht, daß einer der dabei beteiligten Prozesse so tief in die Rechte eingreift, daß ich da etwas "zernudelt" habe. Was ist die "4096" bzw "10" in der Ausgabe von ls? Hat das etwas damit zu tun? Gruß Peter
Hallo Peter, Peter Baumgartner schrieb:
Am Mittwoch, 26. Februar 2003 11:36 schrieb Raimund Hölle:
Peter Baumgartner schrieb: [...]
Am Dienstag, 25. Februar 2003 18:42 schrieb Raimund Hölle:
[...]
2.) Nur auf dem Linux Client sehe ich im Konqueror immer noch das "?" Icon vom Typ "Verknüpfung mit unbekannt, Größe 0B, Rechte Lrwxrwxrwx". Auf dem Server funktioniert der Link.
[...]
hier ls -l: --------------------------snip------------------ drwxr-xr-x 3 peter users 4096 2003-01-12 22:08 OpenOffice.org1.0.1 lrwxrwxrwx 1 peter users 10 2003-02-14 19:26 dose -> /data/dose drwxr-xr-x 2 peter users 4096 2003-02-26 12:04 download
drwxr-xr-x 4 root root 1024 2003-02-26 14:05 boot drwxrwxrwx 3 peter users 4096 2003-02-14 19:26 data drwxr-xr-x 28 root root 61440 2003-02-26 12:49 dev --------------------------snap---------------------
Das sieht gut aus, was liefert denn "ls -l /data/"? Dies ist entscheidend!
und smb.conf, V# ist 2.2.5-124:
Jetzt zu deiner smb.conf - hier fällt mir einiges auf, ich weiß jedoch nicht, ob es dein Problem verursacht.
# Samba config file created using SWAT # from 0.0.0.0 (0.0.0.0) # Date: 2003/01/10 18:33:18
# Global parameters [global] log file = /var/log/samba/%m character set = ISO8859-15 socket options = SO_KEEPALIVE TCP_NODELAY IPTOS_LOWDELAY hosts equiv = etc/hosts.allow ^^^^^ Versuche einmal "/etc/hosts.allow". Wie ich allerdings in einer anderen mail von dir gelesen habe, hat deine hosts.allow momentan noch ein falsches Format - also alle Kommentare wieder rein und dann eine Regel erstellen.
Jedoch ist die Verwendung der hosts.allow für Samba absolut unsicher und deshalb nicht empfohlen - samba gibt dann allen Windows-Benutzern mit einem bestimmten Namen vollen Zugriff - z.B. unter Windows 98 kann man sich jederzeit mit einm beliebigen Namen anmelden und vollen Zugriff erhalten ... :-( Vielleicht vorerst einfach weglassen.
domain master = true username map = /etc/samba/smbusers encrypt passwords = yes veto files = /.AppleDesktop/.AppleDouble/Network Trash Folder/TheVolumesettingsFolder/TheFindByContentFolder/.*/ ^^^^^^^^^^^ Diese Option gehört nicht in den "global"-Abschnitt, sondern bei den einzelnen Freigaben, wie du richtig bei "[homes]" definiert hast.
Einfach weglassen.
keepalive = 120 wins support = true netbios name = yello printing = cups kernel oplocks = No follow symlinks = yes path = /data/DOSE ^^^^^^ Auch diese Angabe hat im "global"-Abschnitt nichts zu suchen - meinst du "logon path"?
Einfach weglassen.
default = global ^^^^^^^ Du definierst hier einen "default service" namens "global", dies erscheint mir etwas seltsam, da "global" keine Freigabe, sondern ein reserviertes Wort ist.
Einfach weglassen.
workgroup = ARBEITSGRUPPE os level = 33 comment = winstore security = share log level = 3
[homes]
[...] Mit dem Rest bin ich einverstanden.
Ich habe allerdings in den letzten Tagen versucht, einen Postfix/Cyrus Mailserver aufzusetzen, wobei ich mich etwas an die "Wollmilchsau" angelehnt habe. Ich glaube aber nicht, daß einer der dabei beteiligten Prozesse so tief in die Rechte eingreift, daß ich da etwas "zernudelt" habe. [...] Eher unwahrscheinlich, daß dies Samba beeinflußt.
Was ist die "4096" bzw "10" in der Ausgabe von ls? Hat das etwas damit zu tun?
Dies ist einfach die Dateigröße - bei Verzeichnissen der benötigte Platz um das "Inhaltsverzeichnis" zu speichern. Ich würde dir weitere Vorgehensweise vorschlagen: 1. Sende mal die Ausgabe von "ls -l /data/". 2. Wenn das nichts ergibt, ändere deine smb.conf 3. Hilft das auch nicht, müßtest du das logging von Samba aktivieren und mal schauen, was beim Zugriff auf den Link ausgegeben wird. Gruß Raimund
Hallo Raimuind, hat ein bißchen gedauert, weil mir gestern beim Rumbasteln am Postfix die kompletten Rechte auf dem Server abgeschmiert sind, und ich erst mal für einige Stunden nicht mehr reingekommen bin :-(( Am Donnerstag, 27. Februar 2003 09:05 schrieb Raimund Hölle:
Hallo Peter,
Peter Baumgartner schrieb:
Am Mittwoch, 26. Februar 2003 11:36 schrieb Raimund Hölle:
Peter Baumgartner schrieb:
[...]
Am Dienstag, 25. Februar 2003 18:42 schrieb Raimund Hölle:
[...]
2.) Nur auf dem Linux Client sehe ich im Konqueror immer noch das "?" Icon vom Typ "Verknüpfung mit unbekannt, Größe 0B, Rechte Lrwxrwxrwx". Auf dem Server funktioniert der Link.
[...]
hier ls -l: --------------------------snip------------------ drwxr-xr-x 3 peter users 4096 2003-01-12 22:08 OpenOffice.org1.0.1 lrwxrwxrwx 1 peter users 10 2003-02-14 19:26 dose -> /data/dose drwxr-xr-x 2 peter users 4096 2003-02-26 12:04 download
drwxr-xr-x 4 root root 1024 2003-02-26 14:05 boot drwxrwxrwx 3 peter users 4096 2003-02-14 19:26 data drwxr-xr-x 28 root root 61440 2003-02-26 12:49 dev --------------------------snap---------------------
Das sieht gut aus, was liefert denn "ls -l /data/"? Dies ist entscheidend!
Das ( wieso das OGG da rumhängt, weiß ich allerdings nicht, hab ich wohl mal falsch adressiert ;-)): yello:/home/peter # ls -l /data insgesamt 31048 drwxrwxrwx 5 peter users 4096 2003-02-27 18:07 . drwxr-xr-x 21 root root 4096 2003-02-28 12:01 .. drwxr-xr-x 15 peter users 4096 2003-02-27 18:01 Mail -rw-r----- 1 peter users 31732951 2002-11-17 14:51 Uriah Heep -04 -July Morning.ogg drwxrwxrwx 8 peter users 4096 2003-02-24 14:59 dose drwxr-xr-x 5 peter users 4096 2003-02-27 18:09 store yello:/home/peter # Kannst Du da was rauslesen?
und smb.conf, V# ist 2.2.5-124:
Jetzt zu deiner smb.conf - hier fällt mir einiges auf, ich weiß jedoch nicht, ob es dein Problem verursacht.
Nö, mit Samba hab ich ja kein Problem, das läuft ja! Ich sehe das Verzeichnis nur auf Linuz-Clients nicht. Werde trotzdem mal Deine Hinweise beherzigen und die smb.conf "zu Fuß" editieren.
# Samba config file created using SWAT # from 0.0.0.0 (0.0.0.0) # Date: 2003/01/10 18:33:18
[---]
Mit dem Rest bin ich einverstanden.
Gruß Raimund
Gruß Peter PS: bin über's Wochenende weg, also keine Panik, wenn ich mich nicht melde ;;-)
Hallo Peter, Peter Baumgartner schrieb: [...]
yello:/home/peter # ls -l /data insgesamt 31048 drwxrwxrwx 5 peter users 4096 2003-02-27 18:07 . drwxr-xr-x 21 root root 4096 2003-02-28 12:01 .. drwxr-xr-x 15 peter users 4096 2003-02-27 18:01 Mail -rw-r----- 1 peter users 31732951 2002-11-17 14:51 Uriah Heep -04 -July Morning.ogg drwxrwxrwx 8 peter users 4096 2003-02-24 14:59 dose drwxr-xr-x 5 peter users 4096 2003-02-27 18:09 store yello:/home/peter #
Kannst Du da was rauslesen?
Nö, sieht alles gut aus. [...]
Nö, mit Samba hab ich ja kein Problem, das läuft ja! Ich sehe das Verzeichnis nur auf Linuz-Clients nicht. Werde trotzdem mal Deine Hinweise beherzigen und die smb.conf "zu Fuß" editieren.
Das ist mir jetzt nicht ganz klar - wie greift denn dein Linux-Client auf die Server-Laufwerke zu - doch per Samba? Oder verwendest du NFS? [...] Gruß Raimund
Hallo Raimund, Am Freitag, 28. Februar 2003 14:07 schrieb Raimund Hölle:
Hallo Peter,
[...]
Kannst Du da was rauslesen?
Nö, sieht alles gut aus.
Das dachte ich mir auch. Ich hatte so ein ähnliches Problem schon mal auf einem Susi 7.2 Server, ich weiß aber um's verplatzen nicht mehr, wie ich das damals gefixt habe.
[...]
Nö, mit Samba hab ich ja kein Problem, das läuft ja! Ich sehe das Verzeichnis nur auf Linuz-Clients nicht. Werde trotzdem mal Deine Hinweise beherzigen und die smb.conf "zu Fuß" editieren.
Das ist mir jetzt nicht ganz klar - wie greift denn dein Linux-Client auf die Server-Laufwerke zu - doch per Samba? Oder verwendest du NFS?
NFS mit kernel based server wie Standard bei 8.1, exports: /home/peter/ *.bssmusix.de(rw,root_squash,sync) /home/ilona/ *.bssmusix.de(rw,root_squash,sync) /home/mac/ *.bssmusix.de(rw,root_squash,sync) /var/spool/cups/ *.bssmusix.de(rw,root_squash,sync) /data/dose/ *.bssmusix.de(rw,root_squash,sync) die letzte Zeile habe ich mal eingefügt, nachdem das Verzeichnis nicht sichtbar war, hat aber nichts gebracht. Ein Link im freigegebenen Verzeichnis sollte ja auch reichen. Smb habe ich nur für die beiden Win2k-Kisten. Daneben läuft noch atalk für die beiden Macs, die aber nur auf /home/mac Zugriff haben (sinnvollerweise, um nicht den ganzen Rechner mit ".apple.doubles" vollzuwerfen. Die nötigen Verzeichnisse (Bilder, Musik...) sind dann individuell in die homes der User verlinkt. Der Witz dabei ist, daß von win aus das Verzeichnis les- und schreibbar ist, über NFS aber nicht.Vielleicht sollte ich mich mal in ldap einlesen und darauf umsteigen! Es läuft übrigens dhcp und dns, da auch Router für DSL, aber das sollte (hoffentlich!!) keine Rolle spielen.
Gruß Peter
Hallo Peter, Peter Baumgartner schrieb:
Hallo Raimund,
Am Freitag, 28. Februar 2003 14:07 schrieb Raimund Hölle:
Hallo Peter,
[...]
Kannst Du da was rauslesen?
Nö, sieht alles gut aus.
Das dachte ich mir auch. Ich hatte so ein ähnliches Problem schon mal auf einem Susi 7.2 Server, ich weiß aber um's verplatzen nicht mehr, wie ich das damals gefixt habe.
[...]
Nö, mit Samba hab ich ja kein Problem, das läuft ja! Ich sehe das Verzeichnis nur auf Linuz-Clients nicht. Werde trotzdem mal Deine Hinweise beherzigen und die smb.conf "zu Fuß" editieren.
Das ist mir jetzt nicht ganz klar - wie greift denn dein Linux-Client auf die Server-Laufwerke zu - doch per Samba? Oder verwendest du NFS?
Tja, da war ich wohl komplett daneben, von NFS habe ich nichts mitbekommen, nur von Samba ... Aber dann ist mir dein Problem natürlich klar - NFS ist eben etwas _völlig_ anderes als Samba! Ein Soft-Link ist letztendlich nichts anderes als eine Datei, in der ein Zieldateiname steht. Dieser Link wird jedoch bei NFS nicht auf dem Server (wie bei Samba) sondern auf dem Client aufgelöst! Hast du also auf deinem Client kein Verzeichnis "/data/dose", läuft der Link natürlich immer ins leere, dies hat überhaupt nichts mit deiner SuSE-Version zu tun; es war noch nie anders! Mounte also auf deinem Client "nfsserver:/data/dose" unter "/data/dose". Gruß Raimund
Hallo Raimund, sorry, ich hatte die Identität nicht eingestellt, ist, glaube ich, als PM raus? Am Freitag, 28. Februar 2003 16:15 schrieb Raimund Hölle:
Hallo Peter,
Tja, da war ich wohl komplett daneben, von NFS habe ich nichts mitbekommen, nur von Samba ...
Aber dann ist mir dein Problem natürlich klar - NFS ist eben etwas _völlig_ anderes als Samba! Ein Soft-Link ist letztendlich nichts anderes als eine Datei, in der ein Zieldateiname steht. Dieser Link wird jedoch bei NFS nicht auf dem Server (wie bei Samba) sondern auf dem Client aufgelöst! Hast du also auf deinem Client kein Verzeichnis "/data/dose", läuft der Link natürlich immer ins leere, dies hat überhaupt nichts mit deiner SuSE-Version zu tun; es war noch nie anders!
Mounte also auf deinem Client "nfsserver:/data/dose" unter "/data/dose".
Gruß Raimund
Hat ein bißchen gedauert, weil ich weg war. Mit dem Namen des mounts hat das nichts zu tun: Ob ich das unter "/data/dose/" oder "/home/blabla/Wurstkessel" mounte, hat überhaupt keinen Einfluß auf die Rechte oder Sichtbarkeit - z.B.: mount -t nfs yello:/home/peter /home/peter/server liefert prompt das gewünschte Ergebnis. Der im gemounteten Ordner enthaltene Link "/data/dose" wird ausgegrayt und ist unknown, während z.B. ein auf "/home/mac/gifs" zeigender Link funktioniert. Aber mehr als chmod 777 (bzw. normalerweise 764) /data/dose kann ich ja wohl kaum machen??? Na ja, ich will dann noch etwas googeln (seufz). Gruß Peter
Hallo Peter, Peter Baumgartner schrieb:
Hallo Raimund,
Am Freitag, 28. Februar 2003 16:15 schrieb Raimund Hölle:
Hallo Peter,
Tja, da war ich wohl komplett daneben, von NFS habe ich nichts mitbekommen, nur von Samba ...
Aber dann ist mir dein Problem natürlich klar - NFS ist eben etwas _völlig_ anderes als Samba! Ein Soft-Link ist letztendlich nichts anderes als eine Datei, in der ein Zieldateiname steht. Dieser Link wird jedoch bei NFS nicht auf dem Server (wie bei Samba) sondern auf dem Client aufgelöst! Hast du also auf deinem Client kein Verzeichnis "/data/dose", läuft der Link natürlich immer ins leere, dies hat überhaupt nichts mit deiner SuSE-Version zu tun; es war noch nie anders!
Mounte also auf deinem Client "nfsserver:/data/dose" unter "/data/dose".
Gruß Raimund
Hat ein bißchen gedauert, weil ich weg war. Mit dem Namen des mounts hat das nichts zu tun: Ob ich das unter "/data/dose/" oder "/home/blabla/Wurstkessel" mounte, hat überhaupt keinen Einfluß auf die Rechte oder Sichtbarkeit - z.B.: mount -t nfs yello:/home/peter /home/peter/server liefert prompt das gewünschte Ergebnis. Der im gemounteten Ordner enthaltene Link "/data/dose" wird ausgegrayt und ist unknown, während z.B. ein auf "/home/mac/gifs" zeigender Link funktioniert. Aber mehr als chmod 777 (bzw. normalerweise 764) /data/dose kann ich ja wohl kaum machen???
irgendeiner von uns hat da was falsch verstanden - deshalb hier eine Aufstellung so, wie ich es verstanden habe: * Der Server exportiert das Verzeichnis /home/peter * Unter /home/peter gibt es einen Link nach /data/dose * Der Client "mountet" das Serververzeichnis "/home/peter" lokal unter /home/peter * Damit siehst du einen Link nach /data/dose * Dieses Verzeichnis /data/dose jedoch existiert nicht auf dem Client, sondern nur auf dem Server! Wie soll also der Client den Link auflösen? Noch einmal: der NFS-Server löst Soft-Links nicht auf! Dies macht erst der Client! Wenn du also dafür sorgst, daß auch der Client ein Verzeichnis /data/dose besitzt, wird der Link auf dem Client nicht mehr ins Leere laufen. Damit unter /data/dose auch etwas sinnvolles steht, mußt du auf dem Server /data/dose exportieren und auf dem Client entsprechend mounten. Du benötigst also bei deiner Konstellation unbedingt __zwei__ NFS-Mounts auf dem Client - einmal das Home-Verzeichnis selber, dann noch das Zielverzeichnis des (der) Links im Home-Verzeichnis. Ich hoffe, mein Verständnis des Problems ist nun klarer geworden - wenn ich jetzt daneben liege, müssen wir anders neu anfangen. Gruß Raimund
Hallo Peter, Raimund Hölle schrieb: [...]
* Der Server exportiert das Verzeichnis /home/peter * Unter /home/peter gibt es einen Link nach /data/dose
* Der Client "mountet" das Serververzeichnis "/home/peter" lokal unter /home/peter * Damit siehst du einen Link nach /data/dose * Dieses Verzeichnis /data/dose jedoch existiert nicht auf dem Client, sondern nur auf dem Server! Wie soll also der Client den Link auflösen?
Noch einmal: der NFS-Server löst Soft-Links nicht auf! Dies macht erst der Client!
Wenn du also dafür sorgst, daß auch der Client ein Verzeichnis /data/dose besitzt, wird der Link auf dem Client nicht mehr ins Leere laufen. Damit unter /data/dose auch etwas sinnvolles steht, mußt du auf dem Server /data/dose exportieren und auf dem Client entsprechend mounten. Du benötigst also bei deiner Konstellation unbedingt __zwei__ NFS-Mounts auf dem Client - einmal das Home-Verzeichnis selber, dann noch das Zielverzeichnis des (der) Links im Home-Verzeichnis.
Ich hoffe, mein Verständnis des Problems ist nun klarer geworden - wenn ich jetzt daneben liege, müssen wir anders neu anfangen.
Ach ja, noch eine andere Möglichkeit - mounte auf dem Linux-Client analog zu den Windows-Clients per smb statt nfs, und du bist dein ganzes Problem los (und benötigst keine NFS-Freigaben auf dem Server). Siehe "man smbmount". Gruß Raimund
Hallo Raimund, Am Mittwoch, 5. März 2003 08:33 schrieb Raimund Hölle:
Hallo Peter,
Raimund Hölle schrieb: [...]
* Der Server exportiert das Verzeichnis /home/peter * Unter /home/peter gibt es einen Link nach /data/dose
* Der Client "mountet" das Serververzeichnis "/home/peter" lokal unter /home/peter * Damit siehst du einen Link nach /data/dose * Dieses Verzeichnis /data/dose jedoch existiert nicht auf dem Client, ^^^^^^^^^^ sondern nur auf dem Server! Wie soll also der Client den Link auflösen?
Doch, auch wenn dieses Verzeichnis clientseitig vorhanden ist, wird es leer angezeigt! Das ist es ja, was ich nicht kapiere! Und andere Links werden ja aufgelöst, auch wenn sie anders heißen als die Verzeichnisse. ( Wunder der Unixwelt?)
Noch einmal: der NFS-Server löst Soft-Links nicht auf! Dies macht erst der Client!
Wenn du also dafür sorgst, daß auch der Client ein Verzeichnis /data/dose besitzt, wird der Link auf dem Client nicht mehr ins Leere laufen.
schön wär's... Damit unter /data/dose auch etwas sinnvolles steht, mußt du auf
dem Server /data/dose exportieren und auf dem Client entsprechend mounten. Du benötigst also bei deiner Konstellation unbedingt __zwei__ NFS-Mounts auf dem Client - einmal das Home-Verzeichnis selber, dann noch das Zielverzeichnis des (der) Links im Home-Verzeichnis.
sind beide drin: --------------snip----------------- /home/peter/ *.bssmusix.de(rw,sync) /home/ilona/ *.bssmusix.de(rw,root_squash,sync) /home/mac/ *.bssmusix.de(rw,root_squash,sync) /var/spool/cups/ *.bssmusix.de(rw,root_squash,sync) /data/dose/ *.bssmusix.de(rw,root_squash,sync) -------------snap----------------
Ich hoffe, mein Verständnis des Problems ist nun klarer geworden - wenn ich jetzt daneben liege, müssen wir anders neu anfangen.
Ach ja, noch eine andere Möglichkeit - mounte auf dem Linux-Client analog zu den Windows-Clients per smb statt nfs, und du bist dein ganzes Problem los (und benötigst keine NFS-Freigaben auf dem Server).
Hm, gute Idee, um zunächst was zu bekommen, aber die Neugier befriedigt's halt nicht. Kann mich da aber erst morgen drum kümmern, bis dann! Peter
Hallo Peter, Peter Baumgartner schrieb: [...] Ich verstehe jetzt wirklich nur noch Bahnhof ... damit ich wieder ins Gleis komme, könntest du vielleicht mal folgende info's mailen: Ausgabe von den Befehlen auf dem Server: "echo $HOSTNAME" "mount" "exportfs -v" "ls -l /home/peter/" "ls -l /data/" "ls -l /data/dose/" Vom Client: dto. Vielleicht kapier' ich's dann. Gruß Raimund
Hallo Raimund, sollte ich das vielleicht über PM schicken? ist länglich und geht ja auch etwas ans "Eingemachte" Am Mittwoch, 5. März 2003 17:36 schrieb Raimund Hölle:
Hallo Peter,
Peter Baumgartner schrieb: [...]
Ich verstehe jetzt wirklich nur noch Bahnhof ... damit ich wieder ins Gleis komme, könntest du vielleicht mal folgende info's mailen:
Ausgabe von den Befehlen auf dem Server:
"echo $HOSTNAME" "mount" "exportfs -v" "ls -l /home/peter/" "ls -l /data/" "ls -l /data/dose/"
Vom Client: dto.
Vielleicht kapier' ich's dann.
Gruß Raimund
On Die, 04 Mär 2003 at 20:19 (+0100), Peter Baumgartner wrote: [...]
oder "/home/blabla/Wurstkessel" mounte, hat überhaupt keinen Einfluß auf die Rechte oder Sichtbarkeit - z.B.: mount -t nfs yello:/home/peter /home/peter/server liefert prompt das gewünschte Ergebnis. Der im gemounteten Ordner enthaltene Link "/data/dose" wird ausgegrayt und ist unknown, während z.B. ein auf "/home/mac/gifs" zeigender Link funktioniert. Aber mehr als chmod 777 (bzw. normalerweise 764) /data/dose kann ich ja wohl kaum machen???
IMHO liegt das Problem darin, dass der Link auf /home/mac/gifs auf ein Ziel im gleichen Dateisystem zeigt, während /data/dose wohl ein anderes Dateisystem ist, oder irre ich mich mit meiner Vemrutung? Jan
Hallo Jan, Am Dienstag, 4. März 2003 21:30 schrieb Jan Trippler:
On Die, 04 Mär 2003 at 20:19 (+0100), Peter Baumgartner wrote: [...]
oder "/home/blabla/Wurstkessel" mounte, hat überhaupt keinen Einfluß auf die Rechte oder Sichtbarkeit - z.B.: mount -t nfs yello:/home/peter /home/peter/server liefert prompt das gewünschte Ergebnis. Der im gemounteten Ordner enthaltene Link "/data/dose" wird ausgegrayt und ist unknown, während z.B. ein auf "/home/mac/gifs" zeigender Link funktioniert. Aber mehr als chmod 777 (bzw. normalerweise 764) /data/dose kann ich ja wohl kaum machen???
IMHO liegt das Problem darin, dass der Link auf /home/mac/gifs auf ein Ziel im gleichen Dateisystem zeigt, während /data/dose wohl ein anderes Dateisystem ist, oder irre ich mich mit meiner Vemrutung?
Da könnte was dran sein: Filesystem: / /data/dose #ist in exports für *.domain, /home/ auch /home/mac/bilder/gifs, tifs, pics.... /peter/dose, bilder - "dose" zeigt auf "/data/dose", "bilder" zeigt auf /home/mac/bilder/gifs /data/ liegt auf einer eigenen Platte, Freigaben siehe weiter oben im thread. /usr /var.... eventuell liegt es daran, daß ich "data/" als root erzeugt und dann "peter - users" zugewiesen habe. Vielleicht habe ich da was falsch gemacht? ich kann das aber frühestens heute abend oder morgen früh verfolgen. bis denne! Peter
Hallo! Ich habe mir KDE 3.1 und Gnome2 (base,apps,internationalization,development) heruntergezogen und will diese unter SuSE Linux 8.0 System installieren. Kann ir bitte jemand sagen wie ich das am besten anstellen soll? Ich habe auf der Page keine Anleitung mit welchen RPM Befehl und von wo aus ich die grafische Benutzeroberfläche updaten kann. Wenn jemand hier schon mal so etwas erfolgreich upgedatet hat, dann würde ich diesen herzlichst für dessen Unterstützung danken Tamer
On Mit, 05 Mär 2003 at 17:11 (+0100), Peter Baumgartner wrote:
Hallo Jan,
Am Dienstag, 4. März 2003 21:30 schrieb Jan Trippler:
On Die, 04 Mär 2003 at 20:19 (+0100), Peter Baumgartner wrote: [...]
oder "/home/blabla/Wurstkessel" mounte, hat überhaupt keinen Einfluß auf die Rechte oder Sichtbarkeit - z.B.: mount -t nfs yello:/home/peter /home/peter/server liefert prompt das gewünschte Ergebnis. Der im gemounteten Ordner enthaltene Link "/data/dose" wird ausgegrayt und ist unknown, während z.B. ein auf "/home/mac/gifs" zeigender Link funktioniert. Aber mehr als chmod 777 (bzw. normalerweise 764) /data/dose kann ich ja wohl kaum machen???
IMHO liegt das Problem darin, dass der Link auf /home/mac/gifs auf ein Ziel im gleichen Dateisystem zeigt, während /data/dose wohl ein anderes Dateisystem ist, oder irre ich mich mit meiner Vemrutung?
Da könnte was dran sein: [...]
Daran liegt es wohl nicht, ich habe es nochmal getestet. Meine Tests geben Raimund recht.
eventuell liegt es daran, daß ich "data/" als root erzeugt und dann "peter - users" zugewiesen habe. Vielleicht habe ich da was falsch gemacht?
Glaube ich nicht, aber prüfen kannst Du ja (kost' ja nix ;-) Wie ich getestet habe: Ich habe einen NFS-Server k233 mit folgender /etc/exports: /work *.privat.jan(rw,all_squash,anonuid=500,anongid=100) In /work habe ich folgende Links angelegt (gekürzt wg. Zeilenlänge): k233:/work# ls -l total 60 drwxr-xr-x [...] 4096 Jan 17 14:36 audio [...] lrwxrwxrwx [...] 5 Mar 5 17:16 link_im_fs -> audio lrwxrwxrwx [...] 9 Mar 5 17:24 link_jan -> /home/jan lrwxrwxrwx [...] 9 Mar 5 17:19 link_nach_aussen -> /tmp/k233 Auf dem Client existiert das Verzeichnis /work/audio und /home/jan, jedoch nicht /tmp/k233. jan@k500:/work> df /work Dateisystem 1k-Blöcke Benutzt Verfügbar Ben% montiert auf k233:/work 38506520 27178380 9372068 75% /work Jetzt die Versuche, auf der Client-Seite in die drei gelinkten Verzeichnisse zu wechseln: jan@k500:/work> cd link_im_fs/ jan@k500:/work/link_im_fs> ls books fun midi mp3 ogg playlists Das ist ok, so sieht das Verzeichnis audio aus. jan@k500:/work/link_im_fs> cd ../link_jan/ jan@k500:/work/link_jan> ls Desktop Mail music public_html tmp Documents XEphem plugin131.trace software Das ist definitiv der Inhalt des Verzeichnis /home/jan auf dem Client! Auf dem Server sieht das anders aus: k233:/work# ls /home/jan tmp jan@k500:/work/link_jan> cd .. jan@k500:/work> cd link_nach_aussen bash: cd: link_nach_aussen: Datei oder Verzeichnis nicht gefunden q.e.d. Jan
Peter Baumgartner wrote:
Am Freitag, 28. Februar 2003 16:15 schrieb Raimund Hölle:
Aber dann ist mir dein Problem natürlich klar - NFS ist eben etwas _völlig_ anderes als Samba! Ein Soft-Link ist letztendlich nichts anderes als eine Datei, in der ein Zieldateiname steht. Dieser Link wird jedoch bei NFS nicht auf dem Server (wie bei Samba) sondern auf dem Client aufgelöst! Hast du also auf deinem Client kein Verzeichnis "/data/dose", läuft der Link natürlich immer ins leere, dies hat überhaupt nichts mit deiner SuSE-Version zu tun; es war noch nie anders!
Mounte also auf deinem Client "nfsserver:/data/dose" unter "/data/dose".
Mit dem Namen des mounts hat das nichts zu tun: Ob ich das unter "/data/dose/" oder "/home/blabla/Wurstkessel" mounte, hat überhaupt keinen Einfluß auf die Rechte oder Sichtbarkeit - z.B.: mount -t nfs yello:/home/peter /home/peter/server liefert prompt das gewünschte Ergebnis. Der im gemounteten Ordner enthaltene Link "/data/dose" wird ausgegrayt und ist
weil auf dem rechner '/data/dose' nicht existiert. der exportierte link zeigt also ins leere.
unknown, während z.B. ein auf "/home/mac/gifs" zeigender Link funktioniert.
dann gibt es '/home/mac/gifs' auf beiden rechnern. deshalb greift der link.
Na ja, ich will dann noch etwas googeln (seufz).
ich denke es würde reichen den text von Raimund noch mal zu lesen. micha
Hallo Michael, Am Dienstag, 4. März 2003 22:48 schrieb Michael Meyer:
Peter Baumgartner wrote:
weil auf dem rechner '/data/dose' nicht existiert. der exportierte link zeigt also ins leere.
unknown, während z.B. ein auf "/home/mac/gifs" zeigender Link funktioniert.
dann gibt es '/home/mac/gifs' auf beiden rechnern. deshalb greift der link.
Nein, eben nicht! Der Link auf das Verzeichnis /home/mac/gifs. in das Verz. /home/peter heißt "bilder"und wird von den Clients aufgelöst.
Na ja, ich will dann noch etwas googeln (seufz).
ich denke es würde reichen den text von Raimund noch mal zu lesen.
Das ufert jetzt etwas aus, ich will erst mal mit Raimund, wie er oben vorgeschlagen hat, nochmal präzisieren, worüber wir reden, sonst labern wir uns ohne Ergebnis die Köpfe wund, OK? Gruß Peter
Am Dienstag, 25. Februar 2003 17:21 schrieb Peter Baumgartner: Hallo, ich habe selbst (sic!) mal ein bißchen gegrübelt und in /var/log/messages finde ich folgendes Genörgel vom portmap Dämon: -------------------------snip--------------------- Feb 26 12:17:13 yello portmap[776]: warning: /etc/hosts.allow, line 10: missing ":" separator Feb 26 12:17:13 yello portmap[776]: warning: /etc/hosts.allow, line 12: missing ":" separator Feb 26 12:17:13 yello portmap[776]: warning: /etc/hosts.allow, line 13: missing ":" separator Feb 26 12:17:13 yello portmap[776]: warning: /etc/hosts.allow, line 18: missing ":" separator Feb 26 12:17:13 yello portmap[776]: warning: /etc/hosts.allow, line 19: missing ":" separator Feb 26 12:17:13 yello portmap[776]: warning: /etc/hosts.allow, line 27: missing ":" separator ----------------------snap------------------------------- die entsprechenden Zeilen in der (von Yast erstellten) /etc/hosts.allow sind: -----------------------snip----------------------------- # package name | daemon path | token # ---------------------------------------------------------------------------- ssh, openssh | /usr/sbin/sshd | sshd, sshd-fwd-x11, sshd-fwd-<port> # quota | /usr/sbin/rpc.rquotad | rquotad tftpd | /usr/sbin/in.tftpd | in.tftpd portmap | /sbin/portmap | portmap # The portmapper does not verify against hostnames # to prevent hangs. It only checks non-local addresses. # # (kernel nfs server) nfs-utils | /usr/sbin/rpc.mountd | mountd nfs-utils | /sbin/rpc.statd | statd # # (unfsd, userspace nfs server) # nfs-server | /usr/sbin/rpc.mountd | rpc.mountd # nfs-server | /usr/sbin/rpc.ugidd | rpc.ugidd # # (printing services) # lprng | /usr/sbin/lpd | lpd cups | /usr/sbin/cupsd | cupsd # The cupsd server daemon reports to the cups ---------------------snap------------------ mir ist nicht so klar, wo da Doppelpunkte hinsollen, etwa statt der Pipes, früher sah das völlig anders aus - neuer Gag von SuSE?? Kennt sich da jemand aus? Aber das hat AFAIK nichts mit den Leserechten für Clients, sondern nur in der "anderen Richtung" zu tun, also wohl keine so ganz gute Idee? Grüße Peter Baumgartner
Am Mit, 2003-02-26 um 12.59 schrieb Peter Baumgartner:
Am Dienstag, 25. Februar 2003 17:21 schrieb Peter Baumgartner: Hallo, ich habe selbst (sic!) mal ein bißchen gegrübelt und in /var/log/messages finde ich folgendes Genörgel vom portmap Dämon:
-------------------------snip--------------------- Feb 26 12:17:13 yello portmap[776]: warning: /etc/hosts.allow, line 10: missing ":" separator
----------------------snap-------------------------------
die entsprechenden Zeilen in der (von Yast erstellten) /etc/hosts.allow sind:
-----------------------snip----------------------------- # package name | daemon path | token # ---------------------------------------------------------------------------- ssh, openssh | /usr/sbin/sshd | sshd, sshd-fwd-x11, sshd-fwd-<port>
mir ist nicht so klar, wo da Doppelpunkte hinsollen, etwa statt der Pipes, früher sah das völlig anders aus - neuer Gag von SuSE?? ROTFL, ... entweder hat YaST da Murks gebaut, oder aber derjenige zwischen Bildschirm und Tastatur ... SCNR.
Dort wurden die '#' aus einem Beschreibungskommentar entfernt, statt eine echte hosts.allow erstellt. .. # short overview about daemons and servers that are built with # tcp_wrappers support: # # package name | daemon path | token # ---------------------------------------------------------------------------- # ssh, openssh | /usr/sbin/sshd | sshd, sshd-fwd-x11, sshd-fwd-<port> # quota | /usr/sbin/rpc.rquotad | rquotad # tftpd | /usr/sbin/in.tftpd | in.tftpd ..
Kennt sich da jemand aus?
Nicht die Kommentarzeichen entfernen, sondern Regel erstellen! man 5 hosts_access man 5 hosts_options Ralf
Am Mittwoch, 26. Februar 2003 13:49 schrieb Ralf Corsepius:
Am Mit, 2003-02-26 um 12.59 schrieb Peter Baumgartner:
Am Dienstag, 25. Februar 2003 17:21 schrieb Peter Baumgartner: Hallo, ich habe selbst (sic!) mal ein bißchen gegrübelt und in /var/log/messages finde ich folgendes Genörgel vom portmap Dämon:
-------------------------snip--------------------- Feb 26 12:17:13 yello portmap[776]: warning: /etc/hosts.allow, line 10: missing ":" separator
----------------------snap-------------------------------
die entsprechenden Zeilen in der (von Yast erstellten) /etc/hosts.allow sind:
-----------------------snip----------------------------- # package name | daemon path | token # ------------------------------------------------------------------------- --- ssh, openssh | /usr/sbin/sshd | sshd, sshd-fwd-x11, sshd-fwd-<port>
mir ist nicht so klar, wo da Doppelpunkte hinsollen, etwa statt der Pipes, früher sah das völlig anders aus - neuer Gag von SuSE??
ROTFL, ... entweder hat YaST da Murks gebaut, oder aber derjenige zwischen Bildschirm und Tastatur ... SCNR.
Hm, das Problem sitzt 30 cm vor dem Schirm??
Dort wurden die '#' aus einem Beschreibungskommentar entfernt, statt eine echte hosts.allow erstellt.
Wer lesen kann, ist klar im Vorteil! Danke für den Hinweis.
.. # short overview about daemons and servers that are built with # tcp_wrappers support: # # package name | daemon path | token # --------------------------------------------------------------------------- - # ssh, openssh | /usr/sbin/sshd | sshd, sshd-fwd-x11, sshd-fwd-<port> # quota | /usr/sbin/rpc.rquotad | rquotad # tftpd | /usr/sbin/in.tftpd | in.tftpd ..
Kennt sich da jemand aus?
Nicht die Kommentarzeichen entfernen, sondern Regel erstellen!
Nutzt nichts, auch "all : all : allow", was ja wohl ein "Scheunentor" ist, bringt keinen Unterschied: Der Link läuft auf dem Server und auf Samba Clients, auf Linux Clients bleibt er "unknown". Also muß ich weitersuchen!
man 5 hosts_access man 5 hosts_options
Ralf
hm, habe die mail zurückbekommen, mein postfix scheint zu meutern, schicke es nochmal über smtp Peter
participants (7)
-
Jan.Trippler＠t-online.de -
Michael Meyer -
Peter Baumgartner -
Raimund Hölle -
Ralf Corsepius -
Tamer Higazi -
Wolfgang Hinsch