Winprosa: externe Kurswahlerfassung

Hej,
ja, sorry. War unpräzise :wink:

Dieses Mal noch lmn6.2…
Grüße
Michael

Hej,

Habs vorhin nochmal versucht. Bei uns bekommen Projekt-Tauschverzeichnisse die Berechtigung 644. Wenn die Infos vom Thread-Anfang stimmen, kann das eigentlich nicht mehr funktionieren.


Ich scheitere jetzt am Anlegen und Mounten des Shares. Wäre toll, wenn jemand meinen Fehler findet… Vorweg: Es ist geht um einen Ubuntu 16.04-Client unter LMN 6.2 :wink:

Also: Ich habe nun - wie oben beschrieben - das Folgende share auf dem Server in /etc/samba/smb.conf.shares eingetragen

[kurswahl]
   comment = WinProsa Kurswahl
   path = /home/samba/kw
   guest ok = no
   writeable = yes
   force create mode = 0666
   force directory mode = 0777

Das Verzeichnis /home/samba/kw auf dem Server gehört administrator:teachers
Dann habe ich mit sudo service smbd restart den samba-deamon neu gestartet.

Auf dem Clienten habe ich in /etc/security/pam_mount.conf.xml das hier am Ende eingetragen:

<volume options="rw,nosuid,nodev" user="*" mountpoint="/home/samba/kw" path="kurswahl" server="10.32.1.1" fstype="cifs" />

Hätte nun naiv gehofft, dass das so klappt… Pustekuchen.
Das Einbinden klappt schon nicht… Entsprechend kann ich auch gar nicht feststellen, ob das Share richtig angelegt ist…

Wie macht man denn das richtig?
Bitte um Hilfe. Danke und Grüße
Michael

Hallo Michael!

Wem gehört das Verzeichnis /home/share/kw? Vergleiche das mal mit dem restlichen Inhalt.

Ersetze mal

 writable = yes 

durch

 write list = @domadmins, @teachers 

Beste Grüße

Thorsten

Hej,

das Share-Verzeichnis heißt /home/samba/kw und gehört auf dem Server administrator:teachers

Irgendwas mache ich aber grundlegend falsch… Egal. Die Ferien waren zu voll für diese Baustelle.
Ich habe es nun wie @ironiemix mit einem eigenen Benutzer gelöst über das Tauschverzeichnis gelöst.

Nächstes Jahr dann elegant…

Danke trotzdem fürs Mitdenken!
Grüße
Michael

Hallo Michael,

Wem gehört das Verzeichnis /home/share/kw?

das Share-Verzeichnis heißt |/home/samba/kw| und gehört auf dem Server
administrator:teachers

vorsicht: beim Zugriff via samba gibt es auch noch die ACLs zwischen
Client und Dateisystem.

LG

Holger

Hallo zusammen,

ich muss den Thread nochmal aufmachen. Nachdem wir längere Zeit keine Probleme mit der Kurswahl haben klappt es dieses Jahr (7.1) nicht.
Wir haben hierfür die vergangenen Jahre immer problemlos wine verwendet.

Ich habe die Dateien auf dem Server ins schuwleite Verzeichnis kopiert. Leider kann ich schon nicht an 2 Rechnern das Programm starten, da beim zweiten öffnen die Lockdatei nicht gefunden wird.
Ich habe sogar extra einen Windows Rechner verwendet um global jedem alles auf dieser Datei zu erlauben, leider erfolglos. Hat da noch jemand einen Vorschlag?

…ergänzende Info: Als es noch funktioniert hat, waren wir noch auf der Version 6.2.

Hallo Björn,

wie sind denn die Rechte der Sperrdatei, wenn der erste User das Programm gestartet hat?

Ich habe früher immer mit „force create mode = 666“ gearbeitet - aber das waren die alten Zeiten, als Samba noch nicht als AD-Controller arbeitete.

Beste Grüße

Jörg

So hier erstmal die Dateirechte:

Auf dem selben Rechner kann ich sie auch zweimal öffnen. Öffne ich die Datei aber auf einem anderen Rechner kommt eine Fehlermeldung

