Windows services VS CLI en rechten

[Standeman]

Ik heb een vreemd probleem waar ik maar niet uitkomt en misschien dat iemand hier een idee hebt waar dit door komt.

Op een windows 2008 64 bit machine heb ik een Tomcat (Java WebApp server) instantie draaien die contact moet leggen met een access database over een netwerk share (via een ODBC System DSN). Wanneer ik tomcat via de CLI opstart werkt alles helemaal prima, maar het is de bedoeling dat Tomcat als een service gaat draaien. Nu is dat laatste niet zo moeilijk, dus een als een service geinstalleerd en klaar zou je denken.

Het probleem ontstaat wanneer de webapp contact wil leggen met de access database op die share. Op dat moment krijg ik een foutmelding dat er geen info weggeschreven kan worden?

[Microsoft][ODBC Microsoft Access Driver] '(unknown)' is not a valid path. Make
sure that the path name is spelled correctly and that you are connected to the
server on which the file resides.

In eerste instantie dacht ik dat de locale system account geen voldoende rechten zou hebben, dus gebruik ik de user waarmee ik normaal gesproken ingelogd ben (hell, via de CLI werkt het prima), maar ook dan krijg ik dezelfde foutmelding.

Nu zit ik me af te vragen wat nou het verschil kan zijn tussen een app opstarten via de CLI of als een windows service qua rechten op een share ook al gebruik je dezelfde user


* Saillant detail: ik gebruik 32-bit java / tomcat / odbc, 64-bit gaf nog veel meer problemen
* Ja, ik weet dat jdbc-odbc koppelingen een enorm brak zijn, maar dat is iets met roeien en riemen

[alt-92]

Als je dat ding met de hand via commandline start worden jouw credentials via passthrough doorgegeven en logt niet de network service maar jouw account in.
heb je al eens in je eventlogs gekeken welke aanmelding er uberhaupt op die remote doos (waar de DB staat) langskomt?

sowieso... access DB's over een netwerkshare benaderen... *brrrrr*

[Standeman]

alt-92 schreef op woensdag 09 mei 2012 @ 20:53:
Als je dat ding met de hand via commandline start worden jouw credentials via passthrough doorgegeven en logt niet de network service maar jouw account in.

Ook als ik bij de service expliciet aangeef met welke user deze moet runnen (c.q. 'logon as')?

heb je al eens in je eventlogs gekeken welke aanmelding er uberhaupt op die remote doos (waar de DB staat) langskomt?

Nee, nog niet gedaan, ga even kijken of ik daar de rechten voor heb... anders moet ik even de klant aan het werk zetten.

sowieso... access DB's over een netwerkshare benaderen... *brrrrr*

Het is sowieso een drama oplossing.

[Standeman]

Uiteindelijk om het probleem heen gewerkt... Blijkbaar kan je dus in de registry (HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\) het UNC path aangeven welke de System DSN odbc koppeling moet gebruiken en ga om het UI tooltje om. Dat betekend dat ik geen share meer nodig heb om de db te benaderen

Ik snap er alleen nog geen bal van waarom de service de share niet kon benaderen

[jvc2001]

Standeman schreef op dinsdag 08 mei 2012 @ 11:33:
In eerste instantie dacht ik dat de locale system account geen voldoende rechten zou hebben, dus gebruik ik de user waarmee ik normaal gesproken ingelogd ben (hell, via de CLI werkt het prima), maar ook dan krijg ik dezelfde foutmelding.

local system account moet je rechten geven op de share
http://serverfault.com/qu...ss-to-localsystem-account

als je het onder de named account opstart, heeft deze account zowel share als ntfs permissies?

UNC path of mapped drive?