Introduction

If you have ever tried to run a .NET application on Linux and been greeted with "A fatal error occurred. The folder /usr/share/dotnet/host/fxr does not exist," you know how frustrating a cryptic path error can be. This error means the .NET runtime cannot locate its Framework Resolver component, and without it no .NET application can start. Understanding why this folder matters and what breaks it will let you fix the problem in minutes instead of hours.

What the FXR (Framework Resolver) Does

The host/fxr directory contains the Framework Resolver libraries. When you run any dotnet command, the host executable looks inside this folder to find the appropriate FXR library, which then determines which version of the .NET runtime to load for your application. Think of it as a dispatcher that reads your project's target framework and routes execution to the correct runtime version.

Without the FXR directory, the dotnet host has no way to resolve which runtime to use, so it fails immediately with the fatal error.

You can verify what the host sees by running:

dotnet --info

This prints the host version, installed SDKs, and runtimes. If the FXR folder is missing, this command itself will fail with the same error.

Common Causes

Several situations lead to a missing or broken host/fxr directory:

Incomplete or corrupted installation. A package manager interrupted during install, or a manual download that was only partially extracted, can leave the dotnet directory without the FXR subfolder.

Snap vs APT conflict on Ubuntu/Linux. Ubuntu ships a dotnet snap package, while Microsoft provides APT packages. If both are installed, the system may resolve dotnet to the snap version while the APT runtime files live in /usr/share/dotnet. The snap version uses a different directory structure, so the expected path does not exist.

Multiple SDK installs in different locations. Installing .NET through a script (like dotnet-install.sh) places files in ~/.dotnet, while package-manager installs use /usr/share/dotnet or /usr/lib/dotnet. If the DOTNET_ROOT environment variable points to the wrong location, the host looks in a directory where no FXR folder exists.

System cleanup or uninstall side effects. Running apt autoremove or manually deleting packages can remove the runtime while leaving the SDK or host binary behind.

Diagnosing the Problem

Start by finding where your dotnet binary actually lives and what it can see:

1which dotnet
2ls -la /usr/share/dotnet/host/
3dotnet --list-sdks
4dotnet --list-runtimes

If which dotnet points to /snap/bin/dotnet but your SDKs are in /usr/share/dotnet, you have found the conflict. If the host/ directory exists but fxr/ is empty or missing, the runtime installation is incomplete.

Fixes

Fix 1 -- Remove the Snap Version and Reinstall via APT

This is the most common fix on Ubuntu:

sudo snap remove dotnet-sdk
sudo apt remove --purge dotnet* aspnetcore*
sudo apt install dotnet-sdk-8.0

After reinstalling, verify the FXR folder exists:

ls /usr/share/dotnet/host/fxr/

Fix 2 -- Set DOTNET_ROOT Correctly

If you installed .NET with the install script to a custom location, tell the system where to find it:

export DOTNET_ROOT=$HOME/.dotnet
export PATH=$DOTNET_ROOT:$PATH

Add these lines to your ~/.bashrc or ~/.zshrc so they persist across sessions.

Fix 3 -- Create a Symlink

When the runtime files exist in one location but the host binary expects another, a symlink bridges the gap:

sudo ln -s /usr/share/dotnet/host/fxr /usr/lib/dotnet/host/fxr

Adjust the source and target paths based on where your files actually live. Use find / -name "fxr" -type d 2>/dev/null to locate existing FXR directories.

Fix 4 -- Reinstall the Runtime Directly

If only the runtime is missing while the SDK is intact, install just the runtime:

sudo apt install dotnet-runtime-8.0

Or use the official install script:

curl -sSL https://dot.net/v1/dotnet-install.sh | bash /dev/stdin --runtime dotnet --channel 8.0

Verifying the Fix

After applying any fix, confirm everything works:

dotnet --info
dotnet --list-sdks
dotnet --list-runtimes

You should see your installed SDK and runtime versions listed without errors. The host/fxr directory should contain version-numbered subfolders matching your installed runtimes.

Common Pitfalls

• Installing .NET through both snap and APT simultaneously, which creates conflicting binary paths
• Forgetting to set DOTNET_ROOT after using the manual install script, so the host searches the wrong directory
• Running sudo apt autoremove after uninstalling an older SDK version, which can pull the shared runtime out from under newer SDKs
• Creating symlinks without checking where the real FXR binaries live first, resulting in broken links
• Editing PATH to include a dotnet directory that has the CLI but not the runtime components

Summary

• The host/fxr directory contains the Framework Resolver, which the .NET host needs to select the correct runtime version
• The most common cause on Linux is a conflict between snap and APT installations of .NET
• Use which dotnet and dotnet --info to diagnose where the system is looking for .NET components
• Set DOTNET_ROOT to match your actual installation directory when using custom install locations
• After fixing, always verify with dotnet --list-sdks and dotnet --list-runtimes to confirm the runtime is properly discovered