Asadmin deploy fails for server instance running on restricted service account on Windows

Windows is an ongoing source of security leaks, so it makes much sense to run Payara server instances using a restricted user account instead of the default “LocalSystem”.

When logging in to such a host as administrator, then running asadmin deploy will fail. The reason is that asadmin apparently just asks the running service to access the EAR file sitting elsewhere. Even worse, granting full access to the EAR file to the restricted service does not solve this, as apparently Payara does not directly access the full path. So only when providing access to ALL super-directories, too, Payara can access it. So typically, it is easier to copy the EAR to c:\payara5 or another top-level folder to make provision of all the needed super-folder-grants easier.

For me, this simply looks like a conceptual bug of asadmin. Even when running on the same machine, certainly the asadmin service MUST NOT try to access the file in its original location, but instead the asadmin command MUST transfer the file using inter-process-communication instead, OR asadmin in that case must simply put the file in the autodeploy folder.

Any opinions?


Have you tried running asadmin with --upload=true? That should force uploading the package via HTTP instead of just sending the server a path to the local filesystem. Asadmin automatically detects whether the server runs on localhost, and in that case it doesn’t upload the file. If the server is remote, only then it automatically switches to upload mode and send the whole application over HTTP.


So finally we found the time to try out --upload=true… Hence I hereby do confirm that --upload=true perfectly solves this use case! :slight_smile: