Fix Build Dependency for Docker

[PatrickChenHZ]

Allow latest version/release to build in Docker.
Latest Revision require ffmpeg 7 to get libavcodec 61. Which means base image must be updated to ubuntu 24.10.

[MackBambu]

Allow latest version/release to build in Docker. Latest Revision require ffmpeg 7 to get libavcodec 61. Which means base image must be updated to ubuntu 24.10.

Isn't ffmpeg being built from source in docker?

[PatrickChenHZ]

Allow latest version/release to build in Docker. Latest Revision require ffmpeg 7 to get libavcodec 61. Which means base image must be updated to ubuntu 24.10.

Isn't ffmpeg being built from source in docker?

Apparently not, when not explicitly installing FFMPEG it would complain libavcodec61 not found at runtime(build linux and therfore docker build would finish and report success). And when running with old dockerfile with ubuntu 22.04 the installed FFMPEG would not allign with version 61, as libavcodec61 require FFPMEG7 which is not supported on ubuntu 22

[MackBambu]

#5252

[PatrickChenHZ]

Given the nature and purpose of docker containers, I personally think it makes more sense to workaround the issue through building stage then adding unnecessary and potentially confusing arguments for runtime.

[MackBambu]

Given the nature and purpose of docker containers, I personally think it makes more sense to workaround the issue through building stage then adding unnecessary and potentially confusing arguments for runtime.

Agree

@PatrickChenHZ Make the suggested changes, and then it can be merged. Thank you!

[PatrickChenHZ]

Updated accordingly, please review.
Thanks!

[MackBambu]

@PatrickChenHZ Did you review my improvement suggestions?
1.Remove the dependency on the bc command, as it is no longer needed.
2.Use libwebkit2gtk-4.1-dev, which is available by default in the Ubuntu 24 repository.

[PatrickChenHZ]

@MackBambu Sorry, maybe I missed something but I couldn't see the suggestions beyond what was mentioned in the linked issue in either file review section nor file comments.

Just made suggested changes. Please review!

Thanks!

[MackBambu]

@calh
hi calh，Could you please help review this PR? I tried building and running this container, and encountered the same issue as #1530 . Thank you!

[MackBambu]

@calh
hi calh，Could you please help review this PR? I tried building and running this container, and encountered the same issue as #1530 . Thank you!

[calh]

Other than a small nitpick, looks good

[PatrickChenHZ]

@MackBambu
Thanks for reviewing. The Issue in #1530 is not really Glib(At least I believe so, we might have different logging level enabled), I could replicate (I believe) the same behavior and got

./DockerRun.sh 
+ docker run --net=host --ipc host -u chen2465 -v /home/chen2465:/home/chen2465 -v /home/chen2465/.Xauthority:/root/.Xauthority -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=:1 --privileged=true -ti --rm bambustudio
[2024-12-31 04:23:43.922421] [0x00007052a5a5c480] [trace]   Initializing StaticPrintConfigs
add font of HarmonyOS_Sans_SC_Bold returns 1
add font of HarmonyOS_Sans_SC_Regular returns 1
[2024-12-31 04:23:44.136297] [0x00007052a5a5c480] [error]   boost::filesystem::create_directory: No such file or directory [system:2]: "/home/ubuntu/.config/BambuStudio"


(process:1): GLib-GObject-CRITICAL **: 04:23:44.136: invalid (NULL) pointer instance

(process:1): GLib-GObject-CRITICAL **: 04:23:44.136: g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

in which the actual error of interest is

[2024-12-31 04:23:44.136297] [0x00007052a5a5c480] [error]   boost::filesystem::create_directory: No such file or directory [system:2]: "/home/ubuntu/.config/BambuStudio"

I included some debugging suggestions in the DockerRun.sh File in the previous commits that should help navigate around this. I did not edit them directly as different environment would have different results(related to Docker Daemon UID and your user UID), so I left it in its simplest form. It will also depend on if there is BambuStudio already on the host OS as it tries to access the config from the host. Though thus far the most universal DockerRun.sh form(which forcefully overwrites the container UID) is as below

