Unclear what to do with "your webserver webroot is not mapped to.."

Hi everyone,

I am not new to Coldfusion, Lucee and Coldbox, but did not so much anymore the last years. Now I have to make a decision for some small projects, do I develop this with Laravel what is already up and running or do I try to install Lucee + IIS and see how that works nowadays and maybe do more with CFML in the future.

My installations (and I tried a lot) fails with the message below and also with other paths like: C:\lucee\tomcat\webapps\ROOT.

Totally confused now about two items:

    • which mapping (IIS? Lucee? Tomcat?)
    • which web server (IIS? Lucee? Tomcat?)

What am I doing wrong in my approach to configure this properly?

Thank you in advance,
Arjan van Dongen

Error message:
Warning, if you can see this message, your webserver webroot is not mapped to [C:\inetpub\wwwroot\lucee].
This means Lucee is only configured to handle .cfm and .cfc and other files like css, js and images won’t load properly

Hi there,
I too, have been having some issues recently trying to get my local dev (windows) to work consistently with the way our staging/prod servers look / work.

I don’t know if you like / use docker at all - but I just found this;

And am so far loving it.
The instructions are clear and straight forward - and the project - takes care of all the “setting up” work.
You don’t have to compile anything - do any weird “path” / “system environment” edits.

(I haven’t managed to get it working with multiple apps, yet… but for one it is a dream.)
(At the moment I am running a different container for each app)

The instructions are really clear and allow you to reconstruct the paths in the docker container - to match your prod environment - irrespective of how they look locally on your “host” machine.

I tried getting IIS working - and did manage to do it.
Only… I had to reinstall Lucee - after I fatally hacked up the configs and the Jar versions (testing for a bug) - and couldn’t for the life of me remember what I did / how I did it - to get Lucee working with IIS.
The default Lucee Windows installer - didn’t work for our convoluted app configuration.
(Lucee works fine - but for some reason, that I can’t correct at the moment - I couldn’t get our apps to work properly)

(assuming Windows 10 or 11)
The initial step is to make sure that (if you haven’t) you install WSL - the windows/linux sub-system - which lets you launch a linux terminal / run linux apps on the same machine as Windows.
in a “powershell” window run; wsl --install
make sure it installs “version 2” - if you have 1 installed already you can upgrade to 2, I used;
Install WSL 2

Also you need to install “Docker desktop” for windows;
Install Docker Desktop

So at the moment, all my source code is sitting c:\inetpub\wwwroot<various paths> on my windows laptop, but when you launch your docker container - you can map you windows filepaths into something else in the docker container.
Below is the command I use to create the docker container, after I have built the image.
(All the docker commands are run from “WSL”, so make sure you launch it via command line / powershell / windows icon)

Docker Run

docker container run --add-host dockerhost:`/sbin/ip route|awk '/default/ { print  $3}'` -p 8080:8080 -p 443:443 -p 80:80 \
-v /mnt/c/inetpub/wwwroot/gsn:/srv/www/app/webroot \
-v /mnt/c/inetpub/wwwroot/vxmlsurvey:/srv/www/app/vxmlsurvey \
-v /mnt/c/inetpub/wwwroot/cfmapping:/srv/www/app/cfmapping \
-v /mnt/c/inetpub/wwwroot/dbsetup:/srv/www/app/dbsetup \
-v /mnt/c/inetpub/wwwroot/trigger:/srv/www/app/trigger \
--name myapp-539-8080 gavinbaumanis/myapp-539141

–add-host dockerhost:/sbin/ip route|awk '/default/ { print $3}' : Now you can use “dockerhost” as thehostname in your Lucee Admin Datasources and use your “Windows” installed databnase(s)

-v /mnt/c/inetpub/wwwroot/gsn:/srv/www/app/webroot : /srv/www/app/webroot is where the docker container expects to find your applications root directory - don’t try to change it - just leave it where it is - and live with the convention.

