Permissions error in directories used by Docker and application I am developing

Question

I have run a docker container mysql from my own application development on C#, and configured data persistence to this path:

C:\ProgramData\Persistence\data\mysql

When i start everything goes well because there is no data (first run)

Once I start developing (create database... etc..) and for some reason I restart the PC and open again docker-desktop and starting the container, it no longer works...

I have managed to determine that the problem is the directory permissions, the read-only attribute (I'm still investigating why...):

I have investigated, and I have tried to solve it with the following methods:

from CMD: icacls "C:\ProgramData\Persistence" /grant Everyone:(OI)(CI)F /T

form PowerShell: Get-ChildItem -Path "C:\ProgramData\Persistence" -Recurse | ForEach-Object { $_.Attributes -= "ReadOnly" }

These commands were executed with my personal user having active administrator privileges and running CMD and Powershell with administrator privileges.

but the problem persists... and I can't find a programmatic way or in YML file to solve it, which is my only interest...

Log Content:

2024-04-15 16:31:39+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.3.0-1.el8 started.
2024-04-15 16:31:39+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2024-04-15 16:31:39+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.3.0-1.el8 started.
ln: failed to create symbolic link '/var/lib/mysql/mysql.sock': Permission denied
2024-04-15T16:31:39.941325Z 0 [System] [MY-015015] [Server] MySQL Server - start.
2024-04-15T16:31:40.118455Z 0 [Warning] [MY-010915] [Server] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release.
2024-04-15T16:31:40.123899Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.3.0) starting as process 1
2024-04-15T16:31:40.127250Z 0 [Warning] [MY-010159] [Server] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
mysqld: File './binlog.index' not found (OS errno 13 - Permission denied)
2024-04-15T16:31:40.128854Z 0 [ERROR] [MY-010119] [Server] Aborting
2024-04-15T16:31:40.129566Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.3.0)  MySQL Community Server - GPL.
2024-04-15T16:31:40.129575Z 0 [System] [MY-015016] [Server] MySQL Server - end.

I have verified that changing the shape attribute manually solves it, but it is not what I am looking for.

Update 1

i have try some changes on my YML file and docker file:

    volumes:
      - ./data/mysql:/var/lib/mysql:rw
      - ./log/mysql:/var/log/mysql:rw

and

RUN mkdir -p /var/log/mysql
RUN chmod -R 0755 /var/lib/mysql /var/log/mysql /etc/mysql

My expectation is that something like this will work.

Update 2

I have been evaluating and for some reason the problem is related to how docker works and the directory structure... and the interaction with third-party software...

The problem occurs in the following way:

1. once docker is up for the first time with the containers and the mysql content everything goes well...
2. If by some chance another third-party software or tool uses or enters the path where the persistence data is located, these.
3. When you restart the system it stops working correctly. as if between the third party application and the restart something happened with the permissions... it sounds stupid but it seems that something happens at that moment.

this my PS Scrript

I would like to think that there is a way to solve the problem natively from the yml with which the structure and the docker/container environment are built, but so far I have not solved it... therefore I resort to working around the problem and every time this occurs, you need to manually run this script in powershell:

# Define the path to the directory
$directoryPath = "C:\ProgramData\Persistence"

# Get the current ACL (Access Control List) for the directory
$acl = Get-Acl $directoryPath

# Define the permission rule to grant full control to everyone
$permission = "Everyone", "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow"

# Create a new access rule
$accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule $permission

# Add the access rule to the ACL
$acl.AddAccessRule($accessRule)

# Set the ACL for the directory
Set-Acl -Path $directoryPath -AclObject $acl

# Check if the permissions were applied successfully
Get-Acl $directoryPath

So:

Although this script solves the problem once started/detected manually, it is not the way I expected to solve it, I am still looking for an alternative that prevents this situation.

Answer 1

It looks like you're using Docker Desktop. This runs a VM which in turn hosts your containers. The VM runs Linux. The docker images you load are Linux binaries compiled for Linux and X86_64.

However, you hand it a NTFS filesystem! And not only that, there's a translation layer in there, translating from NTFS to something that the Linux VM (WSL2) can understand. WSL2 is not meant for server and multiuser deployments, but development, so some things break.

The solution to your problem is to use Docker volumes. They are faster, less fragile, and in addition behave in the way the software you're running expects things to work.

Regarding the read only attribute, please read this.