Troubleshooting and FAQ

Processes appear as "Not Identified"

Little Snitch identifies a process by observing how it starts. Processes that were already running when the daemon started can therefore not always be identified.

Right after installation, this is expected. Reboot the computer so that the daemon runs before your applications start.
Executable scripts (files with #! in the first line) can only be attributed correctly when the daemon is already running when the script starts. Real binaries can usually be identified while already running.
If executables on Btrfs are affected, make sure you run a current version of Little Snitch; early releases had bugs in these areas.

Little Snitch does not start, or the eBPF program is rejected

If eBPF programs fail to load, the symtom is usually a restart loop. The littlesnitch daemon aborts with an error and systemd restarts it immediately. This puts a high load on the CPU and you'll usually notice it as the fans start blowing.

Check the requirements from Installation and Requirements:

Kernel 6.12 or newer: uname -r. There is also no guarantee for bleeding edge new kernels.
BTF support: the directory /sys/kernel/btf/ must exist.
Function tracer support: the kernel must be built with CONFIG_FUNCTION_TRACER=y.
Hardened kernels that remove the bpf_probe_read_kernel() helper are not supported.

Also note: on systems with less than 16 GB of memory, the eBPF programs are loaded sequentially, which makes startup take longer. On some kernel versions Little Snitch needs additional startup time as well. Give it a moment before concluding it failed.

If the daemon logs that a requested security feature could not be activated, it aborts on purpose rather than silently continuing. The command line options --no_capability_sandbox and --no_file_sandbox allow you to explicitly disable the affected feature if your environment does not support it.

Connections show IP addresses instead of names, or wrong names

Name detection depends on Little Snitch seeing your DNS lookups. DNS caches and DNS encryption hide them. See the section on DNS visibility in Advanced Topics, in particular:

Remove the resolve keyword from the hosts: line in /etc/nsswitch.conf.
Disable DNS over HTTPS inside browsers and enable encrypted DNS in systemd-resolved instead.

Occasional wrong names are rare, but inherent to the technique: several names can point to the same IP address, and Little Snitch shows the most recently looked up one.

I locked myself out with a deny default

If you changed the default action in main.toml to deny and lost network access, you can recover with local access to the machine: remove or fix your override file under /var/lib/littlesnitch/override/config/ and restart the daemon:

sudo systemctl restart littlesnitch

If you administer the machine remotely, always test a deny default with a fallback at hand, for example a scheduled job that stops Little Snitch unless you cancel it.

The wrong process is shown as parent, or a helper shows up where the app should be

The parent detection is heuristic and configurable. If "system-helper via your-app" is shown but you want your-app as the top level entry, add the helper to the app manager section of executables.toml. Copy the file to the override directory first; see Advanced Configuration.

An application appears as a new entry after every update

The executable's path probably contains a version number or a changing mount point identifier that the shipped normalization patterns do not cover. Add a pattern to executables.toml in the override directory. See Advanced Topics for how normalization works, and please consider sharing patterns that might help others.

Can I import my rules from Little Snitch on macOS?

No. The .lsbackup (rule and configuration backup) and .lsrules (remote rule groups) formats are not compatible with the Linux version.

Where do I get help?

The issue tracker lives in the GitHub repository.
For everything else, contact Objective Development support.