XNAT 1.6.3: Could not find screen for Login.vm

[Erwin Vast]

Hi all,

Since yesterday I'm trying to install XNAT 1.6.3. However, after installation I receive the following error in the browser when accessing XNAT:

  Horrible Exception: java.lang.Exception: Could not find screen for Login.vm
  	at org.apache.turbine.modules.screens.VelocityScreen.buildTemplate(VelocityScreen.java:104)
  	at org.apache.turbine.modules.screens.TemplateScreen.doBuild(TemplateScreen.java:101)
  	at org.apache.turbine.modules.Screen.build(Screen.java:57)

  (and a lot of more lines)

Logging output:

• In tomcat -> catalina.log there are no errors, except the probably non-related  ERROR db.PoolDBUtils  - SELECT pg_get_serial_sequence and similar errors. 
• In tomcat -> Localhost.[date].log shows no errors. 
• In xnat webapp -> axis.log: ERROR org.apache.axis.configuration.EngineConfigurationFactoryServlet  - Unable to find config file.  Creating new servlet engine config file: /WEB-INF/server-config.wsdd (perhaps this breaks it?). 
• In xnat webapp -> Turbine.log and xdat.log give similar errors as above noting that sevaral screens could not be found. 

The ip's in InstanceSettings.xml and the OS hostname are correctly set. I suspect it has something to do with the latest Java or Tomcat version, but I'm not sure. I'm using java 1.7.0_60 and Tomcat 7.0.54. Furthermore, the error in axis.log could be a problem. I also tested running tomcat as root (just for testing ofcourse) to make sure it's not a permission problem. Selinux is also disabled for testing to rule that out. I had an older version on disk (1.6.1) and that does not give the error with the latest tomcat and java.

Does anyone as any ideas about the cause and/or have a solution?

Thanks a lot!

Erwin

[Herrick, Rick]

I don’t have any ideas for a cause or solution, but I do know that the axis.log “error” is unrelated. It’s not really an error, it’s really more of an info message and it would be nice if it was noted that way, but it’s not. Basically it’s just saying it didn’t find a custom configuration for the Axis engine configuration, so it’s going to use its defaults to generate its own configuration.

 

I also doubt it’s the Java and Tomcat versions: I have Java 1.7.0_55 and Tomcat 7.0.54. Unless that extra +0.0_05 is the difference between working and not working and I just really doubt that.

 

When you installed 1.6.3, is this a clean installation or an upgrade of your existing 1.6.1? In either case, did you follow the full setup or update procedure as described in the wiki, including running the appropriate database script? Usually failing to upgrade the database would fail in different ways, but I’m just looking for any kind of leads on this…

 

Try this: have a look at the file TurbineResources.properties in the WEB-INF/conf folder of your deployed XNAT. Look for a property named services.VelocityService.file.resource.loader.path. This should look something like this:

 

services.VelocityService.file.resource.loader.path = /templates,/module-templates,/xnat-templates,/xdat-templates,/base-templates

 

Let me know, thanks…

 

Rick Herrick

Sr. Programmer/Analyst

Neuroinformatics Research Group

Washington University School of Medicine

(314) 827-4250

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To post to this group, send email to xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.

---

The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

[Erwin Vast]

Thanks Rick for you suggestions! It was not really an upgrade. I use a test VM without important data, so I just dropped the database and installed everything from scratch. But I accidentily compiled and deployed the 1.6.1 version instead of 1.6.3 :)

After a lot of testing I could pinpoint the problem. The cause of the error is (very likely) the usage of a dash in the webapplications name. To be exact, if I use a dash in xdat.project.name in build.properties I receive the above error 'Could not find screen for Login.vm'; without a dash it works! I reproduced this problem multiple times on two different VM's and tested the names 'xnat', 'xnat-web-app-1' and 'xnatwebapp1'. Only 'xnat-web-app-1' didn't work for me.

The problem can be reproduced on a clean VM/system by following the installation guide and using a dash in the project name. On an already XNAT-configured system, I'm not completely sure. On 1 VM I had to remove the database also, but on another VM I can get the error by just using the name xnat-web-app-1 and building/deploying it again. 

