Sie sind nicht angemeldet.

  • »Tronic69« ist männlich
  • »Tronic69« ist der Autor dieses Themas

Beiträge: 264

Registrierungsdatum: 01.09.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

Andere Betriebssysteme: neben Ubuntu beruflich Solaris sowie (leider) auch SLES 9-11

  • Nachricht senden

1

10.08.2014, 18:55

Dateien auf CIFS- oder NFS-Share werden nicht ausführbar angelegt (ohne x-Flag)

Hallo zusammen,

mein letzter Besuch hier ist schon lange her. Hatte allerdings auch keine unlösbaren Probleme und nicht viel Zeit ...

Wie auch immer, nun habe ich ein Problem für das ich keine Lösung gefunden habe, auch nicht mit Tante Goolge oder der Suche hier.

Ausgangssituation:
Ich habe hier ein Familiennetzwerk, mit einem Fileserver (Ubuntu 14.04 LTS), 2 Linux-Clients (Linux Mint 17 LTS bzw. 17 LTS), 4 Rechner/VMs mit Windows 7 Prof./Ultimate, ein Notebook mit Windows 8 und dazu noch Android Phones/Tablets.
Kürzlich habe ich mir einen HP Microserver als NAS-Ersatz zugelegt, damit mein Desktop-Rechner nicht immer laufen muss und nciht immer ein paar Services wegfallen, wenn ich mal wieder daran rum bastel ;-)
Auf dem Fileserver läuft neben einem NFS-Server (eigentlich für die Linux-Clients gedacht) auch ein Samba-Server für die Windows-Clients. Dort liegen natürlich zentral die Daten ab und unter anderem auch Installationsdateien auf einem Install-Share.

Problem:
Wenn ich auf meinem Desktop-Rechner nun Dateien (z. B. Setup-Files) runterlade und auf dem Install-Share speichere, dann sind diese auf den Windows-Clients nicht ausführbar und es kommt eine nicht ganz korrekte Windows-Fehlermeldung:

Zitat

"Auf das angegebene Gerät, bzw. den Pfad kann nicht zugegriffen werden."
Dies stimmt so nicht ganz, denn wenn ich diese Dateien auf ein lokales Laufwerk kopiere, dann klappt das Kopieren und anschließend kann ich sie auch ausführen. Der Grund dafür ist, dass die Dateien beim Speichern mit dem Linux-Desktop die Rechte 644 bekommen. Anfangs dachte ich nach den ersten Recherchen es läge am NFS und habe den Share per CIFS gemountet, aber auch da habe ich dasselbe Problem!
Ich habe es dann mit versch. Mountoptionen versucht (file_mode, dir_mode, nounix, usw.), aber geändert hat sich an dem Verhalten nichts.

Der Abschnitt in Samba sieht so aus und wnn ich die Dateien mit einem Windows-Client spreichere, dann sehend ie Berechtigungen etwas besser aus, aber auch nicht ganz wie erwartet - nämlich 764:

Zitat


[Install]
comment = Install-Verzeichnis auf BOOTUX
path = /data/install
valid users = @stiefel
write list = @stiefel
force group = stiefel
create mask = 0775
directory mask = 0775
guest ok = Yes
locking = No
Hat irgendjemand eine Idee wo hier das Problem liegen könnte? Ich bin aktuell irgendwie ratlos.

Vielen Dank im Voraus!

Viele Grüße
Tom
Wenn die Klügeren immer nachgeben, geschieht immer das was die Dummen wollen! 8)
Wollen wir das wirklich ???


wowi

Ubuntu-Forum-Team

  • »wowi« ist männlich

Beiträge: 4 092

Registrierungsdatum: 03.05.2007

Derivat: Xubuntu

Architektur: 64-Bit PC

Desktop: XFCE

  • Nachricht senden

2

10.08.2014, 20:03

Hi Tronic69,

