System script returned non-zero status 4

[rmw]

Ik dacht nog 'hoe moeilijk kan het zijn?'.

Had ik niet moeten doen

 

Het doel:

Tab gescheiden tekst documenten van een netwerk locatie naar de documenten map van de FMServer overzetten met een batch commando, om daarna de gegevens te kunnen verwerken middels een FM script.

 

Het middel:

Een FM Schedule waarin een system script en een FM script zijn gecombineerd.

 

Het resultaat:

"Schedule "UpdateData" aborted; system script "CopyData.cmd" returned non-zero status 4." als ik het bij het system script geen account opgeef en dus met de standaard privileges van FMServer werk.

OF

"Schedule "UpdateData" aborted; "CopyData.cmd" could not be found or is invalid." als ik een admin account opgeef bij het system script.

 

Ik weet dat het FMServer account een local system account is en dus waarschijnlijk geen netwerk rechten heeft, vandaar dat ik het script de admin privileges mee had gegeven.

Maar die mag blijkbaar niet de batch file uitvoeren of benaderen...

 

Voor de volledigheid de batch file CopyData.cmd bevat dit

@echo off
xcopy "\\\Public Website\Data\*.*" "C:\Program Files\FileMaker\FileMaker Server\Data\Documents\"

En het staat hier

C:\Program Files\FileMaker\FileMaker Server\Data\Scripts

 

En natuurlijk draait het allemaal naar behoren als ik het met de hand uitvoer...

 

Wat doe ik verkeerd.....

 

rmw

[Banach]

Ik denk dat dit soort dingen onder de user fmserver worden uitgevoerd. Grote kans dat die user de noodzakelijker rechten mist.

[rmw]

Ik denk dat dit soort dingen onder de user fmserver worden uitgevoerd. Grote kans dat die user de noodzakelijker rechten mist.

Dat klopt, daarom heb je bij het opgeven van het batch commando ook de mogelijkheid een ander account te kiezen.

Maar als ik dat doe krijg ik "Schedule "UpdateData" aborted; "CopyData.cmd" could not be found or is invalid.".

 

Het is ongetwijfeld een rechten kwestie, maar ik weet niet waar ik moet zoeken...

 

rmw

[SuperWimmie]

Hij bedoelt waarschijnlijk de user waaronder Filemaker Server als applicatie draait onder OS X (of Windows, zo je wilt).

Alle serverscripts zullen in de Server omgeving worden gedraaid, op de fysieke server als apparaat, onder de account waaronder Filemaker Server is geinstalleerd (vermoed ik).

 

Heeft niets te maken met de user in Filemaker.

En dus ook niet met de rechten op scripts, aangezien die puur voor intern Filemaker gebruik zijn bestemd.

[rmw]

Spraakverwarring?

Voor alle duidelijkheid, het draait allemaal op een windows machine.

 

Je hebt de filemaker accounts waarmee je filemaker bestanden opent en je hebt accounts van windows waarmee je windows taken kunt uitvoeren.

 

In dit geval heb ik ze beide nodig.

Het windows account voor het verplaatsen van de documenten en het filemaker account voor het uitvoeren van het script dat de bestanden inleest.

 

Het filemaker account is geen probleem, dat is een admin account met full access in de database. Dat geeft je op bij het kiezen van het filemaker script in het schedule.

 

Het probleem zit hem in het windows account.

Standaard draait FMServer op windows met een local system account (zie de afbeelding in mijn vorige post). Dat heeft bijna altijd GEEN netwerk rechten en geeft bij uitvoeren van de batch file dus ook de genoemde foutmelding: "Schedule "UpdateData" aborted; system script "CopyData.cmd" returned non-zero status 4."

Geef ik voor het uitvoeren van de batch file een ander windows account op (die mogelijkheid is ook zichtbaar in de afbeelding van mijn vorige post) dan volgt: "Schedule "UpdateData" aborted; "CopyData.cmd" could not be found or is invalid."

Het windows account wat ik daarvoor gebruik is het standaard admin account voor die machine. Dat is ook het account wat ik gebruik om de batch file handmatig uit te voeren. En dat geeft geen problemen.

De rechten van de batch file staan voor dat account op full control. En ook de map waarin de batch file staat heeft full control.

 

Dus waar zit het addertje onder het gras ????

 

 

rmw

[SuperWimmie]

een batch file genaamd .CMD?

 

Moet het niet .BAT zijn?

 

(Haha, dit weten die groenteboeren niet. Ramenwasser dan weer wel.)

[menno]

Ik heb even het eea getest en kom tot exact deselfde bevindingen. Ik denk daarom dat dit een regelrechte bug is en heb er op de website van fmi een bugmelding van gemaakt.

Mvg, Menno

[SuperWimmie]

Om nog even terug te komen... Wat gebeurt er als je van de file .BAT maakt?

 

Een .CMD bestand heeft ergens in Windows een programmaatje nodig om het als 32 bits bestandje te laten verwerken.

Is dat programmaatje onder een kaal account niet te bereiken (vanwege setting variabelen), dan voert hij een .CMD niet uit.

 

Een .BAT zit diep in de DOS ingebakken en zal altijd werken.

 

Daarnaast kan je een enkelvoudig DOS commando ook laten werken zonder een Batch file.

 

Send event:

cmd /c xcopy \"\\\\\Public Website\\Data\\*.*\" \"C:\\Program Files\\FileMaker\\FileMaker Server\\Data\\Documents\\\"

 

Wat gebeurt er dan?

[rmw]

Dank voor het meedenken, maar ik vermoed hier inderdaad een bug.

Wijzigen naar .bat maakt geen verschil, de foutmeldingen blijven dezelfde.

 

En helaas is Send event niet server side compatible....dus dat gaat hem ook niet worden.

 

rmw

[SuperWimmie]

Als Send Event niet server sided compatible is, waarmee vuur je dan het .CMD bestand af?

[rmw]

Je kan in een schedule op de server ook kiezen voor een script sequence.

Dan kan je voor en/of na het FM script een OS script uit laten voeren.

Op OSX zijn dat shell scripts, op Windows zijn dat cmd of bat bestanden of powershell scripts

 

Zo dus.

 

rmw