I recently (well a couple of months ago) reinstalled Lucee with AdoptOpenJDK and upgraded to the latest RC for my dev machine.
Server 2019
Lucee 5.3.7.34-RC
Apache Tomcat/9.0.34
Java 11.0.6 (AdoptOpenJDK) 64bit
When testing a page I haven’t looked at in a while which uses cffile to handle files on a network share (and/or through a UNC path) I’m getting an error
Source file [\networkserver\xml\packageTest.xml] is not a file
My first thought was that I hadn’t set the Lucee service LogOn account to something with network credentials…and that was correct (it had been set up and working before the reinstall ie: while still running Oracle Java)
When I went to start Lucee after changing credentials, it refused to start. I’m using exactly the same domain creds as my production server (domain\CFService and also tried CFService@domain.local) which is running Lucee 5.3.6.61. For fun I even tried domain admin as the user…still won’t start.
My production server is running
Server 2012
Lucee 5.3.6.61
Apache Tomcat/8.5.11
Java 1.8.0_121 (Oracle Corporation) 64bit
I just built a test VM that uses
Server 2019
Lucee 5.3.6.61
Apache Tomcat/9.0.35
Java 11.0.7 (AdoptOpenJDK) 64bit
and I can’t start the service under a domain account on that either.
When I enter the DomainControllerName\CFService and click apply it seems to accept it. (the apply button is disabled) If I close and reopen the Service Control, The account shows Local Service Account is still the Logon and -not- the Log On As I had just set and apparently had accepted.
I think the successful start up in the previous post was under the Local account context, despite the Log On As being populated and apparently accepted.
Tried this in both the dev environment and the new VM. It will apparently not run under any context but Local Service. Or I’m an idiot (which is always on the table)
During installation the tomcat/lucee folders/files are set up with the file permissions to run the service with the user “local service”, which is a very low priviliged in-built windows account to run services in a safe manner. It is so low priviliged that it even hasn’t a password. When ever you change the service to run with another user/credentials, you’ll need to check/add those file permissions manually. Just switching credentials of the service running lucee will only work if the user has permissions to do so. Otherwise the service won’t start. Did you check/add file permissions of your new user running the lucee/tomcat service to those lucee/tomcat folders accordingly?
All right. I went back and re-added the CFService user perms (full) to the lucee folder.
Same issue. I add the user account using the browse button to set the DomainControllerName\CFService and click apply. No error. I click to the General tab and click start…service starts without complaint. Click back to the Log On tab the CFService user is still there. Close service panel and reopen…log on is set back to Local Service and still have issues with cffile working.
When I use the “proper” domain\username or username@domain.local combination as the log on I can close and reopen the service panel and the Log On user “sticks” but the service will not start for either style of domain id
This is the behaviour on both my dev machine and the new VM I created to test this.
As noted…my production server running with the Oracle Java doesn’t have this issue. The only differences are server 2012 vs 2019 and Oracle vs AdoptOpenJDK