wenn ich mich nicht täusche, ist das kein Problem irgendwelcher Filerechte, sondern auf Neuerungen bei Windows zurückzuführen. Den Effekt kenne ich auch, der tritt aber bei mir erst seit irgendeinem Update von WIN7 auf. Ich denke, da hat Microsoft wieder einmal irgendwelche Rechte selbst verschärft, und läßt Installationen eben nur noch lokal, oder von "als sicher" deklarierten Laufwerken zu.

Greetz
wowi

  • »Tronic69« ist männlich
  • »Tronic69« ist der Autor dieses Themas

Beiträge: 264

Registrierungsdatum: 01.09.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

Andere Betriebssysteme: neben Ubuntu beruflich Solaris sowie (leider) auch SLES 9-11

  • Nachricht senden

3

10.08.2014, 20:28

Hi wowi,

mit Windows hat es ausnahmsweise nichts zu tun ^^

Wenn ich ein "chmod u+x" mache, dann läuft die Installation unter Windows auch vom Share problemlos.
Es hat wohl eher was mit Samba 4 zu tun, denn als der Fileserver noch mit Samba 3 auf dem Desktop unter Mint 13 lief hatte ich das Problem noch nicht - wobei ich damals ja auch in einem lokalen Filesystem speicherte und nicht auf einem Share.

Gruß Tom
Wenn die Klügeren immer nachgeben, geschieht immer das was die Dummen wollen! 8)
Wollen wir das wirklich ???


wowi

Ubuntu-Forum-Team

  • »wowi« ist männlich

Beiträge: 4 092

Registrierungsdatum: 03.05.2007

Derivat: Xubuntu

Architektur: 64-Bit PC

Desktop: XFCE

  • Nachricht senden

4

10.08.2014, 20:38

Hi Tronic69,

Wenn ich ein "chmod u+x" mache, dann läuft die Installation unter Windows auch vom Share problemlos.
Dass es dann doch fuktioniert, das konnte man (oder nur ich :rolleyes: ) aus dem ersten Post aber nicht rauslesen.

Greetz
wowi

5

10.08.2014, 20:48

Rechner/VMs mit Windows 7 Prof./Ultimate, ein Notebook mit Windows 8
Haben die alle das gleiche Problem?

wenn ich diese Dateien auf ein lokales Laufwerk kopiere
Also wenn Du sie von Windows per SMB von der Freigabe auf eine Platte des Windows-Rechners ziehst, richtig so?

mit Samba 3 auf dem Desktop unter Mint 13 lief hatte ich das Problem noch nicht - wobei ich damals ja auch in einem lokalen Filesystem speicherte und nicht auf einem Share.
Dann ist das aber keine vergleichbare Situation, aus der man jetzt Schlüsse ziehen kann.
mir is wurscht

  • »Tronic69« ist männlich
  • »Tronic69« ist der Autor dieses Themas

Beiträge: 264

Registrierungsdatum: 01.09.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

Andere Betriebssysteme: neben Ubuntu beruflich Solaris sowie (leider) auch SLES 9-11

  • Nachricht senden

6

11.08.2014, 14:03

Rechner/VMs mit Windows 7 Prof./Ultimate, ein Notebook mit Windows 8
Haben die alle das gleiche Problem?
Ja, die haben alle das gleiche Problem und das ist auch richtig so. Das Problem hätte man auch, wenn der Share auf einem Windows-Fileserver liegen und die die Dateien keine Rechte zum Ausführen hätten!
Das ist hier genau das gleiche Thema wie unter Linux mit Scripte: fehlt das x, dann ist das Script bzw. Programm nicht ausführbar - was sich in beiden Fällen mit einem chmod +x erledigen lässt.
Den Unterschied sieht man auch im Anhang.
wenn ich diese Dateien auf ein lokales Laufwerk kopiere
Also wenn Du sie von Windows per SMB von der Freigabe auf eine Platte des Windows-Rechners ziehst, richtig so?
Genau, damit wollte ich auch nur noch einmal unterstreichen, dass der Zugriff auf die Dateien grundsätzlich möglich ist, aber zum Kopieren braucht man ja auch nur Leserechte (mind. "r--"). Zum Ausführen hingegen wird auch das entsprechende Recht benötigt - also mind. "r-x".