I'm glad it works now :) do you know if dashes are indeed not possible? Using dashes is not required for us, just had bad luck that we started with a dash in the name and encountered this problem :)

Thanks,

Erwin

[Erwin Vast]

Two additions to previous post:

 - The services.VelocityService.file.resource.load.path property is exactly as you said when using a non-working name.

 - I'm using Scientific Linux and tested with the java and tomcat version you mentioned. 

Kind regards,

Erwin

[Herrick, Rick]

I was not aware of an issue with a dash in the app name. That could be a problem in our code but could also just be an issue with the Turbine code. Turbine's older, back before we invented fancy characters like dashes :) I'll create an issue in our JIRA and we can have a look at it, but I also added a note to the installation and configuration documentation.

Thanks for figuring that out!

-- 

Rick Herrick

Sr. Programmer/Analyst

Neuroinformatics Research Group

Washington University School of Medicine

(314) 827-4250

--

You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To post to this group, send email to xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.

[Rick Herrick]

Time to resurrect this issue a little bit in case someone else runs into it. I was building a project with a name something like abc1234. After running setup.sh, importing the database schema, and initializing the security roles, I started the server. This is what showed up in catalina.out while Tomcat was starting up:

[Thread-5] ERROR db.PoolDBUtils  - SELECT pg_get_serial_sequence('xnat_projectData_resource','xnat_projectData_resource_id') AS col_name

[Thread-5] ERROR db.PoolDBUtils  - SELECT pg_get_serial_sequence('xnat_projectData_investigator','xnat_projectData_investigator_id') AS col_name

[Thread-5] ERROR db.PoolDBUtils  - SELECT * FROM xnat_projectData_investigator_xnat_projectData_investigator_id_seq

[Thread-5] ERROR db.PoolDBUtils  - SELECT * FROM xnat_projectData_investigator_xnat_projectData_investigator__seq

[Thread-5] ERROR db.PoolDBUtils  - SELECT pg_get_serial_sequence('xnat_subjectData_resource','xnat_subjectData_resource_id') AS col_name

[Thread-5] ERROR db.PoolDBUtils  - SELECT pg_get_serial_sequence('xnat_experimentData_resource','xnat_experimentData_resource_id') AS col_name

[Thread-5] ERROR db.PoolDBUtils  - SELECT * FROM xnat_experimentData_resource_xnat_experimentData_resource_id_seq

[Thread-5] ERROR db.PoolDBUtils  - SELECT pg_get_serial_sequence('xnat_datatypeProtocol_fieldGroups','xnat_datatypeProtocol_fieldGroups_id') AS col_name

[Thread-5] ERROR db.PoolDBUtils  - SELECT * FROM xnat_datatypeProtocol_fieldGroups_xnat_datatypeProtocol_fieldGroups_id_seq

[Thread-5] ERROR db.PoolDBUtils  - SELECT * FROM xnat_datatypeProtocol_fieldGro_xnat_datatypeProtocol_fieldGro_seq

The issue is that Postgres is interpreting the query as case sensitive. I ran the first query from that error in psql:

abc1234=> SELECT pg_get_serial_sequence('xnat_projectData_resource','xnat_projectData_resource_id') AS col_name;

ERROR:  column "xnat_projectData_resource_id" of relation "xnat_projectdata_resource" does not exist

abc1234=> SELECT pg_get_serial_sequence('xnat_projectData_resource','xnat_projectdata_resource_id') AS col_name;

                             col_name

-------------------------------------------------------------------

 public.xnat_projectdata_resource_xnat_projectdata_resource_id_seq

(1 row)

As best I can tell, the first version of the call with the capital D should work, since the Postgres docs say that this should not be happening this way:

Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case. For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are different from these three and each other. 

What's really weird is this is happening based on the project name. That is, specifically, I've tested with the same database, changing the file paths, etc. and the variable that seems to break this is the value given to the xdat.project.name setting in build.properties: if it's xnat, it works, if it's abc1234, it fails.

