I am setting up LXD to play around with conjure-up. I would like to the storage to be mounted only on my RAID device, so it would be good to remove the default storage or replace/redirect it.
I cannot remove the default storage because the default profile uses it.
How can I use the RAID storage with conjure-up and be sure it isn't using my default storage?
The default storage cannot be deleted because it is part of the default profile. The default profile cannot be removed. So the way around this is to push a blank profile to the default profile with;
printf 'config: {}\ndevices: {}' | lxc profile edit default
Then the default storage will be removed from the default profile, so you will now be able to remove the default storage with;
lxc storage delete default
The default storage can be deleted with sudo lxc storage delete default.
Ok, I seem to have found a workaround that would seem to work.
I delete the default profile
lxc profile delete default
Then I deleted the lxc-storage
sudo rm /var/lib/lxd/storage-pools
Finally i linked a directory on my RAID as the deleted directory and create a new storage
sudo ln -s /mnt/RAID/lxc-storage-pools /var/lib/lxd/storage-pools
lxc storage create default dir
There must be a better way to do this though.
I then reinstalled lxd because I lost my default profile set up...
If you are rearranging your storage as I was, you should backup your LXD profiles / LXD network configuration / containers / images before doing the following.
You have to delete a few things in the following order
lxc list
lxc delete <whatever came from list>
lxc image list
lxc image delete <whatever came from list>
# I did not actually need to delete lxdbr0
lxc network list
lxc network delete <whatever came from list>
echo ‘{“config”: {}}’ | lxc profile edit default
lxc storage volume list default
lxc storage volume delete default <whatever came from list>
lxc storage delete default
Related
I saw this post with different solutions for standard docker installation:
How to change the default location for "docker create volume" command?
At first glance I struggle to repeat the steps to change the default mount point for the rootless installation.
Should it be the same? What would be the procedure?
I just got it working. I had some issues because I had the service running while trying to change configurations. Key takeaways:
The config file is indeed stored in ~/.config/docker/. One must make a daemon.json file here in order to change preferences. We would like to change the data-root option (and storage-driver, in case the drive does not have capabilities
To start and stop the headless service one runs systemctl --user [start | stop] docker.
a. Running the systemwide service starts a parallel and separate instance of docker, which is not rootless.
b. When stopping make sure to stop the docker.socketfirst.
Sources are (see Useage section for rootless)
and (config file information)
We ended up with the indirect solution. We have identified the directory where the volumes are mounted by default and created a symbolic link which points to the place where we actually want to store the data. In our case it was enough. Something like that:
sudo ln -s /data /home/ubuntu/.local/share/docker/volumes"
I am running Ubuntu 20.04 and using zfs on my system drive.
I am trying to remove a docker container but I get this error:
glen $ docker rm c3250e315b06
Error response from daemon: container c3250e315b0631cc7fee17ab0c7f649a3995ea17e969705117e064a045b3775e: driver "zfs" failed to remove root filesystem: exit status 1: "/usr/sbin/zfs fs destroy -r rpool/ROOT/ubuntu_bl0u7i/var/lib/120f50d109cf1c84f20db9e6402fef9a4bd91fa8b94f1848a874539663bbdc40" => cannot destroy 'rpool/ROOT/ubuntu_bl0u7i/var/lib/120f50d109cf1c84f20db9e6402fef9a4bd91fa8b94f1848a874539663bbdc40': filesystem has dependent clones
use '-R' to destroy the following datasets:
rpool/ROOT/ubuntu_bl0u7i/var/lib/38ff67538bf4b2ccfef54cfeb55847cf6da6bee70a6bf2e5b063ab0e5820c0fd
rpool/ROOT/ubuntu_bl0u7i/var/lib/120f50d109cf1c84f20db9e6402fef9a4bd91fa8b94f1848a874539663bbdc40-init
I have no idea where to start with the error.
Can anyone help?
Edit:
I fixed it from this comment: https://github.com/moby/moby/issues/36967#issuecomment-676698563
but it nuked all my containers
I'm not sure how to do it through Docker, but ZFS is telling you that filesystem rpool/ROOT/ubuntu_bl0u7i/var/lib/120f50d...bbdc40 had a couple clones created from snapshots on that filesystem. For the sake of argument let's say there's just one, and the cloned filesystem is called clone1, which was created off of snapshot1 on the rpool/...bbdc40 filesystem. So your hierarchy is like this:
rpool/...bbdc40 -> rpool/...bbdc40#snapshot1 -> clone1
The problem is that clone1 is still referencing data from snapshot1, so you can't delete the snapshot, which prevents you from deleting the original filesystem.
However, ZFS allows you to change who the "parent" filesystem is by using the zfs promote command, which lets you change the hierarchy to this:
clone1 -> clone1#snapshot1 -> rpool/...bbdc40
Now nobody is depending on the data in rpool/...bbdc40 (because the snapshot has been moved to be on the newly promoted parent, clone1), so you can delete it.
(That said, Docker probably assumes that it has full control over the state for its filesystems, so if you go around running random ZFS commands it risks making Docker sad and confused. Use at your own risk.)
I have a VPN client in my Docker container (ubuntu:18.04).
The client must do the following:
mv /etc/resolv.conf /etc/resolv.conf.orig
Then the client should create new /etc/resolv.conf with their DNS servers. However, the move fails with an error:
mv: cannot move '/etc/resolv.conf' to '/etc/resolv.conf.orig': Device or resource busy
Can this be fixed? Thank you advance.
P.S.: I can 't change the VPN client code.
Within the Docker container the /etc/resolv.conf file is not an ordinary regular file. Docker manages it in a special manner: the container engine writes container-specific configuration into the file outside of the container and bind-mounts it to /etc/resolv.conf inside the container.
When your VPN client runs mv /etc/resolv.conf /etc/resolv.conf.orig, things boil down to the rename(2) syscall (or similar call from this family), and, according to the manpage for this syscall, EBUSY (Device or resource busy) error could be returned by few reasons, including the situation when the original file is a mountpoint:
EBUSY
The rename fails because oldpath or newpath is a directory that is in use by some process (perhaps as current working directory, or as root directory, or
because it was open for reading) or is in use by the system (for example as mount point), while the system considers this an error. (Note that there is no
requirement to return EBUSY in such cases — there is nothing wrong with doing the rename anyway — but it is allowed to return EBUSY if the system cannot otherwise handle such situations.)
Though there is a remark that the error is not guaranteed to be produced in such circumstances, it seems that it always fires for bind-mount targets (I guess that probably this happens here):
$ touch sourcefile destfile
$ sudo mount --bind sourcefile destfile
$ mv destfile anotherfile
mv: cannot move 'destfile' to 'anotherfile': Device or resource busy
So, similarly, you cannot move /etc/resolv.conf inside the container, for it is a bind-mount, and there is no straight solution.
Given that the bind-mount of /etc/resolv.conf is a read-write mount, not a read-only one, it is still possible to overwrite this file:
$ mount | grep resolv.conf
/dev/sda1 on /etc/resolv.conf type ext4 (rw,relatime)
So, the possible fix could be to try copying this file to the .orig backup and then rewriting the original one instead of renaming the original file and then re-creating it.
Unfortunately, this does not meet your restrictions (I can 't change the VPN client code.), so I bet that you are out of luck here.
Any method that requires moving a file onto /etc/resolv.conf fails in docker container.
The workaround is to rewrite the original file instead of moving or renaming a modified version onto it.
For example, use the following at a bash prompt:
(rc=$(sed 's/^\(nameserver 192\.168\.\)/# \1/' /etc/resolv.conf)
echo "$rc" > /etc/resolv.conf)
This works by rewriting /etc/resolv.conf as follows:
read and modify the current contents of /etc/resov.conf through the stream editor, sed
the sed script in this example is for commenting out lines starting with nameserver 192.168.
save the updated contents in a variable, rc
overwrite the original file /etc/resolv.conf with updated contents in "$rc"
The command list is in parentheses to operate in a sub-shell to avoid polluting the current shell's name space with a variable name rc, just in case it happens to be in use.
Note that this command does not require sudo since it is taking advantage of the super user privileges available by default inside the container.
Note that sed -i (editing in-place) involves moving the updated file onto the original and will not work.
But if the visual editor, vi, is available in the container, editing and saving /etc/resolv.conf with vi works, since vi modifies the original file directly.
I would like create new volume in Portainer. So, in Volumnes page and Create Volume, i want add my /media/USBNAS to /media container folder :
Driver options
name : /media/USBNAS value : /media
But i've an error message with invalid option key: "/media/USBNAS"
There is something I'm doing wrong, but I do not know what
You will need the "local-persist" driver for this.
You can get it here: https://github.com/CWSpear/local-persist
Just install, if possible, using the install script and you're good to go.
Name needs to be "mountpoint" and value is your local path. As you setup your container, you can choose your created volume and set the container path.
I am running Docker Toolbox v. 1.13.1a on Windows 7 Pro Service pack 1 x64OS.
with Virtual Box Version 5.1.14 r112924
when I try to run any docker image e.g. official postgres image from Docker Hub with volumes disabled, it works fine!
But when I enable the volumes it fails.
I tried all official documentations
The VM has shared folder as required and has full access to it also
shared folder screenshot
In case of my example of postgresql it crashes with following log
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... LOG: could not link file "pg_xlog/xlogtemp.27" to "pg_xlog/000000010000000000000001": Operation not permitted
FATAL: could not open file "pg_xlog/000000010000000000000001": No such file or directory
child process exited with exit code 1
initdb: removing contents of data directory "/var/lib/postgresql/data"
I know its the problem with folder permissions. But kinda stuck!
A ton of thanks in advance
I've been busy with this problem all day and my conclusion that it's currently simply not possible to run postgresql inside a docker container while keeping your data persistent in a separate volume.
I even tried running the container without linking to a volume and copying the data that was originally in /var/lib/postgresql into a folder of my host OS (Windows 10 Home), then copy that into the folder that got then linked to the container itself.
Alas, I got the next error:
FATAL: data directory "/var/lib/postgresql/data/pgadmin" has wrong ownership
HINT: The server must be started by the user that owns the data directory.
In conclusion: There's something going wrong with the ownership and the correct user owning it and to be able to fix it, you'll need a unix commandline on Windows that is able to run docker (something currently not possible with Bash on Ubuntu on Windows that is running using Ubuntu 16.04 binaries).
Maybe, in the future, you'll be able to run the needed commands (found here, under Arbitrary --user Notes), but these are *nix commands and powershell (started by Kitematic) can't run those. Bash for Ubuntu for Windows could run those, but that shell has no connection to the docker daemon/service on windows...
TL;DR: Lost a day of work: It is currently impossible on Windows.
I have been trying to fix this issue also ..
At first I thought it was a symlink problem (because the first error fails on " could not link .. operation not permitted)
To be sure symlink is permitted you have to :
share a folder in virtualbox
run virtualbox as administrator (if you account is in administrator group) Right click virtualbox.exe and select run as Administrator
if your account is not administrator, add the symlink privilege with secpol.msc > "Local Policies-User Rights Assignments" add your user to "Create symbolic links"
enable symlink for your shared folder in virtualbox :
VBoxManage setextradata VM_NAME VBoxInternal2/SharedFoldersEnableSymlinksCreate/SHARED_FOLDER_NAME 1
Alternatively you can also use the c:\User\username folder which is shared and symlink enabled by default dockertools installation
Now I can create symlinks in the shared folder from the docker container .. but I still have the same error "could not link ... operation not permitted"
So the reason must be somewhere else ... in the file permissions as you said but I do not see why ?