mit Samba 3 auf dem Desktop unter Mint 13 lief hatte ich das Problem noch nicht - wobei ich damals ja auch in einem lokalen Filesystem speicherte und nicht auf einem Share.
Dann ist das aber keine vergleichbare Situation, aus der man jetzt Schlüsse ziehen kann.
Das mag ja sein, aber es ist mir noch eingefallen. Die entscheidende Frage für mich ist hier eigentlich warum die Dateien mit unterschiedlichen Rechten angelegt werden, wenn ich diese über den Samba-Share speicher. Tue ich dies auf einem Windows-System (java_win7.exe), dann bekommt die Datei die Rechte "rwxrw-r--", und wenn ich dies auf dem Linux-Client auf dem CIFS-Mount tue, dann bekommt die (java_client.exe) Datei die Rechte "rw-r--r--" - genauso wie auf dem Server direkt ohne Share (java_server.exe).


Zitat


tom @ bootux => /data/install/TEST
$ > dir
insgesamt 2,7M
drwxr-xr-x 2 tom stiefel 4,0K 2014-08-11 13:42 .
drwxrwxr-x 30 tom stiefel 4,0K 2014-08-11 13:35 ..
-rw-r--r-- 1 tom stiefel 897K 2014-07-28 07:15 java_client.exe
-rw-r--r-- 1 tom stiefel 897K 2014-07-28 07:15 java_server.exe
-rwxrw-r-- 1 tom stiefel 897K 2014-08-11 13:42 java_win7.exe
Somit kommt für mich das Problem also nur auf den Linux-Systemen zustande und hat vermutlich was damit zu tun, dass dort neu erstellte Dateien grundsätzlich das x-Recht entzogen bekommen. Daher klappt das auch nicht mit NFS, aber warum verhält sich der CIFS-Mount hier anders als der Samba-Mount unter Windows?

Danke und Gruß
Tom
»Tronic69« hat folgendes Bild angehängt:
  • Share-Rechte.png
Wenn die Klügeren immer nachgeben, geschieht immer das was die Dummen wollen! 8)
Wollen wir das wirklich ???


7

11.08.2014, 15:06

Hi Tom,

Da ich weiß, daß Du in diesen Dingen nicht unbewandert bist, nehme ich an daß Du momentan nur den Wald vor Bäumen nicht siehst. Deshalb gebe ich Dir einen Schubs:
Die Linux-Rechte haben mit den SMB/CIFS-Rechten nur bedingt zu tun. Auf keinen Fall kann Samba einer Datei mehr Rechte auf den CIFS-Weg mitgeben als sie vom Linux-Filesystem mitbringt. Selbst wenn du mit "createmask 0775" abspeichern lässt, das Filesystem aber die umask 022 gesetzt hat, fallen also die Schreib-Bits für Group und Others beim Speichern schonmal weg. Exec-Bits für Linux waren bei den Dateien sowieso nicht gesetzt (wozu auch), daher bleiben genau die Bits übrig die Du am File-Listing siehst. Aber das ist nicht das Problem am anderen Ende.

Sondern eher das: Was Windows als ausführbar erkennt (Extension) ist was anders als unter Linux (Bitmaske). Daher ist es weniger wichtig, welche Bits am Linux-Filesystem gesetzt sind, sondern eher welche CIFS-Rechte an den Client übertragen werden. Aber das wichtigste: Windows entscheidet selbst, was es als ausführbar zulässt selbst wenn es ausführbar ist. Und da ist imho der Punkt: Wenn der Windows-Client eine Datei die er bereits als ausführbar eingestuft hat, am Server speichert, wird er sie auch beim Import wieder als ausführbar anerkennen. Für den Linux-Rechner sind die alle nicht ausführbar, also wird er auch nicht das exec-Bit setzen.
Nur, wie gesagt, auch das wird sich nicht darauf auswirken, ob Windows sie tatsächlich ausführt. Das steht dann eher in den von Dir gezeigten Dialogen unter "erweiterte (spezielle) Berechtigungen". Dort sind nämlich jene für lokale ("interaktive"), also NTFS- Berechtigungen und "remote", also CIFS getrennt zu setzen. Dort würde ich für den gesamten importierten Ordner entsprechende Rechte setzen und auf die Inhalte vererben lassen. Dann sollte das klappen.

