Packaging project fails if missing write permission to /home/ue4/UnrealEngine

Output of the ue4-docker info command:

ue4-docker info
ue4-docker version:         0.0.79 (latest available version is 0.0.81)
Operating system:           Linux (Fedora 30 (Workstation Edition), 5.3.7-200.fc30.x86_64)
Docker daemon version:      19.03.12
NVIDIA Docker supported:    No
Maximum image size:         No limit detected
Available disk space:       1.52 TiB
Total system memory:        31.17 GiB physical, 0 bytes virtual
Number of processors:       4 physical, 8 logical

Additional details:

• Are you accessing the network through a proxy server? No

---

Hi! I’m using ue4-docker for containerised builds on Jenkins. The Jenkins Docker plugin always runs containers with this command:

docker run -t -d -u 570896598:570800513 -w /var/jenkins/workspace/dev_game_test -v /var/jenkins/workspace/dev_game_test:/var/jenkins/workspace/dev_game_test:rw,z -v /var/jenkins/workspace/dev_game_test@tmp:/var/jenkins/workspace/dev_game_test@tmp:rw,z

The arguments after -u mach the host user and group ID, and dev_game_test is replaced with the Jenkns job name. The user seems to be set to that in order to ensure that the container has write permission to the mounted volume so that it can save build artifacts there. However, this means that since we aren’t running as the ue4 user any more we lose write permission to /home/ue4/UnrealEngine.

This shouldn’t cause any issues, since it’s normal to run programs from a read-only directory. However, the way that the ue4-docker images are set up, UE4 will actually set up a bunch of symbolic links to Mono DLLs inside /home/ue4/UnrealEngine/Engine/Binaries/ThirdParty/Mono/Linux, as well as compile some DLLs inside /home/ue4/UnrealEngine/Engine/Intermediate/Build/BuildRules the first time it needs to run the UnrealAutomationTool.

On a fresh image, Engine/Binaries/ThirdParty/Mono/Linux/lib/mono/4.5 won’t contain any DLLs (or links to DLLs). It should contain links to all the System*.dll files from the folder for the more specific version of Mono, but this will be set up automatically when you call RunUAT.sh because that in-turn calls SetupEnvironment.sh, which then calls SetupMono.sh, which then calls FixMonoFiles.sh which creates all the symbolic links necessary. We can fix this by running SetupMono.sh once as the ue4 user before trying to make any builds as any other users.

Once I got Mono working, I uncovered another issue which was that Engine/Intermediate/Build/BuildRules/UE4Rules.dll was missing. This file appears to ship with versions of UE4 from the Epic Games Launcher but once again, on source builds for Linux it seems to be auto-generated on first run. The easiest way I found to generate this file was to run UnrealBuildTool.exe once with the UE4Game target. Once it has been generated, it’ll never need to be modified again, meaning that the UE4 installation can now work as fully read-only!

To work around these issues, I’ve created my own Dockerfile based on the default ue4-full image:

FROM ue4-docker.artifactory.bigworldtech.com/ue4-full:4.26.1-opengl
RUN bash -c "source /home/ue4/UnrealEngine/Engine/Build/BatchFiles/Linux/SetupMono.sh /home/ue4/UnrealEngine/Engine/Build/BatchFiles/Linux && \
        mono Engine/Binaries/DotNET/UnrealBuildTool.exe UE4Game Linux Development"

Anyway I have a workaround to enable use of the UE4 Linux images running as a user other than ue4, but I figured this since Jenkins builds are probably a fairly common workload this may be useful to incorporate back into ue4-docker. What do you reckon?

[adamrehn]

@TBBle my understanding is that most of the first-time setup is related to configuring Mono, which is absent under Windows.

[adamrehn]

I’ve done some investigation, here are my initial findings:

• Adding a call to UnrealBuildTool at the end of the ue4-minimal Dockerfile does indeed allow users other than ue4 to compile code when using Unreal Engine 4.26, but only when the user has been created properly inside the container image or the HOME environment variable has been set to a non-empty value to prevent UnrealBuildTool from attempting to create an XML configuration file in /.config (the fallback location used in place of the user’s home directory.)

• This fix does not function for Unreal Engine 4.25 or older. In 4.26, Build.sh will attempt to rebuild UnrealBuildTool if the Engine installation is not an Installed Build, but under 4.25 and older this step is unconditional and will fail when presented with a read-only filesystem.

• Even though project code can be compiled, cooking assets fails with an unknown cook error [AutomationTool exiting with ExitCode=25 (Error_UnknownCookFailure)] and the log file path printed by the UAT output does not exist.

I’ll need to investigate further to determine if it’s possible to get cooking working. If not, then the fix will do little to help users package Unreal projects.