Updated on August 7, 2018 in #dev-mindset, #docker

Behind the Scenes of Debugging an Error That I Couldn't Google

In this case it was a Docker command that was throwing an error, but I would have applied this process to any problem.

Last week I posted Docker Tip #66 which shows a solution to a specific Docker command line error but in this article I’d like to go over the process of how I came to that solution.

Like almost everything in programming, having a solution is great but being able to understand the process so that you can solve new and unknown problems on your own with similar tactics is when things start to really get fun.

Suddenly errors and problems become situations that you can deal with in a calm state of mind instead of wanting to elbow drop your computer.

# Turning Unknowns into Knowns

Debugging an error is usually just a process of elimination. You try a bunch of things until something works.

And one of the best ways to start off on the right foot is to identify as many unknowns as you can think of – even if you think it’s trivial.

Those “is your printer turned on?” jokes were around 20 years ago and I used to laugh at them, but for longer than I can remember I’ve come to respect that question a lot.

It’s not because I expect and think people do silly things. It’s because it eliminates a potential problem. Knowing for a fact that their printer is on lets you move to the next item in the list with 100% confidence (unless they are lying!).

# Explaining the Error for This Docker Command

Someone who is taking my Dive into Docker course was happily progressing through everything but got stuck dealing with Docker volumes.

When he ran the container with a volume, Docker kept throwing this lovely message: docker: Error response from daemon: invalid mode: /app.

Our Back and Forth Emails

Nearly everything here is word for word except I’ve stripped out anything that could identify him for privacy reasons and I also stripped out things that are absolutely unimportant.

You could say this is an inside look at not only debugging a problem but potentially dealing with customer support. Offering life time support for people who take my courses is important because I want to make sure everyone can get through the content even if they get stuck.

I’ve written in my own comments and thought processes below. They are in italics.

(him) He contacted me with:

I ran into a snag on the live reloading lecture (Section 6, Docker in the Real World) when we ran this line in the terminal (everything had been working great up until this point):

docker container run ... -v "$PWD:/app" ...

I’ve removed the full contents of the command since it’s just noise. The only important bit is the volume flag which is shown.

I’m on macOS and using Docker Toolbox / Quickstart Terminal - I’ve tried using single quotes, back ticks, double quotes, no quotes, no dice!

I receive this error when trying the above code with double quotes:

docker: Error response from daemon: invalid mode: /app.

I googled the error and found some questions posed by Windows users receiving that message, but it was for completely different scenarios.

Thanks in advance! I’ll continue on with the great lectures as I await a response. Cheers!

Little things like mentioning everything up until this point was working great and that he’s just going to continue on until he gets a response lead me to believe I was dealing with someone who is as cool as a cucumber and that this will likely be a pleasant experience for both of us.

Mentioning he tried using single quotes, double quotes, back ticks and no quotes when it came to the volume path shows me he was determined to make it work. Especially since he mentioned Googling too.

(me) I replied to his initial question by asking a few questions:

1. What version of Docker do you have installed?
   My thought process here is I wanted to make sure he was using at least a semi-recent version of Docker before moving on.

2. Where do you have the source code for the course located on your Mac?
   While I don’t use Docker Toolbox myself I know it requires that your source code is located somewhere within your User’s directory, so I wanted to confirm where his code was located.

3. Is there a reason why you went with Docker Toolbox instead of Docker for Mac?
   I was generally curious here because nearly every Mac user who has reported an issue said they were using Docker for Mac. I figured he had a good reason to use the Docker Toolbox but I wanted to hear what he said to say.

4. What’s the output if you run this command: echo $PWD
   More information is better than less and in cases like this having the answer to this is a more “guaranteed” way of getting an answer to #2.

(him) He replied with answers:

1. Docker version 18.03.0-ce, build 0520e24
   I liked this answer a lot. He didn’t just say the version but he ran docker --version to give the exact version. Kudos on that. It’s also a modern version of Docker, so that’s good.

2. In a folder on my Desktop
   And this type of answer is exactly why I asked #4 originally. I don’t have a Mac and offhand I wasn’t sure if files on your MacOS desktop are in /Users (they are btw).

