ubuntuusers.de

Nach einem Mount mit pyNeighborhood 0.4 werden bei mir die Benutzerrechte nicht richtig gesetzt. Es wird immer mein eigener Benutzer und meine eigene Gruppe für jedes Verzeichnis und jede Datei angezeigt. Das gleiche Problem habe ich, wenn ich als normaler Benutzer mount.cifs ausführe. Nur wenn ich mount.cifs per sudo ausführe, erhalten die Dateien die Benutzer und Gruppen, wie auf dem Server, der übrigens die UNIX extensions unterstützt. Dieses Verhalten ist in den Wiki-Artikeln zu pyNeighborhood und CIFS leider nicht erwähnt. Bei demjenigen über CIFS wird das Mounten per sudo als normaler Weg beschrieben und nur am Rande erwähnt, dass es auch als normaler Benutzer geht, wenn bei mount.cifs das SUID-Bit gesetzt ist. Die Nebenwirkungen auf die angezeigten Benutzer und Gruppen sind nicht erwähnt.

pyNeighborhood 0.5 kann den Mount mit sudo ausführen. Aber leider funktioniert dieser nicht. Es gibt immer eine Fehlermeldung, die mir aber nicht weiter hilft.

Nach der Installation der Version 0.5 ist in der Konfiguration jedoch nicht sudo eingetragen, sondern gtksu. Wenn ich dies so lasse, hängt der Mount-Befehl, ich sehe ihn als offenen Prozess. Und nach einer sehr langen Zeit erhalte ich dann die Meldung, dass das Dateisystem nicht gemountet werden kann. M.E. hängt es damit zusammen, wie das Passwort übergeben wird. Auch mit gksudo funktioniert es nicht. Als normaler Benutzer hingegen schon, dann habe ich aber wieder das oben beschriebene Problem.

Fazit: das Programm ist für mich unbrauchbar. Sorry. Ich werde versuchen, dem Upstream einen Bugreport zu schreiben. Hat das jemand von euch erfolgreich im Einsatz? Wenn ja, was mache ich falsch?

Dieses Verhalten ist in den Wiki-Artikeln zu pyNeighborhood und CIFS leider nicht erwähnt.

Der Artikel Samba Client pyNeighborhood ist vor Ubuntu 8.04 entstanden. Leider war man bei Ubuntu der Meinung, ab Hardy einiges Altbewaehrtes (smbfs) ersatzlos zu streichen...

Es gibt immer eine Fehlermeldung, die mir aber nicht weiter hilft.

Und die lautet?

Fazit: das Programm ist für mich unbrauchbar.

Was willst Du denn genau erreichen? Vielleicht ist Samba Client fusesmb eine Alternative?

Es gibt einen Mount-Error. Einen solchen gibt es aber auch, wenn das Verzeichnis, wohin gemountet werden soll, für den angemeldeten Benutzer nicht beschreibbar ist. Also ist man nie sicher, ob der Fehler tatsächlich beim Mounten liegt und nicht wo anders. Die genaue Fehlermeldung muss ich erst wieder nachschlagen. Sie sagt m.E. nicht viel aus.

Ich möchte, dass ein Benutzer sich die Dateiablage mit einer grafischen Oberfläche einbinden kann, so dass die Benutzer- und Gruppenrechte richtig angezeigt werden. Theoretisch könnte ich Nautilus dafür nehmen, aber dieser zeigt die erwähnten Dinge eben nicht an.

Bis jetzt lief nur der Dateiserver mit Linux, alle Clients waren bisher Windows. Jetzt will ich den ersten Linux-Client ins Netzwerk einbinden und muss feststellen, dass das gar nicht so einfach ist.

Ich könnte natürlich auch NFS nehmen, aber da habe ich andere Probleme, auf die mir niemand Antwort gibt.

dbet schrieb:

Nach einem Mount mit pyNeighborhood 0.4 werden bei mir die Benutzerrechte nicht richtig gesetzt.

0.4 macht so einiges Falsch, und wird auch nicht mehr weiter Entwickelt.

pyNeighborhood 0.5 kann den Mount mit sudo ausführen. Aber leider funktioniert dieser nicht. Es gibt immer eine Fehlermeldung, die mir aber nicht weiter hilft.

Welche Fehlermeldung den genau? Das sollte ich fixen können.

