Batch mode license activation fails in a Docker container

Hello!

I'm trying to set up a Windows Docker container to perform our automated Unity builds. I'm trying to activate the license and I'm getting an error.

I'm running the following command in the Docker container (in a powershell console).

Start-Process -FilePath 'c:\program files\unity\editor\unity.exe' -ArgumentList '-batchmode','-quit','-nographics','-logfile','log.txt','-serial','xxx','-username','yyy','-password','zzz' -Wait

The log then gets the following output:

BatchMode: Unity has not been activated with a valid License. Could be a new activation or renewal...



(Filename: C:\buildslave\unity\build\Platforms/Windows/Modules/LicensingLegacy/WinILicensingAdapter.cpp Line: 43)



DisplayProgressbar: Unity license

Cancelling DisplayDialog: Updating license failed Failed to update license within 60 seconds. Exiting.

This should not be called in batch mode.



(Filename: C:\buildslave\unity\build\Editor/Platform/Windows/EditorUtility.cpp Line: 1162)



Exiting without the bug reporter. Application will terminate with return code 1

It seems like Unity might be trying to display some kind of dialog box, but is unable to because it's in a headless container? Is there some way around this? When I run the same command outside of the Docker container, it completes successfully.

 

The username, password and serial number are correct. I am able to run the same command outside of the Docker container successfully.

The cache is empty within the Docker container, the container contains a clean install of Unity, however the activation still fails with the same error.

Is there anything else that could be causing this?

 

I tried this with both 2019.1.14 and 2018.2.21 with the same results for both.

 

I just ran into this exact issue as well.

I have a Windows container based on mcr.microsoft.com/windows:1903 and I'm trying to activate a fresh install of Unity version 2018.4.2f1 on it. I also tried Unity version 2019.2.8f1 without any luck.

The command works fine outside the container.

 

My container can talk to the Internet just fine. For instance, I was able to curl unity.com from within the container successfully. I can also confirm this with a Wireshark dump of network traffic from the container. However when running the unity activate command, I saw no traffic being generated at all when it failed, as if it wasn't even trying to talk over the network.

Is there anything else I can try?

 

Which log would that be? Where would I find it? What i pasted in the original comment is the full contents of log.txt that was generated by the command I pasted. Is there a log elsewhere I can look at?

 

Running without the parameters you specified produces no console output at all. The Editor.log file you mentioned is exactly the same as the contents I pasted in the original comment.

 

Hey Amir,

I tried again with Unity 2020.1.0a8 and here's the log:

[Licensing::Module] Channel doesn't exist: "LicenseClient-ContainerAdministrator"

[Licensing::Module] Successfully launched the LicensingClient (PId: 5944)

[Licensing::Module] Successfully connected to LicensingClient on channel: "LicenseClient-ContainerAdministrator"

Entitlement-based licensing initiated

[LicensingClient] Licenses updated successfully

BatchMode: Unity has not been activated with a valid License. Could be a new activation or renewal...

(Filename: C:\buildslave\unity\build\Platforms/Windows/Modules/LicensingLegacy/WinILicensingAdapter.cpp Line: 44)



DisplayProgressbar: Unity license

[Licensing::Module] Error: License is not active (com.unity.editor.headless). HasEntitlements will fail.

Cancelling DisplayDialog: Failed to activate/update license Failed to activate license within 60 seconds. Please try aga

in later or contact support@unity3d.com

This should not be called in batch mode.

(Filename: C:\buildslave\unity\build\Editor/Platform/Windows/EditorUtility.cpp Line: 1116)



Exiting without the bug reporter. Application will terminate with return code 1

 

Here's the log from Unity 2019.3.0b7

[LicensingClient] ERROR Failed to connect to local IPC

[Licensing::Module] Failed to connect to channel: LicenseClient-ContainerAdministrator

[Licensing::Module] Successfully launched the LicensingClient

[Licensing::Module] Successfully connected to LicensingClient on channel: LicenseClient-ContainerAdministrator

[Licensing::Module] Successfully launched and connected to LicensingClient

Entitlement-based licensing initiated

[LicensingClient] Licenses Updated successfully in LicensingClient

BatchMode: Unity has not been activated with a valid License. Could be a new activation or renewal...

(Filename: C:\buildslave\unity\build\Platforms/Windows/Modules/LicensingLegacy/WinILicensingAdapter.cpp Line: 45)



DisplayProgressbar: Unity license

Assertion failed on expression: 'g_BackgroundThread == nullptr'

(Filename: C:\buildslave\unity\build\Editor/Src/TaskManager.cpp Line: 192)



