Unable to open USD stage in Omniverse KIT service

Hi,

I built a KIT service from KIT-APP-TEMPLATE and wrote an API endpoint to open a USD file from a nucleus server.
However, after containerizing and deploying it to the server, I was unable to open the USD file located at the path 'omniverse://40.71.177.24/Projects/Bouygues/

Does anyone have any idea how to solve it?

Here are the logs:

sh: 1: xdg-open: not found
2024-12-18 08:16:53 [17,693ms] [Warning] [carb.omniclient.plugin]  Tick: provider_nucleus: Failed to launch browser (err=32512)!
2024-12-18 08:16:53 [17,694ms] [Error] [omni.usd] Failed to open : omniverse://40.71.177.24/Projects/Bouygues/Bouygues.usd
2024-12-18 08:16:53 [17,694ms] [Error] [omni.usd] Open USD error: Failed to open:omniverse://40.71.177.24/Projects/Bouygues/Bouygues.usd

My code script:

async def open_usd(request: OpenUSDRequest):
        file_path = request.file_path

        try:
            def process_url(url):
                    # Using a single leading `.` to signify that the path is
                    # relative to the ${app} token's parent directory.
                    if url.startswith(("./", ".\\")):
                        return carb.tokens.acquire_tokens_interface().resolve(
                            "${app}/.." + url[1:]
                        )
                    return url
            stage = omni.usd.get_context().get_stage()
            current_stage = stage.GetRootLayer().identifier if stage else ''

            # If we are, we don't need to reload the file, instead we'll just send the success message.
            if omni.client.utils.equal_urls(file_path, current_stage):
  
                return {
                    "status": "success",
                    "message": f"Client requested to open a stage that is already open: {file_path}"
                }

            # Open the USD stage
            success = omni.usd.get_context().open_stage(process_url(file_path))
            if not success:
                return {
                    "status": "error",
                    "message": f"Failed to open USD file at {file_path}"
                }

            return {
                "status": "success",
                "message": f"USD file at {file_path} has been successfully opened."
            }
        except Exception as e:
            return {
                "status": "success",
                "message": f"Error while opening USD file: {str(e)}"
            }

Try the same thing again but don’t use the Nucleus server. Just try putting the usd file directly where the container can access it, through normal disk storage, and see if that works. Then we will know more about the isolated problem. There is no need to use a Nucleus server in most cases. Nucleus Enterprise has some advantages, but in general for small teams and individuals, just normal windows or Linux file storage is perfectly sufficient.

Thanks Richard!

I added the USD file directly to the container, and it worked. However, my team has Nucleus Enterprise, and we prefer using it instead of storing files elsewhere.

We deployed OVAS system for streaming and can send a message to open a USD file by its nucleus path, but We could not open it through the KIT 106.4 service and API endpoint.

Ok understood. So you are saying that it is specific to Kit 106.4? Are you using the Kit App Template?

Can you take a look at this webpage on Nucleus for Kit App Streaming Nucleus Storage Credentials — Kit App Streaming API

Yes, I use a KIT 106.4 version from the KIT App Template. For streaming through KIT Viewer Streaming template we can connect to our nucleus server, but when we build a backend server from KIT service template and deploy it, we were not able to connect to our nucleus server.

Since you are an Enterprise Client and this is clearly an advanced topic for a custom kit app, I think it would be best if you contact your Enterprise Rep for support. If you do not have one, please PM me and I will try to get you some specific advanced help.

Thanks Richard for your help. I will contact our Enterprise Rep and get back to you once I resolve this issue. Perhaps someone in our community has encountered the same problem.