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

Docker Desktop for Windows
, ,
1

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)

image
image957×258 29.1 KB

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…

image
image847×267 25.8 KB

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

enter image description here

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.