Wieso es nach dem Umkopieren plötzlich doch ausführbar ist, ist damit auch klar: Die .exe wird dadurch zu einer lokalen Datei, für die die einfachen NTFS-Rechte gelten.
mir is wurscht

  • »Tronic69« ist männlich
  • »Tronic69« ist der Autor dieses Themas

Beiträge: 264

Registrierungsdatum: 01.09.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

Andere Betriebssysteme: neben Ubuntu beruflich Solaris sowie (leider) auch SLES 9-11

  • Nachricht senden

8

12.08.2014, 01:18

Hi Fredl,

teils hast Du recht und teils auch nicht. Ich habe nun mal etwas recherchiert und mich nochmal ein wenig in die Themen "file creation" und "umask und Samba" eingelesen.
Ja, es ist richtig, dass die maximalen Rechte für eine Datei 666 sind und daher unter Linux immer diese Rechte als maximum abzüglich der umask vergeben werden.
Es ist nicht ganz richtig, dass Samba nicht mehr Rechte vergeben kann. Wenn ein Windows-System auf einem Samba-Share eine Datei speichert wird immer auch das Archiv-Bit gesetzt - was noch aus DOS-Zeiten stammt und an der Default-Einstellung "map archive = yes" hängt.
Da DOS mit FAT und später Windows mit NTFS andere Wegen bei der Vergabe von Berechtigungen gehen muss Samba hier andere Wege gehen. Also wird das unter Linux für Dateien per Default nicht benutze Execte-Bit als Archiv-Bit missbraucht und dadurch erhalten alle von Windows auf einem Samba-Share die Rechte 7?? - sofern ich das durch die "create mask" nicht auf weniger einschränke.

Von Windows aus kann ich auch Dateien mit den Rechten 774 erstellen, wenn ich in der smb.conf folgendes setze:

force create mode = 0775
map system = yes

Grund dafür ist, dass das x-Bit der Gruppe als System-Bit für DOS missbraucht wird und wenn man nun auch noch "map hidden = yes" (für das x-Bit von Others) einstellt, dann wäre sogar "force create mode = 0777" möglich!

Quelle: Samba-Doku


Es wäre vor allem für Admins fatal, wenn Windows wirklich anhand des Datei-Types alleine entscheiden könnte/dürfte was ausführbar ist. Ich kann sehr wohl über echt NTFS-Rechte einstellen was ein User in einem Verzeichnis darf oder eben nicht und ohne das Recht "Ausführen" kann er auch eine EXE nicht ausführen.
Wenn ich eine Datei unter Windows auf einen Samba runterlade und dieser nicht über die "create mask" auf max. 666 eingeschränkt ist, dann kann ich diese Datei auch ausführen - sofern sie Windows aus ausführbare Datei erkennt, weil sie eben einem Programm zugeordnet ist. Denn ansonsten fragt mich Windows womit ich die Datei denn ausführen möchte.
Um den Kreis wieder zu schließen: Entziehe ich der Datei nun das Ausführen-Recht (auf Linux-Ebene mit "chmod -x" oder unter Windows den Haken bei Ausführen entfernen), dann kann ich diese auch nicht mehr ausführen, selbst wenn es eine EXE ist.

Wieso es nach dem Umkopieren plötzlich doch ausführbar ist, ist damit auch klar: Die .exe wird dadurch zu einer lokalen Datei, für die die einfachen NTFS-Rechte gelten.

Das stimmt so nicht. Durch das kopieren der Datei in ein lokales Verzeichnis erbt diese die Rechte des übergeordneten Verzeichnisses und hier ist bei Windows in der Regel ausführen erlaubt.
Das hat genauso wenig mit einfachen lokalen Rechten zu tun wie es oben was mit speziellen CIFS- bzw. Remote-Rechten zu tun hat.


