Enterprise nucleus within air-gapped network trying to reach out to content-production.omniverse.nvidia.com

Hello all.

I have installed the enterprise nucleus docker within an “air-gapped” (not truly but very restricted) network. omniverse docker repo is provided for us by an internal mirror (jfrog artifactory) which is working fine. Pulling images is successful.

The issue is when I bring up the services with compose we find the stack trying to reach directly out to the internet (log indicate the resolver cache component trying to reach content-production.omniverse.nvidia.com s3 bucket to help gather example assets for the /NVIDIA mount……or something)

As we’re on an internet restricted network, this fails and seems to cause the nucleus-api container to descend into a “crash loop”.

Accessing the web interface works fine and i can connect to the server and login using the 'omniverse master credentials.

Is anyone aware of any relevant resources, developer threads or documentation to help address an issue like this? Or rather, modfiy the nucleus server setting so that it is not attempting to reach external sources. Or have heard of anything similar? I am using the eval license so don’t have access to enterprise support (yet) unfortunately. I have briefly searched these threads and will continue my research however I thought I’d ask here.


The crashing nucleus-api container was not related to the S3 resolver /NVIDIA issue.

However the issue still remains in that having a default /NVIDIA mount with options set for the usd resolver to try and reach out to an internet resource, should probably be configurable via the compose files. Particularly for those wishing to operate the platform within a restricted environment.

To understand the crashloop, we’d need to see the logs or errors.
Also, just to validate, you’re following these instructions?
Enterprise Nucleus Server Installation — Omniverse Nucleus latest documentation (nvidia.com)
As for the mount, there is currently not an option to disable the NVIDIA mount initially, but if the s3 bucket doesn’t get pinged, it shouldn’t mount, but can also be removed if it does mount.

Thanks for the reply.

I’m not sure of the exact issue with the crash loop, whether it was some OS or Kernel level dependency… but it was likely the result of trying to run the application stack on top of docker installed on Rocky 9.3. I was aware of the Ubuntu dependency statement in the docs but wanted to try none the less as we don’t have supporting configuration management for Ubuntu within our production environment. Regardless…. Using Ubuntu cleared things up. Do you think support for nucleus enterprise docker on el9 will be available in future?

Regarding the default mounts and external resources etc. I was able to work around by sourcing a custom omni.server.app.config.json file during ‘compose up’ which replaces the default configuration successfully. Feels pretty hacky though to be honest.

Ideally we’d like to be able to configure this directly within the relevant compose file I.e. remove the default /NVIDIA volume and associated external resource.

Also (sorry) yes they are the docs I’m following

We currently do not have plans to support Rocky Linux in the near future. I’ve talked with the devs about the /NVIDIA directory, thank you for the feedback.

like Nathan Abbott reacted to your message: