Can not use WithDataBindMount with Postgres

[BenCoden]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When I add WithDataBindMount I get the following error.

Expected Behavior

The container would be provided with the proper permissions.

Steps To Reproduce

Create a New Aspire app with.Net 9
Add Nuget Aspire.Hosting.PostgreSQL v9.0.0
Add this code block to AppHost Program.cs
var postgres = builder.AddPostgres("postgres") .WithDataBindMount("C:\\PostgreSQL\\Data", false);
Run the App
Check the postgres log

Exceptions (if any)

No response

.NET Version info

.NET SDK:
Version: 9.0.100
Commit: 59db016f11
Workload version: 9.0.100-manifests.4a280210
MSBuild version: 17.12.7+5b8665660

Runtime Environment:
OS Name: Windows
OS Version: 10.0.26100
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\9.0.100\

.NET workloads installed:
[aspire]
Installation Source: VS 17.12.35521.163
Manifest Version: 8.2.2/8.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
Install Type: Msi

[maui-windows]
Installation Source: VS 17.12.35521.163
Manifest Version: 9.0.0/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maui\9.0.0\WorkloadManifest.json
Install Type: Msi

[maccatalyst]
Installation Source: VS 17.12.35521.163
Manifest Version: 18.1.9163/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maccatalyst\18.1.9163\WorkloadManifest.json
Install Type: Msi

[ios]
Installation Source: VS 17.12.35521.163
Manifest Version: 18.1.9163/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.ios\18.1.9163\WorkloadManifest.json
Install Type: Msi

[android]
Installation Source: VS 17.12.35521.163
Manifest Version: 35.0.7/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.android\35.0.7\WorkloadManifest.json
Install Type: Msi

Configured to use loose manifests when installing new manifests.

Host:
Version: 9.0.0
Architecture: x64
Commit: 9d5a6a9aa4

.NET SDKs installed:
9.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

Anything else?

No response

[DamianEdwards]

What are you proposing as the fix for this? Are you expecting the WithDataBindMount would check the permissions and correct them if they're wrong?

@karolz-ms and @danegsta for their thoughts.

[DamianEdwards]

@BenCoden are you running Docker Desktop on Windows? Or are you running a Docker alternative or a more complex Docker setup, e.g. Docker engine in WSL?

[danegsta]

This is almost certainly an issue with how bind mount permissions get exposed/set by the container runtime; we've seen similar issues reported several times. The postgres container runs as a specific linux user (postgres with 999 for the userid and groupid last I checked), but bind mounts from Windows are mounted into the container as the root user and may not have the correct permissions to allow non-root users to modify them. When running on linux (native or WSL), the bind mount inherits the permissions/ownership from the host filesystem (which is its own can of worms).

Volume mounts are one alternative option to bind mounts that "just work" to persist data, with the caveat that the data isn't directly accessible from the host machine anymore. To make bind mounts just work, I think we'd need to introduce a two stage startup for database containers. Instead of starting the standard container entrypoint directly, we need to make sure we chmod/chown the data bind mount to the correct permissions before the database starts. This could be via a custom entrypoint setup script or even doing a two-stage launch for containers where we run a placeholder entrypoint, do any custom configuration via docker/podman exec, and then explicitly launch the original entrypoint.

[karolz-ms]

For database containers in particular, using a volume mount for the data makes sense and bypasses the permission issue. @BenCoden have you considered a volume mount?

[BenCoden]

I did end up using a volume mount.

@BenCoden are you running Docker Desktop on Windows? Or are you running a Docker alternative or a more complex Docker setup, e.g. Docker engine in WSL?

I am using WSL

[BenCoden]

Honestly, data mount was the first thing I encountered when looking into persisting the data. If volume mount is better practice for a db, I have no issues using it.

[DamianEdwards]

@BenCoden

I am using WSL

To further clarify, are you using Docker Desktop on Windows configured to use WSL2? Or are you running Docker engine inside WSL manually?

[dotnet-policy-service]

This submission has been automatically marked as stale because it has been marked as requiring author action but has not had any activity for 14 days.
It will be closed if no further activity occurs within 7 days of this comment.