SpecialFolder.ApplicationData is blank inside of an Alpine docker container

[rcdailey]

I'm doing this in a .NET 6.0 C# console CLI application:

Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);

This returns a blank string when I run inside of a docker container created with FROM alpine. Specifically:

FROM alpine

ENV HOME=/config
ENV DOTNET_BUNDLE_EXTRACT_BASE_DIR=/tmp/.net
ENV CONFIG_FILE="/config/recyclarr.yml"
ENV CRON_SCHEDULE_SONARR="@daily"
ENV CRON_SCHEDULE_RADARR="@daily"

RUN apk add --no-cache libstdc++ icu

COPY --chmod=544 --from=build /build/recyclarr /usr/local/bin
COPY --chmod=544 entrypoint.sh /

VOLUME /config

ENTRYPOINT ["/entrypoint.sh"]

I build my executable using this command:

dotnet publish src\Recyclarr `
    --output publish\linux-musl-x64 `
    --configuration Release `
    --runtime linux-musl-x64 `
    --self-contained true

Relevant msbuild settings:

  <PropertyGroup>
    <PublishSingleFile>true</PublishSingleFile>
    <IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>
    <PublishReadyToRunComposite>true</PublishReadyToRunComposite>
    <PublishReadyToRunShowWarnings>true</PublishReadyToRunShowWarnings>
    <EnableCompressionInSingleFile>true</EnableCompressionInSingleFile>
  </PropertyGroup>

I verified in entrypoint.sh that $HOME is set and returns the expected value. I'm not sure if this is an issue on my side or if .NET just doesn't support this environment. I have spent all day googling but I've had no luck. Can anyone help me figure out how to get this working?

[Clockwork-Muse]

Looks like you may just need to set some environment variables, probably XDG_DATA_HOME or similar.

• this issue
• this blog post

Additionally, although this wouldn't necessarily set the variables by default, you should be creating and using a non-root user in your containers.

[Clockwork-Muse]

I wouldn't expect the sdk images to, no, because that's a "build application" image, not a "run application" image (you can use it for that, but it's a larger image than you need).

That aside, it looks like there isn't a non-root user in those containers, so the variables aren't going to be set either.

[rcdailey]

Setting XDG_DATA_HOME didn't work, but setting XDG_CONFIG_HOME did. Thank you so much for the hint!

I'll admit I don't fully understand these environment variables. Linux is a bit of a mysterious beast. I do think that, if possible, dotnet runtime should do more to abstract these nitty-gritty details away from me. For example I find it weird that even though $HOME is set, $XDG_CONFIG_HOME is still required, According to the XDG spec page I read, it should fall back to $HOME. I'm not sure if that's a linux responsibility or an application one. But I don't think it's unreasonable for dotnet runtime to use $HOME (which I explicitly set, even before I started this discussion thread).

[rcdailey]

For the record, this is the specification I read and it states:

$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

[Clockwork-Muse]

... then you should probably open this as an issue.

[rcdailey]

Issue opened: #69449