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

Comments

8 participants
@mbiebl
Contributor

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 from machinectl start foo fails if /var/lib/machines/foo is a symlink to nspawn does not support container directories that are symlinks with -M Nov 27, 2015

@poettering poettering added the RFE 🎁 label Nov 27, 2015

@crequill

This comment has been minimized.

Show comment
Hide comment
@crequill

crequill 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

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

This comment has been minimized.

Show comment
Hide comment
@juhokuu

juhokuu 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.

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

This comment has been minimized.

Show comment
Hide comment
@bfrog

bfrog 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

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

This comment has been minimized.

Show comment
Hide comment
@Ram-Z

Ram-Z 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

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

This comment has been minimized.

Show comment
Hide comment
@greg-hydrogen

greg-hydrogen 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?

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

This comment has been minimized.

Show comment
Hide comment
@gnyers

gnyers Oct 16, 2016

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

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

nspawn: properly handle image/directory paths that are symlinks
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: #2001

poettering added a commit to poettering/systemd that referenced this issue Nov 28, 2016

nspawn: properly handle image/directory paths that are symlinks
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: #2001

poettering added a commit to poettering/systemd that referenced this issue Nov 29, 2016

nspawn: properly handle image/directory paths that are symlinks
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: #2001

@keszybz keszybz closed this in 3f342ec Dec 1, 2016

Werkov pushed a commit to Werkov/systemd that referenced this issue Jan 26, 2017

nspawn: properly handle image/directory paths that are symlinks
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: #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

nspawn: properly handle image/directory paths that are symlinks
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: #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