And the remaining -v, mappings are for all my “mappings” that are configured, as normal, in the Lucee administrator.
Because these “source” code paths are on my local/host machine - I can edit my app’s source code with VSCode / Windows IDE of choice, in the Windows path - and have the changes, instantly “seen” by my app - in the Lucee, docker, container… AND I can use GIT / etc from my windows machine.

–name myapp-539-8080 gavinbaumanis/lucee-539141 : this gives the docker container the name “myapp-539-8080” (lucee version 5.3.9 @ port 8080 : but it, can, of course be any name you want) and finally “gavinbaumanis/myapp-539141” is my docker repository (username/image name)
(the image name is defined during the “build” - obviously BEFORE running the container of course!)
(You of course don’t have to - but if you want to, you can “push” your docker image(s) to “Docker Hub” and get them from anywhere / share them with others.

So you can set everything up, once - then share your configured / ready to go IMAGE with everyone else in your team (then they just do the docker run command with the file paths that suit their host machines.

Build command

docker image build .       \
    -t gavinbaumanis/myapp-539141 \
    --build-arg LUCEE_ADMIN_PASSWORD=changeit! \
    --build-arg LUCEE_VERSION=

-t gavinbaumanis/myapp-539141 : is to “tag”/name the docker image - instead of getting stuck having to use the GUID of the container, all the time.

The build-args are optional.
In my use-case;
–build-arg LUCEE_ADMIN_PASSWORD=changeit : Sets the password for the Lucee Administrator to “changeit” - this can be whatever you want, of course.
–build-arg LUCEE_VERSION= : is the version of Lucee that you want to install into the container (which happens automatically), also note that if the version on the Lucee downloads page has a “postfix” (BETA/RC/SNAPSHOT) - you have to include that, too, RC in my config.

It might not be readily apparent, but the advantages are;

  • You can build as many containers as you like…
    ** So you can have an identical build for multiple versions of Lucee.
    ** You can “mess around” in your container’s (linux) and Lucee configs/environment, and simply reload it - to get back to what you had before you “broke it”.

The “only” gotchya - is that of course the initial Build of the image / initial run of the container will NOT have any Lucee configuration (datasources / mappings / scheduled tasks / etc).
So you have to set these up - THEN you have to make sure that you re-save your container - otherwise you will lose your config changes, and you do that, with your container running;
(in WSL)
docker ps; which for me shows;
f633968c40b3 gavinbaumanis/myapp-539141:latest ...

Now that you have the container ID, you clone it (while it is running / after all of your config changes);
docker commit xxxxxxxxxxx gavinbaumanis/myapp-539141, where xxxxxxxx is changed out for the container ID from above : f633968c40b3
docker commit f633968c40b3 gavinbaumanis/myapp-539141

Once all this is done - and TBH it is only a few minutes;
You don’t need the terminal again.

From the Docker Desktop app - simply run your saved container.
(there’s a “play” button - when you hover on the container)

Hope that helps!

Welcome to our community!

I think you are seeing this from Lucee’s welcome page. I think that information have been introduced when the welcome page fails to load static asset files (such as .js, .css, etc) but the cfml generated html comming from .cfc and cfml is being correctly served by the Lucee engine from Tomcat.

A little brief overall explanation:

When fronting Tomcat with a webserver such as IIS, requests for .cfm files or .cfc files are passed directly to Tomcat, where the Lucee cfml engine runs these files (within Tomcat JVM). Static files such as .css, .js, .jpg, (everything that isn’t .cfm or .cfc) is served directly by the IIS webserver, because these are non-cfml files.

Now, imagine you have a wwwroot location set in IIS that differs from the docBase location (docBase is how Tomcats wwwroots are called), what would happen? It would serve files from different locations resulting in unexpected/missing static files or missing .cfc/.cfm files.

What you need to do is:

  1. Make sure docBase in Tomcat and IIS wwwroot have defined the same physical paths
  2. That all your files .cfm/.cfc and static files that your app needs to serve are all located in that physical location

Usually that is done by mod_cfml, but sometimes it may happen that static files are being served by different locations.

Make sure 1. and 2. is correctly set.

Now you have Tomcat in the back for cfml and IIS in front for non-cfml files. But how does Tomcat know where to get the .cfm/.cfc files from? The answer is, you need to configure it. At the same time IIS serves the static files from its own IIS webroot configuration.

I would highly recommend both of you look into CommandBox as a MUCH easier and lightweight method of getting a Lucee dev server up and running. All you need to do is install CommandBox, which be done via Homebrew, apt/yum, etc and then cd into your project and run

box server start

And… that’s it :wink: You don’t need Docker. You don’t need IIS. You don’t even need to install Lucee. You can still customize any part of the setup you like, but you’ll be up and running in a fraction of the time and with a fraction of the effort.

No, use ColdBox :wink:

box coldbox create app

Boom, now you’ve got a ColdBox site!

1 Like

Hi @ArjanvD,

First off, welcome to Lucee.

that being said, in addition to all the other advice on this forum, here are my suggestions.

  1. Standard best practice is to never install your webroot on your OS drive for Windows, PERIOD. You can always go to Control Panel, Administrator Tools, Computer Manager, Disk Manager and alter the storage of your box to slice and mount a smaller web only partition if you lack any other space.
  2. Unless you MUST use IIS, do not use IIS. Even on Windows, Apache HTTPD beats IIS in performance, security, and simplicity.
    3 Here is how the IIS Mapping works

IIS —> Install Directory → Service handler --App Pool —> (Mod_JK bonticode Driver) Lucee —>

So lets say Site 1 IIS Directory is C:\inetpub\site1
Now you have Lucee at c:\Lucee\webapps\root\Site1
With the Mod_JK bonticode adapter, Coldfusion is served from c:\inetpubSite1\ and any mappings you add to Lucee (more on that later)

Really though What you are doing is asking IIS to go fetch network service user, to then pick up named application pool (mod_jk bonticode) which then reads the source packet request and matches it against the known bind data.

Fun right?

Here is the better solution,

Unless you need IIS, and I do mean you have some ultra cool code that specifically calls some very legacy code, DO NOT USE IT.

instead do this

install Apache for Windows, you can find it in multiple formats. Apachehaus is great for production and Xampp is awesome if you want a dev box to migrate your php to coldfuion or just a nice bundled mariadb instance. Its actually safe to install on the OS drive, I still suggest best practice of installing it on a separate drive.

Afterwards you can just simply add the proxy information for Lucee.

now you have a rock solid, secure, faster, highly memory efficient HTTPD server. Bonus, you can remove the Desktop via power shell and just run your httpd /lucee install as command line arguments.

Hi Gavin,

Thank you so much for your detailed explanation how to install Lucee Docker. Even I don’t know if this is the solution for now, I will dive into your instructions to get Docker running because you made me very curious ; -)

Best regards,

Hi Andeas,

Thank you and I am glad to got already replies on my post.

Your description will help me for sure. Later on today I’ll use your instructions to get it done.

Thank you,

Somehow I want to use Coldbox but Commandbox is new to me, and I’m aksing myself do I want this. Maybe I have to give myself more time to implement this on a correct way and see the benefits of Coomandbox+Coldbox.

Thank you,

Hi Terry,

Thank you for the welcome and also for our effort to respond on my post ; -)

