Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de

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

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

Zitat von »Fredl«

Zitat von »Tronic69«

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.

Zitat von »Fredl«

Zitat von »Tronic69«

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".

Zitat von »Fredl«

Zitat von »Tronic69«

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

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 {} \;

Hi,

erstmal danke für de Link. Sehr interessant und so habe ich auch mal wieder was von OS/2 gehört

Zitat von »Fredl«

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!

Zitat von »Fredl«

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.

Zitat von »Fredl«

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.

Zitat von »Fredl«

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

Zitat von »Fredl«

Ü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