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

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.