I understand IIS is not the way, but unfortuntely I work since a year in an organisation where products are developped around IIS with .net.

Your advices put me to think again if I want to continue with IIS or just impement the faster and more secure Apache.

Thank you!

I was once like you, and do not get me wrong, Microsoft has its place. I found that uptime, and server costs went down by breaking the applications down by need. There are a few ultra legacy applications that need to run IIS. Beyond that, I found after evaluation that nearly all applications could be re-written relatively quickly to work under *NIX. The very few ASP items either have been replaced with CF Code or Krestrel, the Microsoft .net httpd implementation, running under NIX.

The licensing cost savings, not to mention the added uptime are well worth the extra effort.

Do not get me wrong, I actually like some of the things Microsoft has done and like some of their technology. My environment is a complete mix of Windows, NIX and stuff that should have been long deleted 20+ years ago. I just found that as I continue to lift and shift code, its once less problem per server once converted.

Just to clarify, ColdBox is an MVC framework and CommandBox is a CLI which provides a shell, REPL, commandline scripting, and ability to start servers with no installation. You can use ColdBox without using CommandBox and you can use CommandBox without using ColdBox. (Though, they do work beautifully together!)

I sort of thought I covered that above. I’m honestly a little confused-- the instructions for getting running with Docker (which I do NOT recommend for local development) were huge with dozens of steps and software you had to install and configure, yet you promised to dig right in to understand it. The instructions to start up a ready-to-go Lucee server on CommandBox were literally just