Was ich wollte geht nun zwar immer noch nicht und wird es ohne einen Workaround auch nie tun, aber ich habe wieder so einiges dazu gelernt.


PS:
Fredl, es war schön mal wieder von dir zu lesen und du zeigst immer noch den gleichen Einsatz wie vor Jahren. Wenn man hier so ab und zu mal was liest, könnte man meinen Du schmeißt gefühlt das halbe Forum hier ;)

================================================
Update
Mein Workaround fürs erste über die Crontab:
find /data/install -type f -iname "*.exe" -exec chmod 755 {} \; -o -iname "*.msi" -exec chmod 755 {} \;
Wenn die Klügeren immer nachgeben, geschieht immer das was die Dummen wollen! 8)
Wollen wir das wirklich ???

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Tronic69« (12.08.2014, 01:37)


9

12.08.2014, 10:01

Hi,

Meine Ausführungen waren zugegebenermaßen etwas vereinfacht und auf die Grundlagen gestutzt. Im Sinne der Lesbarkeit und weil ich wusste, daß Du dich ohnehin genauer einlesen würdest. :)

Zum Recht des Ausführens:
ohne das Recht "Ausführen" kann er auch eine EXE nicht ausführen
Der alte Grundsatz, daß Windows .exe, .com und .bat automatisch ausführt wurde erst durch die Möglichkeiten von NTFS halbwegs vernünftig gelöst. Ich wollte nur zeigen, daß die Entscheidung über die Ausführbarkeit von den beiden OS traditionell völlig unterschiedlich gehandhabt wird.
Das mit dem exec-Bit als Ersatz für das Archiv-Bit war mir übrigens nicht (mehr) geläufig, danke für den Hinweis. Aber gerade wegen dieser Erklärung meine ich trotzdem noch, daß das Setzen des Bits auf Linux-Seite nicht direkt den gewünschten Effekt bringen kann. Es sei denn, ich schätze die Wirkung von "archive" auf Windows-Seite falsch ein.

Durch das kopieren der Datei in ein lokales Verzeichnis erbt diese die Rechte des übergeordneten Verzeichnisses und hier ist bei Windows in der Regel ausführen erlaubt.
Ja, darauf wollte ich ja hinaus. In den erweiterten Einstellungen auf Windows-Seite kann man die Rechte für remote und lokal getrennt steuern. Hier wäre imho der Ansatz für Deine Lösung. Nämlich für den gesamten importierten Ordner das Ausführen bestimmter Dateien (jenen wo das Sinn macht, auch das kann man in noch tiefer liegenden Einstellungen beeinflussen) zu erlauben, selbst wenn sie ohne dieses Recht gespeichert wurden (beim Download von Linux aus).

Wenn Du meinst, daß es von Linux-Seite aus lösbar sein sollte dann schau Dir noch einmal die Themen umask und sticky-bit an. Wenn es wirklich auf das exec-Bit ankommen sollte, wäre letzteres Dein workaround. Ich wäre interessiert, ob das wirklich schon eine Lösung wäre.

P.S.: http://www.windowspro.de/wolfgang-sommer…ows-kombinieren
mir is wurscht

  • »Tronic69« ist männlich
  • »Tronic69« ist der Autor dieses Themas

Beiträge: 264

Registrierungsdatum: 01.09.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

Andere Betriebssysteme: neben Ubuntu beruflich Solaris sowie (leider) auch SLES 9-11

  • Nachricht senden

10

12.08.2014, 14:23

Hi,