Hallo Björn,

was sagt den der winprosa support dazu, dass das Programm von mehreren
Rechnern aus gleichzeitig geöffnet wird?
Ist das so vorgesehen?
(normale Programm verwenden ja für den gleichzeitigen Zugriff von
mehreren usern dieses brandneue Konzept „Datenbank“ …verrückt …).
Frag die doch mal welche Dateien welche Rechte haben müssen.

LG

Holger

Ich hab das gleiche im Verwaltungsnetz probiert. Da geht das völlig stressfrei über eine gemeinsame Freigabe und so war das in der Vergangenheit auch bei uns im Schulnetz. Ich wüsste jetzt ehrlich gesagt auch nciht warum die das auf den letzten Metern nochmal grundsätzlich ändern sollten.

Hallo Björn,

wir machen das mit der 6.2 in einem Projekt-Tauschverzeichnis mit folgenden Rechten:

clip_image002.jpg

Viele Grüße
Jürgen

So hier noch die Fehlermeldung:
image

Hej @MirDochEgal ,
konntest Du das lösen? Es war bei mir das gleiche Problem. Ist bei uns leider erst während der Kursvorwahl aufgefallen. :pensive:

Grüße
Michael

Hallo @Sedding,

wir mussten auch bei der aktuellen Version von Winprosa die Rechte rekursiv auf 777 setzen.

Viele Grüße
Jürgen Gaisser

Hallo Jürgen,
ich bin unter der LMN7 unterwegs - da ist das einfache (Linux Dateiberechtigungen) leider prinzipiell nicht mehr die Lösung. :cry:
Ich habe schon die ACLs in Verdacht.
Danke trotzdem für die Antwort.
Grüße
Michael

Hallo,
ich frage auch mal wieder, ob jemand mit dem Winprosa-Problem weitergekommen ist? In der v7 ist es ja nach wie vor schwierig Dateirechte beim Transfer an andere User weiterzugeben.

Also war meine Überlegung einen neuen temporären Lehrer-Account anzulegen, in dessen Home ich die Winprosa-Dateien ablege.
Allerdings kann selbst der neu angelegte teacher die winprosa.exe nicht mit Wine öffnen. Es kommt folgende Fehlermeldung:
WinprosaWineFehler

Das komische ist, dass ich die Datei mit meinem eigenen Lehrer-Account ganz normal mit Wine öffnen kann?!? Ich habe an der Datei vorher nichts geändert.
Hat jemand eine Idee?

Grüße
Daniel

Hallo zusammen,

wir sind auch gerade auf das gleiche Problem gestoßen. Der linuxadmin kann winprosa per Wine starten, die Domänenbenutzer nicht. Auch das Setzen der Rechte auf 777 hat nichts an dieser Situation geändern, es erscheint die bereits gepostete Fehlermeldung. winprosa liegt im übrigen nicht auf einem Share, sondern lokal.

Da wir winprosa nur temporär benötigen, haben wir uns jetzt damit geholfen, dass wir einen lokalen Benutzer (unter KDE neon) angelegt haben. Dieser kann winprosa genauso wie der linuxadmin per Wine öffnen. Vielleicht hilft das ja dem ein oder anderen, auch wenn es keine dauerhafte Lösung ist.

Viele Grüße
Christoph

Hallo Christoph,
das ist eine gute Idee. Ich habe das gerade bei unserem Ubuntu 20.04 Image ausprobiert und es scheint zu klappen :+1:.
Nur eine wichtige Frage hätte ich jetzt noch: Wie schaffst du es, den neuen lokalen User durch den prepare-Image-Prozess zu bringen? Dort werden doch meines Wissens alle lokalen User außer der linuxadmin gelöscht?! Hast du einfach ein Image geschrieben ohne prepare-Image auszuführen?

LG
Daniel

Hallo Daniel,

bei mir gibt es mehrere lokale Nutzer, die das linuxmuster-linuxclient prepare Prozedere unangetastet lässt.
Einfach mal testen… :slight_smile:

Vg, Tobias