box server start

but you’re not sure what the benefit is?? I’m… not sure what to tell you at this point :wink: Full disclosure, I’m the lead developer for CommandBox so I have an obvious bias, but it just seems like the no-brainer here.

Hi @bdw429s / everyone,

For me;
The major benefit of using docker is;
I can “replicate” as close as possible my Production (linux) environment on my Windows dev machine.

(And there may be a way to mitigate my initial annoyance with CommandBox)
But it annoyed me that it used a port that wasn’t in matching with my Prod environment.

But I definitely agree - the ability to start up a CFML server instance is spectacularly easy with CommandBox - absolutely, no doubt.


I understand that, but your annoyance may be a result of not knowing all CommandBox stuff? CommandBox may be a great alternative to docker.

Did you know that one main benefit running Lucee with CommandBox is, that you can set up everything in one single .json file placed in your webroot? You can set environment variables, JVM heap size JVM args and much more, even URLrewrites in there? You would just set that port to a fixed value there. See this example of all you can set in setting server.json here.

And you can have multiple server.json files in your webroot, example server-prod.json and server-dev.json and you can just pick the .json file on demand. E.g. you are able to set that command in the vsCode npm package.json section, so you just click a button in your vsCode to start a dev instance for development.

1 Like

Entirely agree that I know nothing about CommandBox.
Looks like I am going to have to get used it anyway - so that I can contribute to the docs!


I totally get this, and it’s one of the most common reasons I hear. For me, it’s a question of tradeoff, really. Obviously, the only way to 100% match your production deployment is to run a dev environment in the exact same on a huge Dell rackmount server right out of your datacenter under your desk :slight_smile: Of course, no one would do that because it would be a terrible inconvenience and would take a significant amount of configuration and setup, all when they could get 95% or 98% of the same setup and be happy with that. So the question becomes what percentage of a match are you willing to live with, and how inconvenienced do you want to be? Somewhere inside that continuum is your ideal setup.

Docker really shines IMO in more complex setups that require incredibly customized operation system setups or multiple inter-working services that are all local. i.e.

  • Local DB
  • Local Redis/Caching
  • Hard reliance on specific Nginx, Apache, or IIS modules
  • Multiple CF services and or load balancer/proxies that need to mimic an AWS setup, etc

But if you just need a CF site to spin up that connects to a DB over your VPN and you need some basic rewrites to be present, you can get darn close to that with a very, very simple setup. Heck, CommandBox even has some features to force Windows to be case sensitive and Linux to be case insensitive in the web server to help you get a little closer to production with the flip of a setting.

Anyway, this is a great conversation. All I’m really trying to say is CommandBox can usually get you pretty darn close to what you have in production at a fraction of the complexity so you ave to ask yourself how much convenience you’re willing to give up to get those last few percentage points of “exactness” to production and how much it really matters just for development (In theory, you have a Stage/Test/UAT environment already running on production-similar hardware).

Heck, that’s EASY To fix. Don’t throw the baby out with the bathwater!

server start port=8080

Or whatever port you want. You have total control over the port. And modules like commandbox-hostupdater allow you to setup local hostnames AND you can run all your sites on the same port if you want!