Ich werde versuchen, dem Upstream einen Bugreport zu schreiben.

Das bin ich, die Entwicklung habe ich vor ein paar Monaten übernommen. Leider komme ich momentan zeitlich nur wenig dazu die Bugs zu fixen. Sonst würde da auch nicht mehr -rc* stehen, sondern wir wären schon bei 0.5.1! Du kannst mir viele Fehlerausgaben zukommen lassen wenn du das hier machst:

python -d /usr/bin/pyNeighborhood

Das solltest du auf einem Terminal machen, dannach sollte so einiges an Debug ausgaben über das Terminal rauschen.

mfg Betz Stefan

Cool, da treffe ich den Entwickler persönlich! Ich werde dir gerne die Meldungen schreiben, leider kann ich das wahrscheinlich erst Ende Woche tun. Bis dahin erst einmal das Feedback, dass ich die Datei TODO erstellen musste, um aus deinem Source das Debianpaket bauen zu können.

dbet schrieb:

Bis dahin erst einmal das Feedback, dass ich die Datei TODO erstellen musste, um aus deinem Source das Debianpaket bauen zu können.

Fixed (in der SVN Version), am besten holst du dir eh die SVN Version da ich hier alle Bugfixes reinpacke:

svn co https://pyneighborhood.svn.sourceforge.net/svnroot/pyneighborhood/trunk pyneighborhood

mfg Betz Stefan

Die Fehlermeldung lautet:

mount error 13 = Permission denied
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

Ich sehe, wo das Problem liegt. Es wird folgender Befehl zusammengebaut:

Creating Options Dialog
/usr/bin/gksu -- /sbin/mount.cifs //192.168.1.1/Daten /home/dbet/pyNeighborhood/XXX/YYY/Daten -o username=dbet

Hier wartet das Programm, bis ich diesen Befehl per kill töte. Danach erscheint im Debugfenster

Password:

Also wartet mount.cifs auf die Eingabe des Passworts. Das Warten wurde durch den Kill abgebrochen und die Fehlermeldung 13 erscheint.

Das gleiche geschieht, wenn ich statt gksu das Programm sudo verwende (als Parameter eintrage). Nur sehe ich dann gleich im Debugfenster, dass der Mount-Befehl auf das Passwort wartet und ich kann es sogar eingeben! Es wird dann richtig gemountet.

Zum Testen habe ich in host.py folgende Zeile eingefügt:

options.append("password=%s" % password)

Dann funktioniert der Mount. Es liegt also wahrscheinlich daran, dass die Umgebungsvariable PASSWD nicht so gesetzt wird, dass sie ausgewertet werden kann. Vorschlag: eine Datei mit den Rechten 600 nach /tmp schreiben, die Benutzername und Passwort enthält und diese mit credentials= nutzen.

Gerne probiere ich für dich auch noch andere Varianten aus.

Gemäss mount.cifs-Manpage sollte es user= heissen und nicht username=. Findest du es nicht auch besser, dies zu verwenden, auch wenn username= aus Kompatibilitätsgründen (noch) funktioniert?

Noch ein anderes Problem: nebst dem Sambaserver habe ich auch noch ein Windows XP im Netzwerk. Von diesem zeigt es mir die Shares nicht an, nur vom Samba-Server. Die Fehlermeldung im Debugfenster ist die:

OUTPUT -- OUTPUT -- OUTPUT
WINDOOF
Append Workgroup: 
Append Host: WINDOOF
Scanning for Shares:
IP Lookup for: LINUX
Aufruf: smbclient [-?] [-?EgV] [-?EgV] [-?EgVNkP] [-?|--help] [--usage]
        [-R|--name-resolve NAME-RESOLVE-ORDER] [-M|--message HOST]
        [-I|--ip-address IP] [-E|--stderr] [-L|--list HOST] [-t|--terminal CODE]
        [-m|--max-protocol LEVEL] [-T|--tar <c|x>IXFqgbNan] [-D|--directory DIR]
        [-c|--command STRING] [-b|--send-buffer BYTES] [-p|--port PORT]
        [-g|--grepable] [-d|--debuglevel DEBUGLEVEL]
        [-s|--configfile CONFIGFILE] [-l|--log-basename LOGFILEBASE]
        [-V|--version] [-O|--socket-options SOCKETOPTIONS]
        [-n|--netbiosname NETBIOSNAME] [-W|--workgroup WORKGROUP]
        [-i|--scope SCOPE] [-U|--user USERNAME] [-N|--no-pass] [-k|--kerberos]
        [-A|--authentication-file FILE] [-S|--signing on|off|required]
        [-P|--machine-pass] service <password>

