When I did the lab exercise of Chapter 4 I put the USER student before the RUN npm install --omit=dev instruction. The building resulted in the following error:
Error_lab4
Then I put the USER student instruction after the RUN instruction and could finish my lab.
However when I looked at the solution and the demo I see that USER student should be before the RUN command, but I can't get it working.
Can you explain why it is not working for me?
Hi @Travis, I don't understand what the "WORKDIR /app" position inside the Containerfile changes about permission. Can you better explain me?
Setting a working directory is like using CD to a directory. You are changing the directory and setting the directory where you are doing the actual work.
So when you set the working directory, you are saying this is the directory I am in and this is where my commands are being executed. The NPM command attempts to build and install in your working directory. The user in this instance doesn't have permissions to write to that directory.
Think of this not in terms of a container, but regular Linux or systems ... as a Linux user, let's say student ...
in your home directory you can type do the following:
echo "This is a test" > test.txt
This will create a file called test.txt with the contents "This is a test".
Now take that same Linux user student and first go into the directory /etc/
echo "This is a test" > test.txt - bash: test.txt: Permission denied
You get a permission denied because the student user doesn't have the ability to write into that directory
It isn't changing anything about permissions, but it is created and owned by ROOT. Setting that directory essentially says this is where you are going to do the work, but you don't own that directory as the student user.
I finally decided to look at the exercise and the solution in the book. The last thing being done is setting the WORKDIR before switching to the USER student.
What happens in between is all kinds of things are done as root. Having the working directory up higher would have resulted in possible files and other items/artifacts being created by ROOT user that aren't accounted for in the copy and other commands where you change permissions and ownership. Most likely one of those items is causing the permission denied.
Thanks @Travis I got it
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.