Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
Darf ich noch einen kleinen Tipp nachtragen: Durch Upstart treten bei Netzwerk-Automounts via fstab häufig Probleme auf, weil man sich nicht mehr auf eine bestimmte Boot-Reihenfolge verlassen kann. Ich verwende zum Herstellen von Netzwerk-Verbindungen WICD (für LAN und WLAN). Dort gibt es für jedes einzelne Netzwerk die optionalen Einträge "Post-connection Script" und "Pre-disconnection Script". Hier trage ich mein Mount- und Umount-Script ein und fertig. Bei Lucid muss ich allerdings noch für mount.cifs und umount.cifs das SUID-Bit setzen, da dieses - wohl aus Sicherheitsgründen - nicht mehr mehr automatisch gesetzt wird. Einfacher geht's eigentlich nicht. Und die vielfach beschriebenen Boot- und Shutdown-Probleme sind weg. Gruß - Max-Ulrich
|
Panwan
(Themenstarter)
Anmeldungsdatum: 2. Mai 2010
Beiträge: 15
|
Konnte mich leider aufgrund von Internetproblemen (verdammte Telecom Italia!! 😉) die vergangene Woche nicht mehr melden. Großes Dankeschön an Max-Ulrich für die Hilfestellungen. Werde Ende dieser Woche wieder Zugriff auf den betroffenen Computer haben und dann die Tipps ausprobieren. Sofern alles funktioniert, können wir hier ja kurz eine Liste von möglichen Gegenmaßnahmen zum neuen Automount-Verhalten reinstellen (inkl. möglicher Gefahren –> SUID).
Nochmals vielen Dank!
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
inkl. möglicher Gefahren –> SUID
Die sind im Heim- und SOHO-Bereich IMHO zu vernachlässigen. Bei Samba sowieso, weil man da ja auf dem Server den Zugriff sehr genau festlegen kann. Man kann auch auf jedem Schraubendreher den Hinweis anbringen "Vorsicht, nicht als Zahnstocher und nicht zum Reinigen der Ohren geeignet!" 😉
|
Panwan
(Themenstarter)
Anmeldungsdatum: 2. Mai 2010
Beiträge: 15
|
Hmmm, irgendwas mache ich falsch. Habe das SUID-Bit für mount.cifs und umount.cifs gesetzt (per sudo find / -perm +6000
überprüft). Habe auch WICD installiert und dort das Post-connection Script eingestellt: Da ich Anfänger bin, dachte ich mir, dass ich einfach mal auf rc.local linken kann (hier schon der Fehler??) und entsprechend dieses mein Script darstellt. Das Netzlaufwerk wird aber immer noch nicht eingehängt. Habe dann einfach mal versucht, manuell das Laufwerk einzuhängen (mount -a). Dies funktioniert aber nur mit root-Rechten. Bitte nicht hauen (ja, ich bin ein Noob 😉), aber ich dachte, dass das Setzen des SUID-Bits der entsprechenden Datei root-Rechte verleiht, d. h. dass diese Datei, sobald sie ausgeführt wird, root-Rechte besitzt und ich für ihre Ausführung kein sudo-Passwort mehr benötige. So hätte ich mir dann auch die eventuellen Sicherheitsrisiken erklärt. Sorry, wenn das jetzt absoluter Blödsinn war, aber irgendwo hakt es und ich bin mir nicht sicher, woran das liegen kann (anbei bemerkt: Bin auch noch etwas geschlaucht von den Verhandlungen mit Telecom Italia, die uns jetzt endlich an einen näher gelegenen Server angeschlossen haben. Naja, nach 2!!! kaputten Routern und einem DHCP-Server, der nicht macht, was er soll, bin ich froh, jetzt wieder mal ins Forum zu können 😉)
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
Ich war verreist, deshalb habe ich nicht geantwortet. Bin jetzt wieder zu Hause.
dass ich einfach mal auf rc.local linken kann (hier schon der Fehler??) und entsprechend dieses mein Script darstellt
Ja, so einfach geht es leider nicht.
(mount -a). Dies funktioniert aber nur mit root-Rechten.
Das ist normal. Das bezieht sich ja auch auf andere Einträge in der fstab.
So hätte ich mir dann auch die eventuellen Sicherheitsrisiken erklärt.
Die Erklärung stimmt schon, aber sie bezieht sich wie gesagt nicht auf alle Einträge in der fstab. Die Mount- und Umount-Scripte musst Du selbst als einfache Textdateien anfertigen und dann ausführbar machen (z.B. in Nautilus über Eigenschaften → Zugriffsrechte). Sie können dann z.B. so ähnlich aussehen: #! /bin/bash
#
mount.cifs //192.168.1.101/Daten /home/farber/Daten -o rw,uid=1000,gid=1000,credentials=/home/farber/.smbcredentials,iocharset=utf8 0 0 #! /bin/bash
#
umount.cifs /home/farber/Daten Dann trägst Du in WICD die Pfade zu diesen Dateien ein, und fertig. Gruß - Max-Ulrich
|
Panwan
(Themenstarter)
Anmeldungsdatum: 2. Mai 2010
Beiträge: 15
|
Danke nochmals für die Hilfe. Werde das Ganze am Wochenende ausprobieren.
Nur um sicherzugehene, habe ich ein paar Fragen: 1) Für das Skript wird dieselbe Syntax wie für den Eintrag in fstab verwendet, oder? Die bei deinem Beispiel angeführten "credentials" sind nur notwendig, wenn man sich beim Server für die Freigabe anmelden muss, stimmt's? Oder musst man hier das client-eigene sudo-Passwort einfügen (kann ich mir eigentlich nicht vorstellen)? –> Frage nur zur Sicherheit nach, damit es nicht an einem Blödsinn von meiner Seite scheitert. 2) Zum Pfad, den ich bei WICD eintrage: Wenn ich mit dem Texteditor unter Ubuntu eine Datei erstelle, erhält die - linuxtypisch - keine eigene Dateiendung (zumindest sehe ich unter Nautilus keine). Entsprechend enthält der Pfad in WICD ebenfalls keine Dateiendung. Ist das ok, oder gibt es da Probleme (bin schon so Windows-konditioniert, dass ich mir auch solche Problemchen vorstellen kann 😉)? 3) Können dieselben Skripte in der Konsole OHNE sudo-Rechte ausgeführt werden (zur Fehlerkontrolle)?
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
Für das Skript wird dieselbe Syntax wie für den Eintrag in fstab verwendet, oder?
Nein, die gleiche Syntax wie beim mount -Befehl bzw- mount.cifs -Befehl im Terminal. Entsprechend enthält der Pfad in WICD ebenfalls keine Dateiendung. Ist das ok
Die Dateiendung (Suffix) ist in Linux meist ohne Bedeutung. Sie dient mehr zur Orientierung für den Benutzer. Üblich ist bei Shell-Scripten das Suffix .sh . Können dieselben Skripte in der Konsole OHNE sudo-Rechte ausgeführt werden (zur Fehlerkontrolle)?
Wenn für die aufgerufenen Routinen (mount.cifs und umount.cifs ) das SUID-Bit gesetzt ist, ja. Gruß - Max-Ulrich
|
Panwan
(Themenstarter)
Anmeldungsdatum: 2. Mai 2010
Beiträge: 15
|
Hi alle miteinander. nach längerer Forumsabwesenheit kann ich nun endlich mal wieder schreiben. Ich hatte Max-Ulrichs Tipp mit WICD und Skript ausprobiert - leider verursachte WICD einige Probleme bei mir (höchstwahrscheinlich von mir selbst verursacht), sodass ich von der Benützung des Programms absah. Ich dachte, dass sich das Problem vielleicht mit der Zeit durch ein Update von alleine erledigen würde - dies war nicht der Fall. Inzwischen hatte ich bereits meine Leute an das Terminal gewöhnt ^^ Heute nun habe ich mich nochmal dem Thema gewidmet und es nach den anderen Anleitungen hier im Forum bzw. auf der "Baustelle/Samba Client cifs" http://wiki.ubuntuusers.de/Baustelle/Samba_Client_cifs#Probleme-und-Loesungen versucht und ..... ES KLAPPT! Ganz großes Dankeschön an Max-Ulrich Farber für die Anleitung!
Die folgende Kurz-Anleitung basiert auf dem dazugehörigen Wiki-Artikel zu "Baustelle/Samba Client cifs" von Max-Ulrich Farber: 1) Paket "smbfs" herunterladen 2) SUID-Bit für mount.cifs und umount.cifs setzen (Achtung: Mögliche Sicherheitslücke):
sudo chmod +s /sbin/mount.cifs
sudo chmod +s /sbin/umount.cifs 3) Mountpunkt im Heimverzeichnis erstellen:
mkdir ~/lan-ordner 4) Mount-Skript erstellen und im Heimverzeichnis abspeichern:
| #! /bin/bash
#
mount.cifs //192.168.1.12/lan-ordner /home/benutzer/lan-ordner -o iocharset=utf8,uid=1000,gid=1000 0 0
|
5) Mount-Skript ausführbar machen: In Nautilus –> Rechtsklick auf das Skript –> "Eigenschaften → Zugriffsrechte → Datei als Programm ausführen" 6) Pfad zum Skript im Autostart eintragen 7) Wenn alles geklappt hat, sollte nun das Netzlaufwerk nach einem Neustart automatisch eingebunden werden.
Nochmals vielen Dank für die tolle Hilfe, Max-Ulrich! Meiner Ansicht nach ist das Thema damit erledigt. Ich weiß nur nicht, ob ich damit auch das Problem als "fixed" markieren soll, da ja die Lösung nur über einen Umweg erreicht wurde. Was meint ihr?
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
Danke. Das ist zu viel des Lobs!
leider verursachte WICD einige Probleme bei mir
Wicd Version 1.7 hat noch einen Fehler beim Abarbeiten von Skripten. Dieser ist gemeldet, aber es ist leider noch nichts geschehen.
SUID-Bit für mount.cifs und umount.cifs setzen (Achtung: Mögliche Sicherheitslücke):
Die Sicherheitslücke ist irrelevant, wenn man auf dem Server die Zugangsberechtigungen gewissenhaft festgelegt hat. Mount-Skript erstellen
Wegen des SUID-Bit sollte man hier lieber auf den Gast-Zugang verzichten und Benutzername und Kennwort verwenden:
Lege eine Textdatei ~/.smbcredentials an und trage in diese folgende Zeilen ein username=<benutzer>
password=<passwort> (setze für <benutzer> und <passwort> Deine Bezeichnungen ein). Gib im Terminal ein chmod 0600 ~/.smbcredentials Die entsprechende Zeile im Skipt lautet dann mount.cifs //192.168.1.12/lan-ordner /home/benutzer/lan-ordner -o iocharset=utf8,uid=1000,gid=1000,credentials=/home/<benutzer>/.smbcredentials (Die Ziffern 0 0 am Ende sind nur in fstab relevant).
Auf dem Server sollten die entsprechenden Einträge vorgenommen und der Gast-Zugang untersagt sein (siehe nötigenfalls Samba Server GNOME). Dies dürfte dann sicher genug sein.
...ob ich damit auch das Problem als "fixed" markieren soll...?
Ja. Gruß - Max-Ulrich
|
Panwan
(Themenstarter)
Anmeldungsdatum: 2. Mai 2010
Beiträge: 15
|
Hi Max-Ulrich, danke für den Hinweis. Leider hat das NAS nur eine sehr geringe Performance zu bieten - trotz 1GBit-Anschluss kann ich froh sein, wenn ich mal wirklich die 100MBit-Grenze erreiche (naja, die Prozessoren in diesen Consumergeräten sind halt einfach zu schwach). Wenn ich mich nicht irre, wurde in der Bedienungsanleitung oder in entsprechenden Foren darauf hingewiesen, dass die Einschränkung der Nutzerberechtigungen zu Performanceverlusten führen könnten (NAS muss die Berechtigung ja überprüfen) - bei der eh schon geringen Performance würde das zu gr. Einschränkungen mit sich bringen. Da das NAS nur privat verwendet wird, würde ich also - sofern du nicht gravierende Sicherheitsmängel siehst - von einer solchen Maßnahme absehen. Der direkte Zugriff auf das NAS u. seine Funktionen ist sowieso nur passwortgeschützt möglich und der dazugehörige Webserver wurde ebenfalls deaktiviert. Schöne Grüße,
Panwan P.S.: Problem wird als gelöst markiert 😉
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
Da das NAS nur privat verwendet wird, würde ich also - sofern du nicht gravierende Sicherheitsmängel siehst - von einer solchen Maßnahme absehen.
Im privaten Gebrauch hinter einem Router mit NAT sehe ich keinerlei Probleme; ich würde es selbst genau so machen. Ich würde es nur nicht öffentlich für die Allgemeinheit so vorschlagen 😉 . Gruß - Max-Ulrich
|
Panwan
(Themenstarter)
Anmeldungsdatum: 2. Mai 2010
Beiträge: 15
|
Ok, danke. Router mit NAT vorhanden, dann passt es ja 😉
|
Panwan
(Themenstarter)
Anmeldungsdatum: 2. Mai 2010
Beiträge: 15
|
Seit dem letzten smbfs-Update (gestern oder vorgestern) scheitert der SMB-Automount wieder. LÖSUNG (zumindest hat es bei mir geklappt): Erneut das SUID-Bit setzen.
|
Panwan
(Themenstarter)
Anmeldungsdatum: 2. Mai 2010
Beiträge: 15
|
Diese Methode scheint mit Ubuntu 10.10 nicht mehr zu funktionieren (vielleicht aufgrund des entfernten umount.cifs). LÖSUNG: Wieder den üblichen fstab-Mount durchführen. Bei NICHT passwortgeschützten Freigaben (wie in diesem Fall) müssen aber in fstab auch die Optionen "username=guest" und "password=" gesetzt werden, damit der Automount klappt. Werden diese Optionen nicht gesetzt, funktioniert das automatische Mounten (seltsamerweise) nicht. Bsp. für einen entsprechen fstab-Eintrag: //servername/sharename /media/mountname smbfs username=guest,password=,uid=1000,iocharset=utf8,codepage=unicode,unicode 0 0 Im konkreten Beispiel:
#Lan-Ordner
//192.168.1.12/lan-ordner /media/lan-ordner smbfs username=guest,password=,iocharset=utf8,uid=1000,gid=1000 0 0 Siehe auch: https://wiki.ubuntu.com/MountWindowsSharesPermanently
|