Shares found: {}
OUTPUT -- OUTPUT -- OUTPUT
querying LINUX on 127.255.255.255
linux.domain.local, 192.168.1.1 LINUX<00>

Wahrscheinlich wird smbclient mit einem ungültigen Parameter aufgerufen.

Der WinXP-Rechner ist nicht in der gleichen Workgroup. Vielleicht ist dies das Problem. Als Folge wird im linken Fenster ein Icon ohne Namen dahinter angezeigt. Darunter wird aber dann der Name der Arbeitsstation angezeigt.

Wenn der Share gemountet ist, sollte er mit Nautilus geöffnet werden können. Doch wie macht man das? Ich sehe keinen Hinweis. Rechtsklick auf den Share oder Doppelklick bleiben ohne Wirkung. Mit der Version 0.4 funktionierte dies.

Müsste beim Dateimanager-Parameter nicht zusätzlich

--no-desktop

hinter Nautilus stehen?

Apropos Rechtsklick: ich würde es begrüssen, wenn es auf dem gemounteten Share ein Kontextmenü gäbe, welches nebst dem Öffnen mit dem Dateimanager auch das Ausbinden anbieten würde. Ich brauchte einige Zeit, bis ich das Symbol oberhalb entdeckte, womit ich Ausbinde.

Auch im linken Fenster finde ich ein Kontextmenü besser. Ich brauchte mehrere Minuten bis ich herausfand, dass man zum Mounten die Freigabe vom linken Fenster ins rechte ziehen muss.

dbet schrieb:

Hier wartet das Programm, bis ich diesen Befehl per kill töte.

Also ein Problem bei der Passwortübergabe ☹

Zum Testen habe ich in host.py folgende Zeile eingefügt...

Ist leider unsicher, da man z.b. mit ps dann das Passwort sehen könnte, wovon ich ganz und garnichts halte.

Dann funktioniert der Mount. Es liegt also wahrscheinlich daran, dass die Umgebungsvariable PASSWD nicht so gesetzt wird, dass sie ausgewertet werden kann.

Ich habe damals nur Gutsy zum testen genommen, vielleicht hat sich was an sudo geändert und daher zickt pyNeighborhood rum. Ich werde mir mal ne Test-VM mit Hardy, Gutsy und Intrepid aufsetzen unter der Woche. Dann probiere ich das dort mal alles aus!

Vorschlag: eine Datei mit den Rechten 600 nach /tmp schreiben, die Benutzername und Passwort enthält und diese mit credentials= nutzen.

Wäre auch eine Möglichkeit, wobei mir das mit der Environmentvariable oder STDIN vom mount.cifs viel lieber wäre...

Findest du es nicht auch besser, dies zu verwenden, auch wenn username= aus Kompatibilitätsgründen (noch) funktioniert?

Das ist ne Kleinigkeit, ist gefixt in SVN Revision 320.

dbet schrieb:

Mit der Version 0.4 funktionierte dies.

Dieses Feature gibt es aktuell lieder nicht nicht in der 0.5er Entwicklungslinie.

ich würde es begrüssen, wenn es auf dem gemounteten Share ein Kontextmenü gäbe, welches nebst dem Öffnen mit dem Dateimanager auch das Ausbinden anbieten würde.

Das kommt nach 0.5.0, neue Features kommen nicht mehr in die 0.5.0... Da will ich jetzt nur noch Bugfixes reinmachen damit man es überhaupt mal wieder richtig verwenden kann.

Ich brauchte mehrere Minuten bis ich herausfand, dass man zum Mounten die Freigabe vom linken Fenster ins rechte ziehen muss.

Dokumentation brauch ich auch noch, es gibt viel zu tun 😉

Wegen dem Problem mit Windows, darüber habe ich schon was gelesen... Das werde ich mir auch mal ansehen wenn ich dazu kommen, kann so ja nicht sein!

mfg Betz Stefan