#!/bin/bash
set -x
# Just in case, here's some other things that might help:
#  Force the container's hostname to be the same as your workstation
#  -h $HOSTNAME \
#  If there's problems with the X display, try this
#  -v /tmp/.X11-unix:/tmp/.X11-unix \
#  or 
#  -v $HOME/.Xauthority:/root/.Xauthority \
#  You also need to run "xhost +" on your host system
# Bambu Studio also require the parent directory for the configuration directory to be present to start
#  which means it is important to make sure user is passed to container correctly
#  if the following configuration does not work with error: "boost::filesystem::create_directory: No such file or directory"
#  try replacing -u line with 
#  -u $(id -u ${USER}):$(id -g ${USER}) \
#  and add 
#  -e HOME=/home/$USER \
docker run \
  `# Use the hosts networking.  Printer wifi and also dbus communication` \
  --net=host \
  `# Some X installs will not have permissions to talk to sockets for shared memory` \
  --ipc host \
  `# Run as your workstations username to keep permissions the same` \
  -u $USER \
  `# Bind mount your home directory into the container for loading/saving files` \
  -v $HOME:/home/$USER \
  -v $HOME/.Xauthority:/root/.Xauthority \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -e HOME=/home/$USER \
  -u $(id -u ${USER}):$(id -g ${USER}) \
  `# Pass the X display number to the container` \
  -e DISPLAY=$DISPLAY \
  `# It seems that libGL and dbus things need privileged mode` \
  --privileged=true \
  `# Attach tty for running bambu with command line things` \
  -ti \
  `# Remove container when it is finished` \
  --rm \
  `# Pass all parameters from this script to the bambu ENTRYPOINT binary` \
  bambustudio $* 

I've tested this in a fresh Ubuntu VM and it works fine. You do have to run

xhost +

outside the container for GUI to work, else CLI commands works perfectly.

Please let me know if the above DockerRun.sh helps addressing the problem and if I should just make this the default.

Thank you @calh I did make another commit that removed Bash from DockerFile and also addressed another potential building issue.

[MackBambu]

@PatrickChenHZ
When building the image, the UID and GID conflicted, and I had to modify USER=ubuntu in Dockerbuild.sh.

------
 > [12/12] RUN if [ "1000" != "0" ]; then       groupadd -f -g 1000 muck &&       useradd -u 1000 -g 1000 muck;     fi:
0.293 useradd: UID 1000 is not unique
------

 1 warning found (use --debug to expand):
 - WorkdirRelativePath: Relative workdir "BambuStudio" can have unexpected results if the base image changes (line 64)
Dockerfile:91
--------------------
  90 |     ARG GID=0
  91 | >>> RUN if [ "$UID" != "0" ]; then \
  92 | >>>       groupadd -f -g $GID $USER && \
  93 | >>>       useradd -u $UID -g $GID $USER; \
  94 | >>>     fi
  95 |     
--------------------
ERROR: failed to solve: process "/bin/bash -l -c if [ \"$UID\" != \"0\" ]; then       groupadd -f -g $GID $USER &&       useradd -u $UID -g $GID $USER;     fi" did not complete successfully: exit code: 4

Please let me know if the above DockerRun.sh helps addressing the problem and if I should just make this the default.

These parameters are very effective, and now I can run normally on the VM ! Do they only apply in VM environments? Can they work properly in non-VM environments?

[PatrickChenHZ]

@MackBambu

These parameters apply outside a VM as well, it works perfectly on my ubuntu and Arch workstations and all other non-VM machines I've tested on(something around 30 machines). I mentioned VM only because I wanted to test in a clean environment to make sure it is not working just because some configs on my workstations.

The user ID issue is known and yet also entirely environment-dependant. Please try to pull the latest commit from my fork, the bug fix I mentioned in the last comment is to fix this building issue. Though its more of a omit warning than a fix. It just adds the -o/--non-unique to line 93 to ignore the error. It will work in certain environment but not others(out of the box with provided DockerRun.sh) in my fork. In all other cases by using the DockerRun.sh I attached above(aka just adding all the suggested arguments in the DockerRun.sh comment section) it will just bypass all possible problems.

I am working on an actual fix to this problem as opposed to just omitting the errors. I expect to make a push today. I will leave a comment once that's done. I make extensive use of containerized Bambu Studio in our production environment so I do see this error showing up quite often, and I believe I found the fix for it.

Thanks!

[PatrickChenHZ]