I've created a bug for this (https://issues.xnat.org/browse/XNAT-3538) and we'll try to figure out what's going on there. In the meantime, if someone does run into this problem and finds this post, just change your project name until something works!

To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussion+unsubscribe@googlegroups.com.
To post to this group, send email to xnat_discussion@googlegroups.com.

Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.

["Josh" Dzhoshkun Ismail Shakir]

Hi folks,

I've been experiencing this problem as well. No matter how I changed the project name, I keep getting it. The only solution that works for me is to use a brand-new database. I.e. even deleting and subsequently re-creating the same database does not work.

Regards,

Josh

To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To post to this group, send email to xnat_di...@googlegroups.com.

Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.

[Rick Herrick]

Hey Josh,

Could you tell me what your project name and database name was? I'm not sure what you mean by using "a brand-new database" as different from deleting and re-creating the same database. Do you mean you changed the name? If so, what was the name that failed and what was the name that worked?

I haven't had a chance to look into this since I last posted about it, since it's a fairly deep-dive technical topic, but I will at some point and would like to have as much information available as possible to help find the root cause.

["Josh" Dzhoshkun Ismail Shakir]

Hi Rick,

Apparently I forgot to click the option for receiving notifications of this thread, and so Google never notified me of your quick reply, for which I take this opportunity to thank you.

+ I don't remember the exact DB name any more, but it had only letters, no hyphen, no numbers, etc. in it.

+ Let me explain what I mean by "brand-new database":

createdb mydbtofail

# ...

# set up XNAT, incl. instructions related to DB

# ...

# horrible exception

# ...

dropdb mydbtofail

createdb mydbtofail

# still horrible exception

createdb myNEWdb

# ...

# set up XNAT, incl. instructions related to DB, using myNEWdb

# ...

# happy :)

#

+ Now I can also confirm that this issue pops up when I try to deploy my XNAT instance as the root of Apache Tomcat, i.e. http://myserver.com (rather than http://myserver.com/myinstance). And "brand-new database" does not help in this case. (The way I deploy my instance as root is by moving the created WAR file over to TOMCAT_HOME/webapps as ROOT.war)

Any ideas ?

Josh

["Josh" Dzhoshkun Ismail Shakir]

Hi again,

I've found out that the issue comes up if an attempt is made to access the newly deployed xnat instance (i.e. via the browser) BEFORE restarting tomcat. Even only one such attempt causes the issue to persist (i.e. even if tomcat is restarted afterwards, it doesn't seem to help).

There doesn't seem to be any issue if tomcat is restarted RIGHT AFTER the xnat instance deployment, BUT BEFORE any attempt is made to access it.

For the record, I've used project names like myproj02 to reproduce this. Only non-capital letters and numbers.

Cheers,

Josh

[Herrick, Rick]

I’ll try to recreate this by going through the same steps, but first let me make sure I understand your build/deploy process:

1. XNAT is currently running on Tomcat.
2. Rebuild XNAT in the builder folder without specifying the -Ddeploy=true flag (i.e. you’re just building the war).
3. Copy the war file into the Tomcat webapps folder without stopping Tomcat.
4. To cause the issue, try to access XNAT now. For XNAT to work properly, don’t access XNAT now.
5. Restart Tomcat.

Is that correct?

-- 

Rick Herrick

Sr. Programmer/Analyst

Neuroinformatics Research Group

Washington University School of Medicine

(314) 740-5961

+ Now I can also confirm that this issue pops up when I try to deploy my XNAT instance as the root of Apache Tomcat, i.e. http://myserver.com(rather than http://myserver.com/myinstance). And "brand-new database" does not help in this case. (The way I deploy my instance as root is by moving the created WAR file over to TOMCAT_HOME/webapps as ROOT.war)

["Josh" Dzhoshkun Ismail Shakir]

