Permission denied when unlinking file from non-writable directory on osxfs mapped volume

Docker Desktop
1

Expected behavior

Root user should be able to unlink file from directory regardless of write permission.

Actual behavior

Container root user unable to unlink file from mapped volume directory lacking u+w permission.

Information

OS X: version 10.11.5 (build: 15F34)
Docker.app: version v1.11.1-beta12
Running diagnostic tests:
[OK] Moby booted
[OK] driver.amd64-linux
[OK] vmnetd
[OK] osxfs
[OK] db
[OK] slirp
[OK] menubar
[OK] environment
[OK] Docker
[OK] VT-x
Docker logs are being collected into /tmp/20160525-112521.tar.gz
Most specific failure is: No error was detected
Your unique id is: 6327870E-9476-448F-9191-E3C788405376
Please quote this in all correspondence.

Steps to reproduce the behavior

Start an Alpine container on Docker for Mac using a volume mount from a user home directory (substitute your username for “joe”):

$ docker run -it --rm -v /Users/joe:/root/dir alpine /bin/sh

Confirm that unlink behaves as expected outside the volume mount:

/ # cd /tmp
/tmp # mkdir -p a/b
/tmp # touch a/b/c
/tmp # chmod -w a/b
/tmp # rm -rfv a
removed ‘a/b/c’
removed directory: ‘a/b’
removed directory: ‘a’

Try the same unlink within the HFS+ volume mount – fails due to permissions:

/ # cd /root/dir
~/dir # mkdir -p a/b
~/dir # touch a/b/c
~/dir # chmod -w a/b
~/dir # rm -rfv a
rm: can’t remove ‘a/b/c’: Permission denied
rm: can’t remove ‘a/b’: Directory not empty
rm: can’t remove ‘a’: Directory not empty

The same sequence of operations works as expected if run using a VirtualBox docker-machine:

[root@9cef1b543d24 /]# cd /root/dir
[root@9cef1b543d24 dir]# mkdir -p a/b
[root@9cef1b543d24 dir]# touch a/b/c
[root@9cef1b543d24 dir]# chmod -w a/b
[root@9cef1b543d24 dir]# rm -rfv a
removed ‘a/b/c’
removed directory: ‘a/b’
removed directory: ‘a’

Work-around

Ensure all directories are writable before trying to unlink files from them:

chmod -R +w a

Making the directory user-writable solves the problem. This work-around may work for some. In my actual application, an RPM file is being unpacked (using rpm2cpio) and the permissions come from the RPM.