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

Restoring snapshot leaves behind old btrfs subvolumes due to failure to recursively delete them #2058

JohnstonJ opened this issue May 30, 2016 · 0 comments


Copy link

@JohnstonJ JohnstonJ commented May 30, 2016

Required information

  • Distribution: Ubuntu 16.04
  • The output of "lxc info" or if that fails:
apicompat: 0
auth: trusted
  - '[fd2b:84b0:23a5:1::e09]:8443'
  - '[fd2b:84b0:23a5:1:a4a0:e99a:e9ef:cebb]:8443'
  - '[fd2b:84b0:23a5:1:20c:29ff:fe58:bbb5]:8443'
  - '[2601:781:c201:15f1:a4a0:e99a:e9ef:cebb]:8443'
  - '[2601:781:c201:15f1:20c:29ff:fe58:bbb5]:8443'
  - x86_64
  - i686
  certificate: |
    -----END CERTIFICATE-----
  driver: lxc
  driverversion: 2.0.1
  kernel: Linux
  kernelarchitecture: x86_64
  kernelversion: 4.4.0-22-generic
  server: lxd
  serverpid: 1833
  serverversion: 2.0.1
  storage: btrfs
  storageversion: "4.4"
  core.https_address: '[::]:8443'
  core.trust_password: true
public: false

Issue description

When using lxc restore, it fails to clean up old btrfs subvolumes when those subvolumes have additional nested subvolumes created by the container itself. For example this might happen if following the tutorials for nesting containers by Stephane Graber here:

Steps to reproduce

  1. LXD must be configured with btrfs storage driver, that is, /var/lib/lxd must be on btrfs.
  2. On Ubuntu 16.04 host, create a new Ubuntu 16.04 container.
  3. Take a snapshot of the container.
  4. In the container, run this command to make a new subvolume: btrfs subvolume create testme
  5. Attempt to restore the snapshot.

Expected behavior: there should be no errors, warnings, or stray files & subvolumes left behind.

Actual behavior: the original subvolume is left behind as /var/lib/lxd/containers/containername.back, along with the testme subvolume we made. Also, a warning is logged to lxd.log:

t=2016-05-30T00:23:45+0000 lvl=warn msg="subvolume delete failed" driver=storage/btrfs output="ERROR: cannot delete '/var/lib/lxd/containers/sandvich.back': Directory not empty\nDelete subvolume (no-commit): '/var/lib/lxd/containers/sandvich.back'\n" subvol=/var/lib/lxd/containers/sandvich.back

I think this is the faulty line of code:

return s.subvolDelete(sourceBackupPath)

It looks like there was a previous resolved issue about this: #907 - examining the diff indicates that a new subvolsDelete function was added that recursively deletes subvolumes. I'm guessing that the above function call was somehow missed as part of that effort, and that the line of code I highlighted should instead call subvolsDelete.

Perhaps an audit of all function calls to subvolDelete should be conducted just to be sure there aren't similar bugs elsewhere?

stgraber added a commit to stgraber/lxd that referenced this issue Jun 16, 2016
Closes lxc#2058

Signed-off-by: Stéphane Graber <>
@tych0 tych0 closed this in 754ea6f Jun 16, 2016
stgraber added a commit that referenced this issue Jun 27, 2016
Closes #2058

Signed-off-by: Stéphane Graber <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
You can’t perform that action at this time.