I added setfacl command in my dockerfile put its not executed in the product image, however, when I executed manually inside the image container its working perfect
I tried using RUN command and its not working
i read before that ACL commands not preserved in the docker image so
these 3 lines are part of my Dockerfile which is Script containing the setfacl commands I want to execute
COPY script.sh .
RUN chmod +x script.sh
RUN sh script.sh
and the script contain
#!/bin/bash
setfacl -R -d -m g::rwx /var/www/html/storage/framework/views/
setfacl -R -d -m o::rw /var/www/html/storage/framework/views/
mkdir create-testdir-to-make-sure-that-script-is-executed
the test dir executed successfully, whereas the setfacl didn't make any effect cause when i create any file in the container in the views dir its not take the permisions in the setfacl
Related
the only difference between them is that the "dev" folder exists in centos image,
check the comment in this piece of code(while executing docker build)，appreciate it if anyone can explain why?
FROM centos:latest
LABEL maintainer="xxxx"
RUN dnf clean packages
RUN dnf -y install sudo openssh-server openssh-clients curl vim lsof unzip zip
**below works well!**
# RUN mkdir -p oop/script
# RUN cd oop/script
# ADD text.txt /oop/script
**/bin/sh: line 0: cd: dev/script: No such file or directory**
RUN mkdir -p dev/script
RUN cd dev/script
ADD text.txt /dev/script
EXPOSE 22
There are two things going on here.
The root of your problem is that /dev is a special directory, and is re-created for each RUN command. So while RUN mkdir -p dev/script successfully creates a /dev/script directory, that directory is gone once the RUN command is complete.
Additionally, a command like this...
RUN cd /some/directory
...is a complete no-op. This is exactly the same thing as running sh -c "cd /some/directory" on your local system; while the cd is successful, the cd only affects the process running the cd command, and has no effect on the parent process or subsequent commands.
If you really need to place something into /dev, you can copy it into a different location in your Dockerfile (e.g., COPY test.txt /docker/test.txt), and then at runtime via your CMD or ENTRYPOINT copy it into an appropriate location in /dev.
I am changing the privileges on a few scripts before running them in the containers. I want to modify the script's permissions in one command.
This fails for the Dockerfile command:
RUN chmod +x {add, subtract}.sh
The following does work:
chmod +x *.sh
However, I do not want all the scripts in the local folder to have the execute permission.
Edit:
Here is the full Dockerfile:
FROM golang:1.12
COPY . .
RUN chmod +x {add, subtract}.sh
It fails not only because of docker, but because it is invalid sh syntax. For the shell syntax portion, you want:
chmod +x {add,subtract}.sh
Note the space is removed after the comma.
Furthermore, as per this, to allow for normal shell processing you need to modify the RUN command a little. To achieve what you want, do this:
RUN /bin/bash -c 'chmod +x /tmp/{add,subtract}.sh'
Tested with:
FROM golang:1.12
COPY add.sh /tmp
COPY subtract.sh /tmp
RUN /bin/bash -c 'chmod +x /tmp/{add,subtract}.sh'
In my .bashrc I'm using .sh script for easily configuring newly installed Debian. But while trying to
rm -f ~/.bash_aliases
wget https://raw.githubusercontent.com/.../.bash_aliases
rm -f ~/.bashrc
wget https://raw.githubusercontent.com/.../.bashrc
it's just omitting those line?
File is with permission chmod +x ./script.sh and run by sudo ./script.sh
What could possibly be wrong?
(In final code there is full link, files are being downloaded as .bashrc.1 and .bash_aliases.1)
Don't use sudo unless you have a good reason.
When you run sudo ./script.sh it runs as root, so ~ refers to root's home directory /root instead of your user's home directory.
Just run ./script.sh instead, so that it runs as you and modifies your own home directory.
I am using the docker-solr image with docker, and I need to mount a directory inside it which I achieve using the -v flag.
The problem is that the container needs to write to the directory that I have mounted into it, but doesn't appear to have the permissions to do so unless I do chmod 777 on the entire directory. I don't think setting the permission to allows all users to read and write to it is the solution, but just a temporary workaround.
Can anyone guide me in finding a more canonical solution?
Edit: I've been running docker without sudo because I added myself to the docker group. I just found that the problem is solved if I run docker with sudo, but I am curious if there are any other solutions.
More recently, after looking through some official docker repositories I've realized the more idiomatic way to solve these permission problems is using something called gosu in tandem with an entry point script. For example if we take an existing docker project, for example solr, the same one I was having trouble with earlier.
The dockerfile on Github very effectively builds the entire project, but does nothing to account for the permission problems.
So to overcome this, first I added the gosu setup to the dockerfile (if you implement this notice the version 1.4 is hardcoded. You can check for the latest releases here).
# grab gosu for easy step-down from root
RUN mkdir -p /home/solr \
&& gpg --keyserver pool.sks-keyservers.net --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4 \
&& curl -o /usr/local/bin/gosu -SL "https://github.com/tianon/gosu/releases/download/1.4/gosu-$(dpkg --print-architecture)" \
&& curl -o /usr/local/bin/gosu.asc -SL "https://github.com/tianon/gosu/releases/download/1.4/gosu-$(dpkg --print-architecture).asc" \
&& gpg --verify /usr/local/bin/gosu.asc \
&& rm /usr/local/bin/gosu.asc \
&& chmod +x /usr/local/bin/gosu
Now we can use gosu, which is basically the exact same as su or sudo, but works much more nicely with docker. From the description for gosu:
This is a simple tool grown out of the simple fact that su and sudo have very strange and often annoying TTY and signal-forwarding behavior.
Now the other changes I made to the dockerfile were these adding these lines:
COPY solr_entrypoint.sh /sbin/entrypoint.sh
RUN chmod 755 /sbin/entrypoint.sh
ENTRYPOINT ["/sbin/entrypoint.sh"]
just to add my entrypoint file to the docker container.
and removing the line:
USER $SOLR_USER
So that by default you are the root user. (which is why we have gosu to step-down from root).
Now as for my own entrypoint file, I don't think it's written perfectly, but it did the job.
#!/bin/bash
set -e
export PS1="\w:\u docker-solr-> "
# step down from root when just running the default start command
case "$1" in
start)
chown -R solr /opt/solr/server/solr
exec gosu solr /opt/solr/bin/solr -f
;;
*)
exec $#
;;
esac
A docker run command takes the form:
docker run <flags> <image-name> <passed in arguments>
Basically the entrypoint says if I want to run solr as per usual we pass the argument start to the end of the command like this:
docker run <flags> <image-name> start
and otherwise run the commands you pass as root.
The start option first gives the solr user ownership of the directories and then runs the default command. This solves the ownership problem because unlike the dockerfile setup, which is a one time thing, the entry point runs every single time.
So now if I mount directories using the -d flag, before the entrypoint actually runs solr, it will chown the files inside of the docker container for you.
As for what this does to your files outside the container I've had mixed results because docker acts a little weird on OSX. For me, it didn't change the files outside of the container, but on another OS where docker plays more nicely with the filesystem, it might change your files outside, but I guess that's what you'll have to deal with if you want to mount files inside the container instead of just copying them in.
I would like to create a directory using a bash script and then set the mode to 00755 at the same time
mkdir -p -m=00755 "/dir/dir2"
Is this the correct way of using them together and can I also add chown command to the same line while creating them?
It goes a little like this:
install -d -m 0755 -o someuser -g somegroup /dir/dir2
If you want to set the owner during creation, you can simply impersonate as this user, using sudo for example:
sudo -uTHE_USER mkdir -p -m=00755 "/dir/dir2"
This has the advantage that there will be no time difference between creation and changing the ownership, which could otherwise being harmful if exploited.
Yes that should work. As for the chown, simply follow the command ' && chown... '. && is similar to ; except the next command ONLY executes if the previous command exits success (0).