But the question is, can I also use the nuget package on linux by changing how the docfx.exe command is run by the nuget package? Or is this only possible by actually fixing this in docfx.console?

Create script docfx that runs docfx.exe using Mono, e.g., like this (assuming docfx.exe is located in /opt/docfx/docfx.exe):

echo '#!/bin/bash\nmono /opt/docfx/docfx.exe $@' > /usr/bin/docfx && chmod +x /usr/bin/docfx

Then, pass MSBuild parameter BuildDocToolPath with path to that script, e.g., like this:

dotnet publish -c Release -o out -p:BuildDocToolPath=/usr/bin/docfx

docfx.console will than use this path to execute DocFX. I think the property BuildDocToolPath isn't documented anywhere, but you can see it in source code.

If you specify an assembly in the metadata configuration, DocFx will look for the XML documentation in the same directory (source). The problem, however, is that when you include a NuGet reference, that XML documentation isn't included in your project's bin folder, even if it's included in the NuGet package. As a result, while DocFx is able to identify the structure, it is not able to identify the documentation.

TL;DR: To resolve this, you can configure msbuild to copy the XML documentation to the bin folder, ensuring DocFx has access to it (example). Details below.

Background

When you reference a NuGet package, by default, the package is downloaded, unzipped, and cached in the following location:

%UserProfile%\.nuget\packages\{Package}\{Version}\

Note: This is obviously a Windows directory; the location will vary by operating system.

This will include e.g.,

\lib\net6.0\{AssemblyName}.dll
\lib\net6.0\{AssemblyName}.xml

When you build your .NET project, the {AssemblyName}.dll is copied to your project's bin directory, but not the {AssemblyName}.xml. Since you've instructed DocFx to look in your project's bin folder, it is therefore unable to collect the documentation.

Naïve Workaround

The obvious workaround would be to simply source the metadata from the NuGet cache directly. This can easily be accomplished by adjusting the docfx.json configuration as follows:

{
  "metadata": [
    {
      "src": [
        {
          "files": "bin/Release/net6.0/{AssemblyName}.dll",
          "src": "C:\\Users\\{User}\\.nuget\\packages\\{Package}\\{Version}\\lib\\net6.0\\"
        }
      ],
      "dest": "api/{AssemblyName}"
    }
  ]
  …
}

This works, of course. But it's also a really brittle solution that isn't feasible for production code. Most notably, DocFx doesn't recognize the %UserProfile% alias, and so the {User} must be hardcoded into the configuration. Not only will this be different for each developer, but it will also be different on the build server. And that's not even factoring in non-Windows environments.

A better solution

Given this, the better solution is to instruct msbuild to copy the XML documentation to the bin folder along with the assembly. Fortunately, that's pretty easy, as discussed in How to include XML Documentation from Nuget Package in csproj build output. In your csproj file, simply add the following:

<Project>
  <Target Name="_ResolveCopyLocalNuGetPkgXmls" AfterTargets="ResolveReferences">
    <ItemGroup>
      <ReferenceCopyLocalPaths Include="@(ReferenceCopyLocalPaths->'%(RootDir)%(Directory)%(Filename).xml')"
      Condition="'%(ReferenceCopyLocalPaths.NuGetPackageId)'!='' and Exists('%(RootDir)%(Directory)%(Filename).xml')" />
    </ItemGroup>
  </Target>
</Project>

The main advantage of this approach is that it relies on msbuild variable to abstract the location of the NuGet cache, the package name, the version number, and the destination folder. As a result, this should work on any machine or operating system.

With this in place, DocFx will successfully find the XML documentation alongside the assembly, and include it in the generated yml metadata.