UID/GID on direct write to data volume
annybs opened this issue · comments
Line 169 in 720fd6a
This needs to be checked on a compatible Linux device. I don't have one to hand, so assigning @adamkdean to have a look, please!
This is mitigated by changes in v1.7.2 #116 which use container-oriented volume management instead of interacting directly with the disk. This makes it simpler to configure sudoless Docker access without encountering file access issues.
The original behaviour of direct volume read/write can be reinstated by setting DOCKER_DIRECT_RW=true in the environment. The volume access issues obtain if not accessing Docker as root, but may be preferable for some users (particularly as it doesn't require pulling alpine to facilitate data transfers).
This issue remains open for the moment as it would be nice to have unproblematic direct write.
This change has caused some issues on a testnet Stargate - when attempting to access the data volume, the process stalls.
It was previously set up using the original direct write method so there is potentially an issue with switching from one to the other.
I will investigate this to try to ensure that the container method works in all environments.
I've reflected since the patch earlier, and have decided that fixing permission issues are not a top priority, and so this issue should be closed.
The use of a transfer container is now the officially supported method, with no further work planned for direct read/write fixes.
However, the DOCKER_DIRECT_RW=true method will be retained to preserve backward compatibility for any environments that may be unable to use a transfer container. There seems to be no harm in keeping the option for now.