3. I have an older Mac, 2009 hardware. Tried installing Docker for Mac and couldn’t. :(
   Fair enough.

4. /Users/foo/Desktop/DevOps - Docker:Jenkins/diveintodocker/src/06-docker-in-the-real-world/03-creating-a-dockerfile-part-1
   I was a little taken back by the DevOps - Docker:Jenkins at first glance since that’s not related to my course but I didn’t follow up on it since it’s not important.

   After thinking for a few seconds I just assumed he probably has a bunch of DevOps / Docker / etc. related courses in there and he was using : as some type of tag separator.

Hope this helps! If the issue isn’t obvious, no worries! I’ve continued on with the course and can do almost everything else (so far)!

The last bit raised my confidence levels that no matter what happens, this is going to be a good support experience. I never leave anyone hanging (even if they go ballistic) but it’s always better when everyone is optimistic and happy.

(me) So then I asked:

Everything looks good there. It’s important the code ends up somewhere inside of /Users/foo and in your case it is.

Are you also running the command from /Users/foo/Desktop/DevOps - Docker:Jenkins/diveintodocker/src/06-docker-in-the-real-world/03-creating-a-dockerfile-part-1?

If not, you would need to do that.

I don’t just like throwing out 1 line answers. I try to share as much detail as possible for the situation, which often includes both the “why” and the “how”.

I also had to follow up with a new question here just in case. In the course notes it does tell you to run the command from that directory but I wanted to make sure.

(him) To which he replied with:

Yeah, in my terminal I cd all the way into /Users/foo/Desktop/DevOps - Docker:Jenkins/diveintodocker/src/06-docker-in-the-real-world/03-creating-a-dockerfile-part-1

I really liked this answer. He made it ultra clear what he was doing and as someone who answers a lot of questions, I love when I see that.

(me) So then I requested:

What happens if you run this:

docker container run ... -v /Users/foo/Desktop/DevOps - Docker:Jenkins/diveintodocker/src/06-docker-in-the-real-world/03-creating-a-dockerfile-part-1:/app ...

When in doubt, convert things into their most simple form. Instead of using $PWD I recommended we just use the full path manually. It can’t hurt to try.

(him) And he replied with:

From that I get:

docker: invalid reference format.
See 'docker run --help'.

I put quotes around the file path portion and got this:

docker: Error response from daemon: invalid mode: /app.
See 'docker run --help'.

That got me pretty curious. At this point I was suspicious about the path but not 100% sure on an answer yet.

(me) So then I wrote:

I can’t say that I’ve seen this one before (and I’ve seen a lot :D), but at least we determined using $PWD isn’t the issue because it’s failing with the full manual path.

You mentioned 2009 hardware, but what exact version of MacOS are you running?

Also, is there anything unique or note worthy about how you have everything set up and installed?

Lastly, does the command below also fail?

docker container run --rm -v "/Users/foo":/tmp alpine ls -la /tmp

The expected output would be no error and it should list out your user’s directory but as the contents of the /tmp folder inside of the container.

This is just another example where I’m trying to remove as many variables as possible. In this case, I tried removing as much of his custom path out of the equation as possible and also dropped back to using a basic alpine image.

(him) He replied with:

Oh ya, I get a whole data dump from that!

<insert expected output of ls which I've removed>

(me) And I followed up:

Ok now we’re getting somewhere.

We just confirmed your computer and Docker installation is capable of having volumes work.

Next step is to figure out the differences between that working command and the one that is failing.

My gut tells me it might have something to do with spaces in one of your folder names because nothing good has ever come out of using spaces in folder names when it comes to using the command line.

Can you try putting the diveintodocker folder directly on your desktop which removes “DevOps - Docker:Jenkins” from the path?

Then you would run:

docker container run ... -v /Users/foo/Desktop/diveintodocker/src/06-docker-in-the-real-world/03-creating-a-dockerfile-part-1:/app ...

And if that happens to work, you can replace the above -v flag with -v $PWD:/app as a final test.

(me) And I followed up again (before he replied):

Having just re-read that email (because I always proof read my emails after I send them) I think this might end up being a case where it all works, but for the wrong reason.

I don’t think it’s the space in the folder name that’s the problem. I think it might be the : in between Docker:Jenkins. Docker might be trying to parse that as some type of volume path.

(him) To which he replied:

That was it! I’m getting this now with both using the whole file path and $PWD, as expected:

* Serving Flask app "app.app"

 * Forcing debug mode on

 * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)

 * Restarting with stat

 * Debugger is active!

 * Debugger PIN: 132-724-937

WAHOO! I didn’t even think about the funky folder name that I used. That’s what I get for trying to be very clear about what’s in what folder, haha.

Thanks Nick - I really appreciate your determination in figuring this out! The folder names will definitely will be something I check in the future!

I still haven’t asked him about the colon in the folder name but his answer strongly makes me believe it was related to tagging content that’s inside the folder.

Mystery solved!

(me) And I finished things off with:

No problem. Glad it all worked out in the end.

The output you get now looks good.

It’s important to confirm that his output was correct to remove any doubt.

# Applying This Strategy to Your Problems and Errors

The takeaways here are to always remain calm, break things down into their simplest form, try a bunch of things out and don’t give up. When in doubt, there’s always Rubber Duck Debugging.

All of the above tactics are what I use to troubleshoot pretty much any problem and it also works for non-technical problems too. Debugging is a skill you need to practice just like anything else. You’ll get faster and better as you gain more experience.

Did you like this type of behind the scenes article? Let me know below.