[Licensing::Module] License is not active (com.unity.editor.headless). HasEntitlements will fail.

Cancelling DisplayDialog: Updating license failed Failed to update license within 60 seconds. Exiting.

This should not be called in batch mode.

(Filename: C:\buildslave\unity\build\Editor/Platform/Windows/EditorUtility.cpp Line: 1120)



Exiting without the bug reporter. Application will terminate with return code 1

I double checked the network connection and I'm indeed able to ping and connect to license.unity3d.com and any other servers that I tried. Networking appears to be working correctly.

 

I ran both 2020.1.0a8 and 2019.3.0b7 and got the same output as tgwozdz_unity. The container definitely has a working network connection and I was able to ping license.unity3d.com (it resolved to 35.195.230.199). Happy to try any other troubleshooting steps you can think of!

 

Why is this issue "Won't fix"? Not being able to active Unity in a docker container is a critical issue. We give your company thousands of dollars to have licenses and the licensing system does not work, how is this not a major issue?

 

Listing those dependencies would be awesome. I'm working on the same thing but in Ubuntu. (where 2019.2 and before works but 2019.3 doesn't)

 

seconded, we have this issue, also using ubuntu. We've just updated to 2019.3 and it was working perfectly before in containers.

I also attempted to allow full access for the container with the following flags, but it didn't resolve it.

securityContext:
privileged: true

 

following on this thread
https://issuetracker.unity3d.com/issues/cannot-activate-license-within-a-docker-container
I have tried to activate the license unity on version 2019.4.12f1 and 2020.2.0b9 on a windows docker container "mcr.microsoft.com/windows:2004-amd64" but that failed.
The command that I've run is as follow:

Code (CSharp):

1. Start-Process -FilePath 'C:\PATH_TO_UNITY\\unity.exe' -ArgumentList '-batchmode','-quit','-nographics','-logfile','c:/logs/activate.log','-serial','XXXX','-username','XXXX','-password','XXXX' -Wait

The logs I got for 2019.4.12f1 are:

The logs I got for 2020.2.0b9 are:

 

I've managed to get this working for unity 2020.3.14f1

I had to use mcr.microsoft.com/windows:1909 docker image any later images seems to break it. (have not tested windows server ltsc2022) but 2004 and 20H2 didn't work.

as mentioned above the issue lies with a couple of windows services not running.

starting the services when the container boots up is partially the fix I also had to ensure the network was set to private not public and in addition to this I had to setup a docker network using the transparant driver per https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/network-drivers-topologies

in order to check if the Network List Manager detects if there is internet connection you can run Get-NetConnectionProfile

Then when building the container I installed a service which runs on bootup to run the powershell script which enables all the services

Also as a sidenote unity does not seem to run properly with hyperv isolation as such make sure to run the container with --isolation=process The drawback of this is that you need to have the same OS on the container host which means you'll likely have to downgrade windows on your host machine to build 1909.

Code (CSharp):

1. Set-Service 'wmiApSrv' -StartupType Automatic
2. Set-Service 'nlasvc' -StartupType Automatic
3. Set-Service 'netprofm' -StartupType Automatic
4. Start-Service 'netprofm'
5. Start-Service 'wmiApSrv'
6. Start-Service 'nlasvc'
7. Set-NetConnectionProfile -Name Network -NetworkCategory Private

the full docker command I used for running the container is as follows

Code (CSharp):

1. docker run -it --isolation=process --device class/5B45201D-F2F2-4F3B-85BB-30FF1F953599 --network=transparent-network test:windows1909

--device class/5B45201D-F2F2-4F3B-85BB-30FF1F953599 ensures the gpu is accesible to the container which might be handy if you need to do anything with regards to textures etc

 

Not exactly the same issue as OP, but we fixed it in docker by doing a separate command before calling our executeMethod. If we tried to license in the same command as the execute method in 2019.12.5 or later, we got the same error as OP.

Code (CSharp):

1. xvfb-run --auto-servernum --server-args='-screen 0 640x480x24' /opt/unity/Editor/Unity -batchmode -nographics -adb2 -logFile $CI_PROJECT_DIR/artifacts/Editor_Build${distributionMethod}.log -username USERNAME@DOMAIN m -password $MY PASS -serial $MY_SERIAL -quit

 

For what it's worth, Unity's network connectivity detection is crap. Even on a native Windows 10, it often fails if you have multiple bridge adapters (because of VMs or other complex configs). In short, you're doing it wrong by relying on a Windows service, since it often picks the wrong adapter to determine connectivity. This is 100% a Unity bug, and there are other forum posts where this has been explained and not fixed for years and years. It's the truth.