Lieber Besucher, herzlich willkommen bei: Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.
Benutzerinformationen überspringen
User
Registrierungsdatum: 01.09.2005
Derivat: Ubuntu
Architektur: 64-Bit PC
Desktop: Unity
Andere Betriebssysteme: neben Ubuntu beruflich Solaris sowie (leider) auch SLES 9-11
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!Zitat
"Auf das angegebene Gerät, bzw. den Pfad kann nicht zugegriffen werden."
Hat irgendjemand eine Idee wo hier das Problem liegen könnte? Ich bin aktuell irgendwie ratlos.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
Benutzerinformationen überspringen
Ubuntu-Forum-Team
Registrierungsdatum: 03.05.2007
Derivat: Xubuntu
Architektur: 64-Bit PC
Desktop: XFCE
Benutzerinformationen überspringen
User
Registrierungsdatum: 01.09.2005
Derivat: Ubuntu
Architektur: 64-Bit PC
Desktop: Unity
Andere Betriebssysteme: neben Ubuntu beruflich Solaris sowie (leider) auch SLES 9-11
Benutzerinformationen überspringen
Ubuntu-Forum-Team
Registrierungsdatum: 03.05.2007
Derivat: Xubuntu
Architektur: 64-Bit PC
Desktop: XFCE
Dass es dann doch fuktioniert, das konnte man (oder nur ich ) aus dem ersten Post aber nicht rauslesen.Wenn ich ein "chmod u+x" mache, dann läuft die Installation unter Windows auch vom Share problemlos.
Haben die alle das gleiche Problem?Rechner/VMs mit Windows 7 Prof./Ultimate, ein Notebook mit Windows 8
Also wenn Du sie von Windows per SMB von der Freigabe auf eine Platte des Windows-Rechners ziehst, richtig so?wenn ich diese Dateien auf ein lokales Laufwerk kopiere
Dann ist das aber keine vergleichbare Situation, aus der man jetzt Schlüsse ziehen kann.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.
Benutzerinformationen überspringen
User
Registrierungsdatum: 01.09.2005
Derivat: Ubuntu
Architektur: 64-Bit PC
Desktop: Unity
Andere Betriebssysteme: neben Ubuntu beruflich Solaris sowie (leider) auch SLES 9-11
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!Haben die alle das gleiche Problem?Rechner/VMs mit Windows 7 Prof./Ultimate, ein Notebook mit Windows 8
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".Also wenn Du sie von Windows per SMB von der Freigabe auf eine Platte des Windows-Rechners ziehst, richtig so?wenn ich diese Dateien auf ein lokales Laufwerk kopiere
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).Dann ist das aber keine vergleichbare Situation, aus der man jetzt Schlüsse ziehen kann.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.
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?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
Benutzerinformationen überspringen
User
Registrierungsdatum: 01.09.2005
Derivat: Ubuntu
Architektur: 64-Bit PC
Desktop: Unity
Andere Betriebssysteme: neben Ubuntu beruflich Solaris sowie (leider) auch SLES 9-11
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Tronic69« (12.08.2014, 01:37)
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.ohne das Recht "Ausführen" kann er auch eine EXE nicht ausführen
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).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.
Benutzerinformationen überspringen
User
Registrierungsdatum: 01.09.2005
Derivat: Ubuntu
Architektur: 64-Bit PC
Desktop: Unity
Andere Betriebssysteme: neben Ubuntu beruflich Solaris sowie (leider) auch SLES 9-11
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.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.
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.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).
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 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.
Sagte ich weiter oben schon: "interaktiv" und afair "Netzwerk" oder so.was Du mit "Rechte für remote und lokal" meinst. Das nennt sich IMHO etwas anders.
Siehe auch der verlinkte Artikel. Wenn schon dann Vollzugriff auf Netzwerk-Ebene und anschließende Einschränkungen lokal (NTFS).es bringt dem User nichts, wenn er auf dem Share Vollzugriff, aber letztlich unten drunter keine NTFS-Rechte hat
Deshalb das Stichwort "Sticky-Bit". Vielleicht kann es jemand anderer wiederholen.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.
Benutzerinformationen überspringen
User
Registrierungsdatum: 01.09.2005
Derivat: Ubuntu
Architektur: 64-Bit PC
Desktop: Unity
Andere Betriebssysteme: neben Ubuntu beruflich Solaris sowie (leider) auch SLES 9-11
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 ???Deshalb das Stichwort "Sticky-Bit". Vielleicht kann es jemand anderer wiederholen.
Vielleicht kannst Du mich mal runter schubsen
Benutzerinformationen überspringen
User
Registrierungsdatum: 01.09.2005
Derivat: Ubuntu
Architektur: 64-Bit PC
Desktop: Unity
Andere Betriebssysteme: neben Ubuntu beruflich Solaris sowie (leider) auch SLES 9-11
Vielen Dank auch!Übrigens alles Gute zum Geburtstag!
Benutzerinformationen überspringen
User
Registrierungsdatum: 03.07.2015
Derivat: unbekannt
Architektur: unbekannt
Desktop: unbekannt
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »temp_devil« (03.07.2015, 10:39)
1 Besucher
Sponsorenwerbung: |
Hardware, Computer, PCs, Notebooks & Laptops mit Linux |
Forensoftware: Burning Board®, entwickelt von WoltLab® GmbH
Individuelle Notebooks Laptops - Individuelle Computer PCs - Linux Notebooks & Computers
Lastminute - Ubuntu Linux - Abmahnung - Geek und Nerd Shirt Shop
T-Shirts - sanierung wien