Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nspawn does not support container directories that are symlinks with -M #2001

Closed
mbiebl opened this issue Nov 23, 2015 · 6 comments
Closed

nspawn does not support container directories that are symlinks with -M #2001

mbiebl opened this issue Nov 23, 2015 · 6 comments
Labels
Milestone

Comments

@mbiebl
Copy link
Contributor

@mbiebl mbiebl commented Nov 23, 2015

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805785

machinectl start #containername# fails when /var/lib/machines/#containername#
is symbolic link to other folder

systemd[1]: Starting Container jee...
systemd-nspawn[2798]: Failed to open root file system: Too many levels of
symbolic links
systemd[1]: systemd-nspawn@jee.service: Main process exited, code=exited,
status=1/FAILURE
systemd[1]: Failed to start Container jee.
systemd[1]: systemd-nspawn@jee.service: Unit entered failed state.
systemd[1]: systemd-nspawn@jee.service: Failed with result 'exit-code'.
ls -la /var/lib/machines
drwx------  2 root root 4096 Ноя 22 14:55 .
drwxr-xr-x 77 root root 4096 Ноя 22 14:06 ..
lrwxrwxrwx  1 root root   26 Ноя 22 14:24 jee ->
/home/#my_home_folder#/containers/jee
@mbiebl mbiebl added the machine label Nov 23, 2015
@poettering poettering added nspawn and removed machine labels Nov 27, 2015
@poettering poettering changed the title machinectl start foo fails if /var/lib/machines/foo is a symlink nspawn does not support container directories that are symlinks with -M Nov 27, 2015
@poettering poettering added the RFE 🎁 label Nov 27, 2015
@crequill
Copy link

@crequill crequill commented Dec 8, 2015

Same problem here with systemd 228
For me it's not a RFE, it's a BUG: this was working with systemd 218

@juhokuu
Copy link

@juhokuu juhokuu commented Dec 8, 2015

Yes, it did indeed work in previous versions. I was relying on this behaviour on a couple of servers and it's also something that is outlined in the machinectl man page under Files and directories:

Machine images are preferably stored in /var/lib/machines/, but are also searched for in /usr/local/lib/machines/ and /usr/lib/machines/. For compatibility reasons, the directory /var/lib/container/ is searched, too. Note that images stored below /usr are always considered read-only. It is possible to symlink machines images from other directories into /var/lib/machines/ to make them available for control with machinectl.

@bfrog
Copy link

@bfrog bfrog commented Jan 14, 2016

I just ran in to this myself after reading the man page on how I could do exactly what apparently does not work

@Ram-Z
Copy link

@Ram-Z Ram-Z commented Apr 10, 2016

Same issue. It seems unrelated to -M.

17:55 ramsi@fractal
❱❱ sudo mkdir container
17:55 ramsi@fractal
❱❱ sudo pacstrap -cd container systemd
[...]
❱❱ sudo systemd-nspawn -b -D container                                                                                                                          ~
Spawning container container on /home/ramsi/container.
Press ^] three times within 1s to kill container.
systemd 228 running in system mode. (+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
Detected virtualization systemd-nspawn.
Detected architecture x86-64.

Welcome to Chakra!

Set hostname to <localhost>.
display-manager.service: Cannot add dependency job, ignoring: Unit display-manager.service failed to load: No such file or directory.
[...]
Chakra 4.5.0-1-CHAKRA (console)
localhost login: ^]^]^]

17:58 ramsi@fractal
1❱❱ ln -s container symlink                                                                                                                                     ~
17:58 ramsi@fractal
❱❱ sudo systemd-nspawn -b -D symlink                                                                                                                            ~
Spawning container symlink on /home/ramsi/symlink.
Press ^] three times within 1s to kill container.
Failed to open root file system: Too many levels of symbolic links
@greg-hydrogen
Copy link

@greg-hydrogen greg-hydrogen commented May 1, 2016

agreed... this is a regression from previous versions, is there any way we can get the RFE tag removed and the BUG tag added, or do we need to create a new issue?

@gnyers
Copy link

@gnyers gnyers commented Oct 16, 2016

a possible workaround for anyone interested: bind mounting the target directory seems to work:
mount --bind /containerstore /var/lib/machines/

@poettering poettering added this to the v233 milestone Oct 19, 2016
poettering added a commit to poettering/systemd that referenced this issue Nov 25, 2016
This resolves any paths specified on --directory=, --template=, and --image=
before using them. This makes sure nspawn can be used correctly on symlinked
images and directory trees.

Fixes: systemd#2001
poettering added a commit to poettering/systemd that referenced this issue Nov 28, 2016
This resolves any paths specified on --directory=, --template=, and --image=
before using them. This makes sure nspawn can be used correctly on symlinked
images and directory trees.

Fixes: systemd#2001
poettering added a commit to poettering/systemd that referenced this issue Nov 29, 2016
This resolves any paths specified on --directory=, --template=, and --image=
before using them. This makes sure nspawn can be used correctly on symlinked
images and directory trees.

Fixes: systemd#2001
@keszybz keszybz closed this in 3f342ec Dec 1, 2016
Werkov pushed a commit to Werkov/systemd that referenced this issue Jan 26, 2017
This resolves any paths specified on --directory=, --template=, and --image=
before using them. This makes sure nspawn can be used correctly on symlinked
images and directory trees.

Fixes: systemd#2001

(cherry picked from commit 3f342ec)

[fbui: adjust context]
[fbui: fixes bsc#1012390]
Werkov pushed a commit to Werkov/systemd that referenced this issue Jun 22, 2017
This resolves any paths specified on --directory=, --template=, and --image=
before using them. This makes sure nspawn can be used correctly on symlinked
images and directory trees.

Fixes: systemd#2001

(cherry picked from commit 3f342ec)

[fbui: adjust context: chase_symlinks() is missing in v228. Instead of
       backporting this fair chunck of new code, use
       canonicalize_file_name() instead as the 'root' parameter is not
       used in this case.]

[fbui: fixes bsc#1012390]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.