Windows 7 VM, OS X, SMB, Access denied voor EXE.

[mister X630]

Ik heb hier een VM met Windows 7 x64 draaien op VmWare fusion, draaiend op OS X 10.8.2. Vanuit deze Windows 7 VM connect ik naar een share van de OS X host zelf.

Dit werkt in principe allemaal uitstekend, full access. Lezen / schrijven, copy, move, alles.
1 ding werkt alleen niet. Ik krijg het het starten van veel executables (.EXE) vanaf de share (network-mapping) een access denied melding en ik krijg dit niet verholpen.

De exacte melding:
Windows cannot access the specified device, path, or file. you may not have the appropriate permissions to access the item.

Wat heb ik al geprobeerd:
* UNC path i.p.v. network-mapping
* virusscanners uit op zowel host als VM
* host toegevoegd aan "Local intranet zone" van IE
* User Account Control (UAC) uitgeschakeld
* Gisteren een nieuwe kale VM geinstalleerd met Windows 7 x64 SP1 als. Maar ook dan heb ik hetzelfde probleem met geen enkel geinstalleerd programma / driver.
* ook een XP VM geinstalleerd, en daar ook hetzelfde probleem!

Als ik de .EXE van de share eerst naar de VM kopieer werken die ook gewoon prima. Internet staat ook vol met dit probleem. Maar daar is de oplossing vaak UAC uitschakelen of het unc path toevoegen aan "local intranet zone" van IE, maar helaas is dit bij mij niet het geval.

Kent iemand dit probleem en weet hij/zij er een oplossing voor?

[Mental]

Moet je inloggen op de unc share of heb je gewoon toegang?
Klinkt heel erg als dat je admin token geen toegang heeft tot die share.
Als je die verbinding opzet en je moet een wachtwoord ingeven dan is die verbinding alleen beschikbaar binnen je user token; schakel je dan over (lees: krijg je een UAC prompt om te elevaten) dan is die verbinding er simpelweg niet.
Wat je kunt doen is de verbinding ook onder je admin account opzetten (vanuit een commandprompt bijv.) of de toegang zodanig regelen dat je niet hoeft in te loggen op die share.

[CMD-Snake]

Klinkt alsof je geen execute permissies hebt op de share.

Binnen Windows kan je op een share ook filteren of er dingen uitgevoerd mogen worden. Je zal dan even moeten kijken op de host hoe je alsnog execute toestemming kan verlenen.

[mister X630]

Mental schreef op woensdag 03 oktober 2012 @ 10:03:
Moet je inloggen op de unc share of heb je gewoon toegang?
Klinkt heel erg als dat je admin token geen toegang heeft tot die share.
Als je die verbinding opzet en je moet een wachtwoord ingeven dan is die verbinding alleen beschikbaar binnen je user token; schakel je dan over (lees: krijg je een UAC prompt om te elevaten) dan is die verbinding er simpelweg niet.
Wat je kunt doen is de verbinding ook onder je admin account opzetten (vanuit een commandprompt bijv.) of de toegang zodanig regelen dat je niet hoeft in te loggen op die share.

Dank voor de snelle reactie!

Nee, ik hoef niet in te loggen, direct volledig toegang. Username/password op OS X en de VM zijn gelijk, dus die matched hij direct.

Schiet me gelijk nog een optie te binnen, ik zal het password op de VM eens aanpassen zodat ik bij het mappen van de drive WEL een user/pass combi op moet geven.

[edit1]
Zojuist dus gedaan, password aangepast, bij het mappen van de drive inderdaad wel netjes een user/pass prompt. Drive wordt prima gemapped, maar helaas blijft het probleem hetzelfde.

Ik zal nu eens mappen/runnen vanuit een elevated command prompt.
[/edit1]

[ Voor 20% gewijzigd door mister X630 op 03-10-2012 10:33 ]

[Mental]

start eens een elevated (run as admin) commandprompt en kijk of je dan wel de exe kan starten?
Als dat wel werkt gaat het een leuk zoekplaatje worden

[mister X630]

Zojuist vanuit een elevated cmd:
net use y: \\<IP>\<share> /username:<username>

Vraagt dan netjes om het password. Mapping wordt gemaakt, maar bij het starten van de .EXE komt alleen "access denied" terug. zo vaag!

[edit1]
Nogmaals even voor de duidelijkheid, dit is dus niet het geval bij alle .EXE files. Als ik bijvoorbeeld een winrarsetup.exe (winrar setup), vsewin.exe (mcafee vshield install), of Filezilla.exe (FTP) start vanaf dezelfde share dan doet hij dat prima.

mysqldump.exe (onderdeel van een mysql installatie) heeft wel weer hetzelfde probleem bijvoorbeeld. "Access denied"

De programma's waardoor ik tegen dit probleem aanliep zijn eigen executables gegenereerd door Delphi. Deze doen het allemaal niet.

Het lijkt wel of hij de afkomst van de .EXE's niet vertrouwt ofzo.
[/edit1]

[ Voor 65% gewijzigd door mister X630 op 03-10-2012 14:15 ]

[Mental]

Gek, virusscanner uitgeschakeld?
Gekeken of toevallig bij de properties van die exe file hij geblokkeerd is omdat hij vanaf internet afkomstig is? (zo'n heerlijk vaag vinkje).
Meer kan ik me ook niet bedenken, wat je eventueel kan doen is het opstarten van zo'n executable monitoren met iets als procmon.exe (http://live.sysinternals.com/procmon.exe) en kijken wát er precies denied wordt.

[mister X630]

Mental schreef op donderdag 04 oktober 2012 @ 13:10:
Gek, virusscanner uitgeschakeld?
Gekeken of toevallig bij de properties van die exe file hij geblokkeerd is omdat hij vanaf internet afkomstig is? (zo'n heerlijk vaag vinkje).
Meer kan ik me ook niet bedenken, wat je eventueel kan doen is het opstarten van zo'n executable monitoren met iets als procmon.exe (http://live.sysinternals.com/procmon.exe) en kijken wát er precies denied wordt.

Zelfs op een nieuw geinstalleerde VM met windows 7 blijft het probleem. (dus zonder virusscanner)

Ik zal eens kijken met ProcMon wat er mis gaat, als hij zover komt dan...

[edit1]
helaas, zover komt hij niet eens, de executable wordt al gedenied voordat hij uberhaupt start.
En nee, dat irritante "blocked" vinkje is het ook niet trouwens, daar had ik al naar gekeken inderdaad.
[/edit1]

[ Voor 14% gewijzigd door mister X630 op 05-10-2012 12:02 ]

[mister X630]

Iemand nog een suggestie misschien?

[Mental]

Met procmon blijven monitoren en filteren op PATH contains 'executablenaam', explorer.exe is namelijk de boosdoener dat de executable niet start en niet de executable zelf.