erstmal danke für de Link. Sehr interessant und so habe ich auch mal wieder was von OS/2 gehört ;)
Das mit dem exec-Bit als Ersatz für das Archiv-Bit war mir übrigens nicht (mehr) geläufig, danke für den Hinweis. Aber gerade wegen dieser Erklärung meine ich trotzdem noch, daß das Setzen des Bits auf Linux-Seite nicht direkt den gewünschten Effekt bringen kann. Es sei denn, ich schätze die Wirkung von "archive" auf Windows-Seite falsch ein.
Nun ja, wenn man den ganzen Erklärungen (auch in dem Link) und Dokumentationen folgt, dann hast Du recht und das Setzen des x-Bits sollte keinen Einfluss an der Ausführbarkeit einer Datei auf dem Share unter Windows haben. Zumindest in meinem Fall tut es das aber definitiv. Denn wenn ich unter Linux das x-Bit entferne kann ich die Datei unter Windows nicht mehr ausführen und wenn ich es wieder setze ist die Datei auch wieder ausführbar. Dieses Spielchen kann ich so oft hin und her durchführen wie ich möchte, ohne dass sich irgendwas ändert.
Sehr dubios das Ganze, aber ich vermute da hat eben Samba doch noch irgendwie sein Finger dazwischen!
In den erweiterten Einstellungen auf Windows-Seite kann man die Rechte für remote und lokal getrennt steuern. Hier wäre imho der Ansatz für Deine Lösung. Nämlich für den gesamten importierten Ordner das Ausführen bestimmter Dateien (jenen wo das Sinn macht, auch das kann man in noch tiefer liegenden Einstellungen beeinflussen) zu erlauben, selbst wenn sie ohne dieses Recht gespeichert wurden (beim Download von Linux aus).
Jetzt habe ich wohl endlich verstanden was Du mit "Rechte für remote und lokal" meinst. Das nennt sich IMHO etwas anders. Es gibt einmal die (lokalen) NTFS-Berechtigungen, die relativ granular einstellbar sind, und dann die Share- bzw. Freigabe-Berechtigung, die nur Lesen, Ändern und Vollzugriff kennen.
Diese Share-Berechtigungen gelten erst einmal nur für den Share an sich und es bringt dem User nichts, wenn er auf dem Share Vollzugriff, aber letztlich unten drunter keine NTFS-Rechte hat. Zumindest ist das bei Windows-Freigaben so, denn hier muss ich die Rechte zweimal vergeben: einmal für den Share und einmal die NTFS-Rechte.
Vielleicht ist das hier bei dem Samba-Share ähnlich. Das würde zumindest annähernd erklären warum das Ausführen unter Windows erst klappt, wenn das x-Bit gesetzt ist.

Wenn Du meinst, daß es von Linux-Seite aus lösbar sein sollte dann schau Dir noch einmal die Themen umask und sticky-bit an. Wenn es wirklich auf das exec-Bit ankommen sollte, wäre letzteres Dein workaround. Ich wäre interessiert, ob das wirklich schon eine Lösung wäre.
Da ich das Problem ja nur habe, wenn ich auf einem Linux-System eine Datei auf dem Share neu ablege, ist eine Lösung bzw. ein Workaround nach aktuellem Stand auch nur dort machbar. Vielleicht meldet sich ja noch jemand anderes zu Wort, der hier eine andere Lösung sieht.
Wenn die Klügeren immer nachgeben, geschieht immer das was die Dummen wollen! 8)
Wollen wir das wirklich ???


11

12.08.2014, 15:35

was Du mit "Rechte für remote und lokal" meinst. Das nennt sich IMHO etwas anders.
Sagte ich weiter oben schon: "interaktiv" und afair "Netzwerk" oder so.

es bringt dem User nichts, wenn er auf dem Share Vollzugriff, aber letztlich unten drunter keine NTFS-Rechte hat
Siehe auch der verlinkte Artikel. Wenn schon dann Vollzugriff auf Netzwerk-Ebene und anschließende Einschränkungen lokal (NTFS).

Da ich das Problem ja nur habe, wenn ich auf einem Linux-System eine Datei auf dem Share neu ablege, ist eine Lösung bzw. ein Workaround nach aktuellem Stand auch nur dort machbar.
Deshalb das Stichwort "Sticky-Bit". Vielleicht kann es jemand anderer wiederholen. ;)
mir is wurscht

  • »Tronic69« ist männlich
  • »Tronic69« ist der Autor dieses Themas

