Why log paths differ between installer types
The same version of the same application logs somewhere else depending on how it was installed. What MSI, MSIX, Store, pkg, Mac App Store, deb, Snap, Flatpak and AppImage each do to the path.
The same application, at the same version, on two machines, writing its log to two different paths, is not a bug and not a misconfiguration. It is how it was installed. Packaging decides whether the application gets the filesystem as it is, or a redirected view of it, and a redirected view moves every path the application uses without the application knowing.
This is why the catalogue tags every path with an installer type rather than listing one path per application.
Windows: MSI, EXE, MSIX and portable
| Type | What it does to the path |
|---|---|
| msi | Machine-wide install. Logs usually per-user under AppData, or machine-wide under ProgramData when a service is involved |
| exe | Whatever the vendor’s own installer decides. Frequently per-user, and frequently a different tree from the same vendor’s MSI |
| msix | Store or packaged install. Everything is redirected into %LOCALAPPDATA%\Packages\<package-family>\ |
| portable | No install at all. Logs usually land beside the executable, wherever that was unzipped |
MSIX is the one that surprises people. A packaged application that writes to %APPDATA%\Vendor\App in its own code has that call redirected, transparently, into its package container. The application’s documentation is not wrong; it is describing the path the application asked for, not the path Windows gave it.
Microsoft Teams shows both eras at once. Classic Teams was an EXE install and wrote %APPDATA%\Microsoft\Teams\logs.txt. The current Teams ships as a Store package and writes under %LOCALAPPDATA%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\. Same vendor, same product name, nothing in common between the paths.
A second split runs alongside packaging: per-user against per-machine. Docker Desktop writes %LOCALAPPDATA%\Docker\log.txt for the desktop application and %PROGRAMDATA%\DockerDesktop\service.txt for the service that runs regardless of who is signed in. Either can be the one with your answer in it, depending on what failed.
macOS: pkg, dmg and the App Store
A pkg installer and a dmg you drag to Applications usually produce the same paths: the application is unsandboxed and writes to ~/Library/Logs or ~/Library/Application Support like any other Mac application.
The Mac App Store build is different, because sandboxing is mandatory there. Every write under ~/Library is redirected into a container:
~/Library/Application Support/App/ # direct download ~/Library/Containers/com.vendor.app/Data/Library/Application Support/App/ # App Store
1Password logs to ~/Library/Containers/com.1password.1password/Data/Library/Logs/1Password/. Note the shape: the sandbox prefix, then the path the application actually asked for. Once you can see that seam, you can translate any unsandboxed path into its sandboxed equivalent. More on the containers themselves in how to find application log files on macOS.
Linux: deb, rpm, Snap, Flatpak, AppImage
Distribution packages (deb, rpm) follow the distribution’s layout, which is why the same service logs to different places on Debian and on Red Hat: PostgreSQL writes /var/log/postgresql/ on one and /var/lib/pgsql/<version>/data/log/ on the other. Nothing was redirected there; the packagers simply chose differently.
Snap and Flatpak do redirect. Both give the application a private home directory, so its perfectly ordinary XDG paths land inside a container:
~/.config/obs-studio/logs/ # deb or rpm ~/snap/obs-studio/current/.config/obs-studio/logs/ # snap ~/.var/app/com.obsproject.Studio/config/obs-studio/logs/ # flatpak
Those are all OBS Studio, same version, three package formats. AppImage is the exception: it is unconfined, so it uses the plain XDG paths in the first line.
Working out which one you have
- Windows.
Get-AppxPackage *teams*returns something? It is MSIX, and the path is under%LOCALAPPDATA%\Packages\. Otherwise check Apps & features, or look for the install directory underProgram Filesversus%LOCALAPPDATA%\Programs\, which is the usual sign of a per-user EXE install. - macOS. An App Store build has a
_MASReceiptfolder inside the app bundle, and a container under~/Library/Containers/named for its bundle identifier. - Linux.
snap list,flatpak list, then your package manager. If none of them know about it, it is an AppImage or a tarball.
Then search the catalogue: every path is tagged with the installer types it was verified against, so you can match the one in front of you rather than trying all of them.