Ich brauchte mehrere Minuten bis ich herausfand, dass man zum Mounten die Freigabe vom linken Fenster ins rechte ziehen muss.

encbladexp wird sich erinnern: Mir ging es genau so! Frage: Ist es wirklich so viel Arbeit, alternativ noch einen Doppelklick im linken Fenster anzubieten? Das probiert doch erstmal jeder. Und in Version 4 ging das ja.

Gruß - Max-Ulrich

encbladexp schrieb:

dbet schrieb:

Hier wartet das Programm, bis ich diesen Befehl per kill töte.

Also ein Problem bei der Passwortübergabe ☹

Zum Testen habe ich in host.py folgende Zeile eingefügt...

Ist leider unsicher, da man z.b. mit ps dann das Passwort sehen könnte, wovon ich ganz und garnichts halte.

Klar, war auch nur ein Test, um das Problem einzukreisen.

Dann funktioniert der Mount. Es liegt also wahrscheinlich daran, dass die Umgebungsvariable PASSWD nicht so gesetzt wird, dass sie ausgewertet werden kann.

Ich habe damals nur Gutsy zum testen genommen, vielleicht hat sich was an sudo geändert und daher zickt pyNeighborhood rum. Ich werde mir mal ne Test-VM mit Hardy, Gutsy und Intrepid aufsetzen unter der Woche. Dann probiere ich das dort mal alles aus!

Vorschlag: eine Datei mit den Rechten 600 nach /tmp schreiben, die Benutzername und Passwort enthält und diese mit credentials= nutzen.

Wäre auch eine Möglichkeit, wobei mir das mit der Environmentvariable oder STDIN vom mount.cifs viel lieber wäre...

Findest du es nicht auch besser, dies zu verwenden, auch wenn username= aus Kompatibilitätsgründen (noch) funktioniert?

Das ist ne Kleinigkeit, ist gefixt in SVN Revision 320.

dbet schrieb:

Mit der Version 0.4 funktionierte dies.

Dieses Feature gibt es aktuell lieder nicht nicht in der 0.5er Entwicklungslinie.

Dann nimm bitte im Einstellungsdialog die Möglichkeit weg, den Dateimanager konfigurieren zu können.

ich würde es begrüssen, wenn es auf dem gemounteten Share ein Kontextmenü gäbe, welches nebst dem Öffnen mit dem Dateimanager auch das Ausbinden anbieten würde.

Das kommt nach 0.5.0, neue Features kommen nicht mehr in die 0.5.0... Da will ich jetzt nur noch Bugfixes reinmachen damit man es überhaupt mal wieder richtig verwenden kann.

Verstehe ich.

Ich brauchte mehrere Minuten bis ich herausfand, dass man zum Mounten die Freigabe vom linken Fenster ins rechte ziehen muss.

Dokumentation brauch ich auch noch, es gibt viel zu tun 😉

Die Tooltips funktionieren bei mir nicht. Im Debugmodus sehe ich, dass das Programm dafür PyGTK 2.12 verlangt. Ich habe python-gtk2 in Version 2.12 installiert, ausserdem konnte ich das Paket ohne Abhängigkeitsprobleme installieren. Ich verstehe nicht, was noch fehlen sollte.

Wegen dem Problem mit Windows, darüber habe ich schon was gelesen... Das werde ich mir auch mal ansehen wenn ich dazu kommen, kann so ja nicht sein!

mfg Betz Stefan

Also der Doppelklick ist das was ich noch mit reinnehme, den Button für den Dateimanager mache ich einfach im Glade Dialog aus "Disabled" dann ist er ausgegraut und nicht nutzbar.

mfg Betz Stefan

encbladexp schrieb:

dbet schrieb:

Findest du es nicht auch besser, dies zu verwenden, auch wenn username= aus Kompatibilitätsgründen (noch) funktioniert?

Das ist ne Kleinigkeit, ist gefixt in SVN Revision 320.

So, wie du es gemacht hast, würde es nun aber mit smbmount nicht mehr funktionieren. Dies nur als Hinweis.

encbladexp schrieb:

Also der Doppelklick ist das was ich noch mit reinnehme, den Button für den Dateimanager mache ich einfach im Glade Dialog aus "Disabled" dann ist er ausgegraut und nicht nutzbar.

Das wäre für mich OK. Wenn nur das Mounten per sudo endlich geht.