Docker "0c6d765c54" upgrade: image build problem: "Directory renamed before its status could be extracted"

[mfeblowitz]

Expected behavior

Docker image creation would complete successfully when executing:

RUN wget -q -O- $xyzPackage | tar -xz -C / --owner=user1 --group=user1

Actual behavior

Several reports like:

tar: dir1: Directory renamed before its status could be extracted
tar: dir1: Directory renamed before its status could be extracted
...
The command '/bin/sh -c wget -q -O- $xyzPackage | tar -xz -C / --owner=user1 --group=user1' returned a non-zero code: 2

Information

The second thing to go wrong after upgrading to version 1.13.0, 2017-01-19, Channel: stable) (I think) - definitely had hashcode: 0c6d765c54. (First thing was corrupt Data directory: I already reported that.)

Tried this:

• Uninstalled Docker and removed Containers/com.docker.docker.
• Reinstalled Docker
• still saw messages
• Uninstalled Docker and removed Containers/com.docker.docker.
• Rolled back to Version 1.12.5 (14777), Channel: Stable, hashcode 3e6f00c1dc
• the command then completed without error

Steps to reproduce the behavior

[justincormack]

Is there any way to provide a way to reproduce this?

It may be an overlay storage driver issue - you can add {"storage-driver":"aufs"} in the advanced daemon preferences pane and see if that makes a difference.

[samoht]

@mfeblowitz could you please provide a diagnostic ID so that we can investigate your issue? Thanks! (see https://docs.docker.com/docker-for-mac/troubleshoot/#/diagnose-problems-send-feedback-and-create-github-issues)

[mfeblowitz]

I'm under a time crunch. I'll try the upgrade again when I get a chance and will send the diagnostics.

[mfeblowitz]

Ok -

I upgraded again and again saw the behavior. Diagnostic ID is 213C8854-B875-4328-A46E-2DD06B6B7E59

All diagnostic tests reported [OK].

Here's the unaltered listing of 2 files untarred ok (there were many) and then the error message lines:

...
opt/ibm/InfoSphere_Streams/4.2.0.3/toolkits/com.ibm.streams.rulescompiler/com.ibm.streams.rulescompiler/ODMCompiledRuleset/ODMCompiledRuleset_h.cgt
opt/ibm/InfoSphere_Streams/4.2.0.3/toolkits/com.ibm.streams.rulescompiler/com.ibm.streams.rulescompiler/ODMCompiledRuleset/ODMCompiledRuleset.xml

tar: opt/ibm/InfoSphere_Streams/4.2.0.3/java/bin: Directory renamed before its status could be extracted
tar: opt/ibm/InfoSphere_Streams/4.2.0.3/java: Directory renamed before its status could be extracted
tar: opt/ibm/InfoSphere_Streams/4.2.0.3/etc/webApps/dfe/eclipse/plugins/dfe/WEB-INF/classes: Directory renamed before its status could be extracted
tar: opt/ibm/InfoSphere_Streams/4.2.0.3/etc/webApps/dfe/eclipse/plugins/dfe/WEB-INF: Directory renamed before its status could be extracted
tar: opt/ibm/InfoSphere_Streams/4.2.0.3/etc/webApps/dfe/eclipse/plugins/dfe: Directory renamed before its status could be extracted
tar: opt/ibm/InfoSphere_Streams/4.2.0.3/etc/webApps/dfe/eclipse/plugins: Directory renamed before its status could be extracted
tar: opt/ibm/InfoSphere_Streams/4.2.0.3/etc/webApps/dfe/eclipse: Directory renamed before its status could be extracted
tar: opt/ibm/InfoSphere_Streams/4.2.0.3/etc/webApps/dfe: Directory renamed before its status could be extracted
tar: opt/ibm/InfoSphere_Streams/4.2.0.3/etc/webApps: Directory renamed before its status could be extracted
tar: opt/ibm/InfoSphere_Streams/4.2.0.3/etc: Directory renamed before its status could be extracted
tar: Exiting with failure status due to previous errors
The command '/bin/sh -c wget -q -O- $streamsDevelopmentPackage | tar -xvz -C / --owner=streamsadmin --group=streamsadmin' returned a non-zero code: 2

As stated above, the referenced wget command works fine in the prior Docker version.

As far as replicating, I think that will be difficult. The total number of files being untarred is 62810, and the errors start at the 15,212th file (!).

I tried with {"storage-driver":"aufs"} as recommended. It took a very long time to restart. And it appears to have erased all of my images' layers. But it did solve the problem.

What are the tradeoffs of using aufs vs the overlay filesystem? Should I stay with this or use until the problem is repaired?

[samoht]

Unfortunately I think you hit moby/moby#19647

Usually overlay2 is much more stable than aufs (hence we use it by default in Docker for Mac) but it seems that you have hit one of its few bugs. You should subscribe to the upstream ticket if you are interested about the resolution on that bug, meanwhile you should be able to continue working with aufs. Thanks again for your report!

[tedgoddard]

I've encountered this as well with Docker 17.12.0-ce-mac46. Applying "storage-driver" : "aufs" allowed the tar file to be extracted during build, but it's difficult to confirm this immediately as a fix since the failures are transient. (A few days of use should confirm, though.)

(Other failures I have seen recently, which are likely the same root cause, have been link failure with the curl library and malformed .zip files, all pointing at file system corruption.)

[docker-robott]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

[mfeblowitz]

/remove-lifecycle stale

[mfeblowitz]

/lifecycle frozen

[mg262]

When I try the workaround given above, namely adding {"storage-driver":"aufs"}, I find that Docker 2.0.0.3 on Mac will not start (there's an error about graphdriver). And indeed the docs suggest that you can't actually change storage driver on a Mac.

Has anyone got this to work specifically on a Mac? What v. of Docker?