@MackBambu Sorry for the delay, but I wanted to throughly tested my new setup in as much variety of system environment as I could, and I am happy to report it worked great.
Also wondering how do I request an edit to the wiki/README, could not find the source file/repo for Bambu Studio's wiki. I would like to clarify the bevahior of this new setup.

The change in this commit includes:
A entrypoint/convienience script that sets up the user dynamically at run time, making this new docker setup a works out-of-the-box experience. It is no longer necessary to configure the user at build time. In fact I may recommended Bambu considering providing this on DockerHub as a pre-built image, user can pull the image and it should work in both CLI and GUI mode as-is.
User still need basic understanding of file permission to use volume mounting(e.g. if user runs docker daemon in non-root config, if a volume owned by root, container user won't be able to access those files), but that is beyond our worry.
The old building strategy is still kept whenever possible.

Some hints I want to add to the wiki:

1. For better consistency on having X11 passthrough to work use these arguments when starting the container:

  -v $HOME/.Xauthority:/tmp/.Xauthority \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -e XAUTHORITY=/tmp/.Xauthority \

run xhost + on the host system then retry, if the arguments didn't work

2. If user want to pass through their home directory but do not want host's bambu studio configuration adopted in the container, do a docker "double mount" and mount an anonymous volume to the config folder
   -v :SHOME/.config/BambuStudio

Here is the ”new“ behavior,

Case1： Container built "blind" with no build args docker build -t bambustudio . or sudo docker build -t bambustudio .
Runtime:

1. Run as root sudo docker run bambustudio or sudo ./DockerRun.sh
   user inside container is root, you can either bind mount /root to to the contatiner or use it as is.
2. Run as non-root docker run bambustudio or ./DockerRun.sh
   user inside container is root, you may mess up file permission when mounting, but it works
3. Run as non-root or root, but environmental variables of desired user is passed e.g.

docker run \
  `# Use the hosts networking.  Printer wifi and also dbus communication` \
  --net=host \
  `# Some X installs will not have permissions to talk to sockets for shared memory` \
  --ipc host \
  `# Run as your workstations username to keep permissions the same` \
  `# Bind mount your home directory into the container for loading/saving files` \
  -v $HOME:$HOME \
  -e RUN_USER=$USER \
  -e RUN_UID=$(id -u ${USER}) \
  -e RUN_GID=$(id -g ${USER}) \
  -v $HOME/.Xauthority:/tmp/.Xauthority \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -e XAUTHORITY=/tmp/.Xauthority \
  `# Pass the X display number to the container` \
  -e DISPLAY=$DISPLAY \
  `# It seems that libGL and dbus things need privileged mode` \
  --privileged=true \
  `# Attach tty for running bambu with command line things` \
  -ti \
  `# Remove container when it is finished` \
  --rm \
  `# Pass all parameters from this script to the bambu ENTRYPOINT binary` \
  bambu_studio_no_arg $* 

a new user is created at container startup and bambu studio is executed with user passed through, user can bind mount their desired folders.

Case2: Same as original build behavior, current user is passed as build arg when building the container, it get built into the image and skip any setup when container starts, suitable for developers. developers can go into dockerfile and just skip the entrypoint.sh file if they desire. sudo ./DockerBuild.sh(root is used, you should use sudo ./DockerRun.sh as well) or ./DockerBuild.sh (docker usergroup/access docker daemon without sudo needs to be setup, current user is used.) or hard code desired UID/GID/USER as build args.

1. Container started with ./DockerRun.sh(no extra environmental variables set), the user that was passed at build time is used.
2. Container started with

  -e RUN_USER=$USER \
  -e RUN_UID=$(id -u ${USER}) \
  -e RUN_GID=$(id -g ${USER}) \

set, if the user passed here is different from the user set at build time, current user is added inside the container and bambustudio gets executed with this newly added user.

I believe this is a good middle ground between users who just wish to use Bambu Studio in container as a CLI service or as a sandbox, and developers.
It works out-of-the-box for regular users and docker build CI/CD pipeline, also allows devs who wish isolation but doesn't want to wait for the user adding process at each container start.

Please let me know what you think and if it works!

[MackBambu]

@PatrickChenHZ I successfully built the container and tested some functionalities. It looks great，thank you for your help! If there's any wiki that needs updating, I can help replace the current instructions.

@lanewei120 If the CI build passes, I think we can merge it.

[lanewei120]

thanks for doing this