Beiträge: 264

Registrierungsdatum: 01.09.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

Andere Betriebssysteme: neben Ubuntu beruflich Solaris sowie (leider) auch SLES 9-11

  • Nachricht senden

12

12.08.2014, 19:45

Deshalb das Stichwort "Sticky-Bit". Vielleicht kann es jemand anderer wiederholen.
Vielleicht stehe ich ja irgendwo auf der Leitung, aber ich verstehe immer noch nicht was das Sticky-Bit damit zu tun haben bzw. an dem Verhalten ändern sollte ???
Vielleicht kannst Du mich mal runter schubsen ;)
Wenn die Klügeren immer nachgeben, geschieht immer das was die Dummen wollen! 8)
Wollen wir das wirklich ???


13

12.08.2014, 22:31

Vielleicht kannst Du mich mal runter schubsen

Nicht nötig, hier stehst Du richtig. :)
In dem Fall hilft das wirklich nichts, weil es sich auf die Datei-Flags in dem Ordner nicht auswirkt. Ich habe mich daran festgefahren, weil ich auf diese Weise die Gruppeneigentümerschaft innerhalb eines solchen Ordners vererbe. So ist es egal wer die Dateien dort abgelegt hat, jedes Gruppenmitglied kann sie lesen. Mit dem exec-Bit bringt Dich das leider nicht weiter, da hast Du Recht.

Da Du vorhin bereits über "map archive" und "map hidden" gestolpert bist, könntest Du aber einmal die Option "map system" antesten. Sie sollte eigentlich DOS-executables über das group-exec-Bit markieren (user-exec ist ja schon von "archive" belegt). Ob *.msi da auch darunter fallen müsste man sehen.

Allerdings kann ich trotz ausführlicher Tests das Problem nur bedingt nachvollziehen. Bei mir hat ein solches Verzeichnis den create mode 0740 und wenn ich eine als rwxr-xr-x markierte .exe dort ablege, bleibt ihr zumindest rwxr----- erhalten, was ja zu der Maske passt. Wieso bei Dir das x völlig verschwindet, komme ich nicht drauf. Könnte es etwas mit dem Download an sich zu tun haben? Holst Du da fertige .exe oder Archive mit eingepackten .exe? Zumindest damit sollten vorher vorhandene Attribute wieder restauriert werden.

Oder es ist tatsächlich ein neues Feature von Samba4...
mir is wurscht

14

13.08.2014, 10:52

Übrigens alles Gute zum Geburtstag! :)
mir is wurscht

  • »Tronic69« ist männlich
  • »Tronic69« ist der Autor dieses Themas

Beiträge: 264

Registrierungsdatum: 01.09.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

Andere Betriebssysteme: neben Ubuntu beruflich Solaris sowie (leider) auch SLES 9-11

  • Nachricht senden

15

13.08.2014, 17:24

Übrigens alles Gute zum Geburtstag! :)
Vielen Dank auch!

Wegen dem eigentlichen Thema werde ich mich noch einmal melden, aber jetzt wird erst einmal gefeiert und nachher gibt es hoffentlich noch das gelb-schwarze Geschenk 8)
Wenn die Klügeren immer nachgeben, geschieht immer das was die Dummen wollen! 8)
Wollen wir das wirklich ???


Beiträge: 1

Registrierungsdatum: 03.07.2015

Derivat: unbekannt

Architektur: unbekannt

Desktop: unbekannt

  • Nachricht senden

16

03.07.2015, 08:31

Folgende Lösung half bei mir:
Gefunden bei https://forge.univention.org/bugzilla/show_bug.cgi?id=33785

=> In der [Global] Sektion der smb.conf folgende Zeile eintragen:

acl allow execute always = True

Nachtrag: Hier ist das ganze auch bei Samba.org beschrieben:
https://wiki.samba.org/index.php/Setup_a…with_POSIX_ACLs

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »temp_devil« (03.07.2015, 10:39)