1. No, XNAT is not running yet (I'm trying to deploy a new instance).

2. Only build XNAT in the builder folder, and yes, without specifying -Ddeploy=true.

The rest is correct. Or more precisely, was correct... Right now I'm always getting the error despite the fact that I'm restarting TomCat promptly after copying the WAR file into the webapps directory. Please also note that I'm copying the WAR file as ROOT.war, as I want to run my instance under https://myserver.com (build.properties configured appropriately)

It seems that the cause of this issue is permanently causing a corruption somewhere. So I want to make sure everything is fresh when building XNAT from scratch. In that regard, my understanding is that deleting the deployments and projects folder within the builder folder should imply that the builder folder is "clean". Is that correct, or are there any other files / directories you would recommend cleaning for a really fresh build ?

[Herrick, Rick]

I would suggest shutting Tomcat down before copying your ROOT.war into the webapps folder and restarting once you’ve copied it in.

Another thing you might try is exploding the war manually. All of our operational deployments actually run in exploded configurations. I’ve run from a war before, but it’s possible that what you’re seeing is caused by running from the war and how the OS is resolving (or failing to resolve) XNAT’s attempts to access files within the web application folder.

Supposing that your builder is located in $BUILDER, you could do something like this (all commands changed for your particular OS/path configuration):

1. sudo service tomcat7 stop
2.  cd /var/lib/tomcat7/webapps
3. rm -r * (or whatever if there are things you want to leave there, but the main thing is to delete the ROOT.war and the ROOT folder if Tomcat exploded the war in place)
4. mkdir ROOT
5. cd ROOT
6. jar xf $BUILDER/deployments/xnat/target/xnat.war

You can also build XNAT directly into the webapps folder with the -Ddeploy=true option. The problem there is that it will build into, e.g. webapps/xnat. We handle mapping that configuration to the root application with changes to the <Host> entry in the server.xml file:

<Host name="localhost" appBase="empty" unpackWARs="true" autoDeploy="false">

    <Context path="" docBase="/var/lib/tomcat7/webapps/xnat"/>

</Host>

Inside of <Host>, that appBase entry tells Tomcat that its default folder for web applications is no longer webapps, but instead is “empty” (which in this case maps out to /var/lib/tomcat7/empty). There’s nothing there so there are no applications discovered on start-up.

The <Context> element then maps the deployed XNAT application to the root context (which for whatever reason is specified with “” instead of “/“). Note that the path is absolute: changing the appBase means that Tomcat can’t find the application directly since it will look relative to the $TOMCAT/empty folder.

Also note that the autoDeploy flag affects only automatic deployment AFTER Tomcat start-up (i.e. if you copy something into the appBase folder while Tomcat is running): everything within the folder indicated by the appBase setting is deployed on Tomcat start-up. That’s why you have to point to a different location for the appBase AND configure the docBase path for the root context: if you don’t, you’ll get two separate instances of XNAT running within your Tomcat, one at / and one at /xnat, which is bad.

Regarding your question about a “clean” XNAT, what I usually do if I want to completely scrub my builder folder and start with essentially untouched code is this:

rm -r bin/[A-Z]* deployments ide-bin lib plugin-resources/cache projects work

Note that ide-bin comes from my IDE, so you may not have that. Removing all of that stuff takes you back to a relatively pristine version of the builder.

That said, I don’t think that’s really your issue. There’s no connection from the Tomcat back to your builder install, so anything that happens on the webapp side will have no effect on the stuff in the builder. I’m not certain what’s going on, but I’m certain it’s not that.

["Josh" Dzhoshkun Ismail Shakir]

Thank you very much for the detailed reply, Rick. I really appreciate it. Please see my comments below.

On Tuesday, May 5, 2015 at 7:19:54 PM UTC+1, Rick Herrick wrote:

I would suggest shutting Tomcat down before copying your ROOT.war into the webapps folder and restarting once you’ve copied it in.

I had already tried this, but to no avail.

 

Another thing you might try is exploding the war manually. All of our operational deployments actually run in exploded configurations. I’ve run from a war before, but it’s possible that what you’re seeing is caused by running from the war and how the OS is resolving (or failing to resolve) XNAT’s attempts to access files within the web application folder.

Supposing that your builder is located in $BUILDER, you could do something like this (all commands changed for your particular OS/path configuration):

1. sudo service tomcat7 stop
2.  cd /var/lib/tomcat7/webapps
3. rm -r * (or whatever if there are things you want to leave there, but the main thing is to delete the ROOT.war and the ROOT folder if Tomcat exploded the war in place)
4. mkdir ROOT
5. cd ROOT
6. jar xf $BUILDER/deployments/xnat/target/xnat.war

I've tried this now. The same issue again.

 

You can also build XNAT directly into the webapps folder with the -Ddeploy=true option. The problem there is that it will build into, e.g. webapps/xnat. We handle mapping that configuration to the root application with changes to the <Host> entry in the server.xml file:

<Host name="localhost" appBase="empty" unpackWARs="true" autoDeploy="false">

    <Context path="" docBase="/var/lib/tomcat7/webapps/xnat"/>

</Host>

Inside of <Host>, that appBase entry tells Tomcat that its default folder for web applications is no longer webapps, but instead is “empty” (which in this case maps out to /var/lib/tomcat7/empty). There’s nothing there so there are no applications discovered on start-up.

The <Context> element then maps the deployed XNAT application to the root context (which for whatever reason is specified with “” instead of “/“). Note that the path is absolute: changing the appBase means that Tomcat can’t find the application directly since it will look relative to the $TOMCAT/empty folder.

Also note that the autoDeploy flag affects only automatic deployment AFTER Tomcat start-up (i.e. if you copy something into the appBase folder while Tomcat is running): everything within the folder indicated by the appBase setting is deployed on Tomcat start-up. That’s why you have to point to a different location for the appBase AND configure the docBase path for the root context: if you don’t, you’ll get two separate instances of XNAT running within your Tomcat, one at / and one at /xnat, which is bad.

I've tried this as well. Still no joy.

As a side-note, the Tomcat documentation does not recommend modifying the server.xml file directly (see https://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context)

 

Regarding your question about a “clean” XNAT, what I usually do if I want to completely scrub my builder folder and start with essentially untouched code is this:

rm -r bin/[A-Z]* deployments ide-bin lib plugin-resources/cache projects work

Note that ide-bin comes from my IDE, so you may not have that. Removing all of that stuff takes you back to a relatively pristine version of the builder.

That said, I don’t think that’s really your issue. There’s no connection from the Tomcat back to your builder install, so anything that happens on the webapp side will have no effect on the stuff in the builder. I’m not certain what’s going on, but I’m certain it’s not that.

The web app itself is not connected directly to the builder folder. However as the builder folder is being used for setting up the app, it might have an impact in case any settings are cached somewhere within the builder folder (i.e. cached when a first build is attempted, and persisting during subsequent build attempts). I've also tried cloning a fresh copy of the builder repo, but it takes a very long time, so not feasible to do every time I need a clean builder folder. That's why I was asking what a "clean" builder folder is.

I'm really clueless at this point, any further thoughts / recommendations are welcome.

Josh

[Herrick, Rick]

Regarding modifying the server.xml, the primary reason for not adding a context element directly within there is because it requires a restart of Tomcat. Generally once the context is set, though, it doesn’t require much in the way of maintenance, so this generally isn’t an issue. Optimally we’d go with the /META-INF/context.xml route but just haven’t done that for our production servers. You’re welcome to give it a try, but to be honest it’s kind of a pain in the neck and doesn’t even work to set the context path of the application (http://bit.ly/1H0VtoH):

When autoDeploy or deployOnStartup operations are performed by a Host, the name and context path of the web application are derived from the name(s) of the file(s) that define(s) the web application. Consequently, the context path may not be defined in a META-INF/context.xml embedded in the application and there is a close relationship between the context name, context path, context version and the base file name (the name minus any .war or .xml extension) of the file.

Anyway, that’s a side issue.

Regarding the issue with a “clean” builder and settings getting cached there, if there is any variance on things working or not working based on Tomcat starting and stopping, then there is no connection back to the builder folder, simply because… well, there is no connection back to the builder folder from Tomcat. So there are no settings that could get cached or modified on start-up. The primary reason for cleaning your builder folder is to get rid of build artifacts during development, e.g. when you’re changing data-type schema frequently. Nothing that happens in the deployed web app would affect this.

As noted previously, “Horrible Exception” is a Tomcat message, not an XNAT message. Have you checked the Tomcat logs, usually located in the logs folder under $TOMCAT_HOME, or your system logs (e.g. /var/log or maybe /var/log/tomcat7 or whatever?)? How have you configured the memory settings for Tomcat?

[Herrick, Rick]

This is somewhat of a long shot, but one other thing to try is to shut down Tomcat and delete everything under the work folder in your $TOMCAT_HOME. The work folder is where all of the intermediate working files for your application are placed. These are especially important if you’re deploying from a war file. On occasion I’ve seen them get stuck and not deleted even when the web app source has been updated, which can cause all kinds of weird problems. You certainly have what would qualify as a weird problem, so it’s worth a try.

-- 

Rick Herrick

Sr. Programmer/Analyst

Neuroinformatics Research Group

Washington University School of Medicine

(314) 740-5961

["Josh" Dzhoshkun Ismail Shakir]

Hi Rick,

We've finally managed to make it work. In summary, this was causing the trouble:

1. running Tomcat standalone on port 8443, and

2. using the firewall to redirect all HTTPS requests (on port 443) to port 8443.

This is the solution:

1. run Tomcat on port 8080, and

2. behind Apache HTTP, where:

3. Apache HTTP deals with all the encryption, and

4. redirects all the requests to port 8080.

We've modified the server.xml file as well:

1. Host > appBase: a directory where the WAR files will get exploded

2. Host > Context > path: "" (so that our app runs as root)

3. Host > Context > docBase: /path/to/our/war/file (excluding the extension, i.e. ".war")

(the directory in 1. is different from where my WAR file resides in 3.)

So now I simply follow the installation instructions (*) -- BTW thanks for this improved version, which is much clearer than the previous one -- to setup my XNAT instance WITHOUT the -Ddeploy=true option. Then I simply copy the generated WAR file to the destination specified in the server.xml file.

(*) https://wiki.xnat.org/display/XNAT16/XNAT+1.6+Installation+Guide

Thank you very much for your time.

Cheers,

Josh

...

[Herrick, Rick]

Interesting. Could you please post the full <Host> element from your server.xml? I think I see what you’re saying but am interested to try it out.

--

You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To post to this group, send email to xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.

[Herrick, Rick]

BTW, I meant to add, I’m glad you finally got it going! Things definitely get weird when trying to both host an application and manage all of the SSL and port redirects in Tomcat. Most sys admins I know run Tomcat in a pretty vanilla state and manage everything else outside of it thru Apache HTTPD, nginx, or something similar.

["Josh" Dzhoshkun Ismail Shakir]

Here is the Host entry, with a comment for clarification:

<Host name="localhost"  appBase="exploded"

            unpackWARs="true" autoDeploy="true"

            xmlValidation="false" xmlNamespaceAware="false">

        <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"

               prefix="localhost_access_log." suffix=".txt"

               pattern="%h %l %u %t &quot;%r&quot; %s %b" />

        <Context path="" docBase="/usr/share/tomcat/webapps/your-app-name" /> <!-- your-app-name.war: gets exploded into appBase folder above -->

</Host>

...

[Miklos Espak]

I have other installations with just tomcat, no apache httpd, and they work well. I had to use authbind to allow tomcat to run on 80/443, and I had to modify the service init script for this, but that was all.

In this specific case it is not totally clear to me which step has resolved the problem, but I suspect that removing the firewall rules for 80/443 was the key. Basically, we cleaned and rebuilt everything, and copied over all the settings from other xnat servers (like genfi). After we had finished with all this, we tried it again and it worked. We did not test after the intermediate steps, though.

Miklos