Viewing logs of the Traekif-Manager-Agent in the binary installation

[shrimphorticulturist]

Is there any log availables of the TMA service binary ?

In fact, my installation of the binary TMA on a second LXC instance works (seen in green in Traefik-Manager) but makes errors :

Maybe it's a permission issue on yml files but without logs it's hard to investigate.

Thx.

[yhay81]

Yes. The binary installation runs TMA as a systemd service, so its stdout/stderr is in the system journal rather than a separate log file.

Use:

sudo systemctl status tma --no-pager -l
sudo journalctl -u tma -n 200 --no-pager
sudo journalctl -u tma -f

The last command follows new messages while you reproduce the error. This is the unit name used by the documented binary install: https://github.com/chr0nzz/traefik-manager/blob/e9ad656a3e27c9f0429b96de0c7e172753746ccd/docs/agent.md#install-via-binary

For the suspected YAML permission issue, also inspect the exact unit configuration and path permissions:

sudo systemctl cat tma
sudo namei -l /path/from/CONFIG_PATH

The service needs access not only to each .yml file, but also execute/traverse permission on every parent directory and write permission on the config directory when it creates backups or replaces files. After changing the unit or environment, run:

sudo systemctl daemon-reload
sudo systemctl restart tma

If journalctl -u tma says there is no such unit, run systemctl list-unit-files | grep -i tma and substitute the actual unit name created by your installer.

[shrimphorticulturist]

Hi, thx for the answer.

The only lines in journactl are those even if i reproduce the error :

Jul 24 13:09:24 rev-prox-ext systemd[1]: Stopped tma.service - Traefik Manager Agent.
Jul 24 13:09:24 rev-prox-ext systemd[1]: Started tma.service - Traefik Manager Agent.
Jul 24 13:09:24 rev-prox-ext tma[4977]: 2026/07/24 13:09:24 TMA v1.7.3 listening on :8090 (traefik=https://urlobfuscated/, insecure-tls=false)

On sur Traefik-Manager instance, there's a specific traefik-manager user who own the yaml files or conf.d folder.
On TMA, no specific users, what kind of permission should i grant ?

[yhay81]

The ownership on the central Traefik Manager host does not carry over to the remote TMA host. TMA only needs access to the paths on the LXC where tma.service runs.

First, check the effective account:

systemctl show tma -p User -p Group
pid=$(systemctl show tma -p MainPID --value)
ps -o user=,group=,cmd= -p "$pid"

The documented binary unit has no User= line, so an empty User value means the system service runs as root. If that is your setup, it already has filesystem permission and changing modes is unlikely to fix this. The first thing I would verify is the configured path: /app/config is the container-oriented example, not usually the native Traefik path. Point TMA at the real path on this LXC, for example:

[Service]
Environment=CONFIG_DIR=/etc/traefik/conf.d
Environment=BACKUP_DIR=/var/lib/traefik-manager/backups
# Or, for one file:
# Environment=CONFIG_PATH=/etc/traefik/dynamic.yml

Then run systemctl daemon-reload && systemctl restart tma. You can safely show the non-secret path/account lines with:

systemctl cat tma | grep -E '^(User|Group)=|Environment=(CONFIG_PATH|CONFIG_DIR|CONFIG_PATHS|BACKUP_DIR)='
namei -l /etc/traefik/conf.d

Please do not paste the complete unit because it contains TMA_API_KEY.

If you intentionally run TMA as a dedicated user, give that user group-based access (not chmod 777): it needs read/write on the YAML files, traverse/write on the containing directory so it can create or atomically replace files, and write access to BACKUP_DIR. For example, add both the Traefik and TMA users to a shared group, set the directory group and setgid bit, then configure User=tma, Group=traefik-config, and UMask=0007 in the service. Verify with:

sudo -u tma test -r /etc/traefik/conf.d/example.yml
sudo -u tma test -w /etc/traefik/conf.d/example.yml
sudo -u tma test -w /etc/traefik/conf.d
sudo -u tma test -w /var/lib/traefik-manager/backups

Given the unit shown in the project docs, though, I would check the actual CONFIG_PATH/CONFIG_DIR before changing any permissions.

[shrimphorticulturist]

I got no TMA account :

User=
Group=
root     root     /usr/local/bin/tma

The service constants :

Environment=CONFIG_PATH=/etc/traefik
Environment=CONFIG_DIR=/etc/traefik/conf.d
f: /etc/traefik/conf.d
drwxr-xr-x root    root    /
drwxr-xr-x root    root    etc
drwxr-xr-x traefik traefik traefik
drwxr-xr-x traefik traefik conf.d

I made some progress, i assume the errors were in CONFIG_PATH and CONFG_DIR.
Now i have this message :

It come from the basic_auth middleware i have on the api.
I looked in the documentation I dindn't see any possibility to configure a user and password just like the traefik-manager host.

[chr0nzz]

That 401 is the whole answer, and it's good news - it rules out permissions and TLS entirely. TMA reached your Traefik fine; Traefik's API replied 401 Unauthorized. So this isn't a yml permission issue at all (the binary agent runs as root anyway, and it never got that far).

What's happening: TRAEFIK_API_URL is pointed at a Traefik endpoint that's behind authentication - a dashboard/API route with basicAuth, forwardAuth, or similar in front of it (your earlier startup line showed https://.../, a public URL). TMA has no way to send Traefik dashboard credentials - the internal API isn't meant to be authenticated - so every call comes back 401, and the Manager shows "Could not load routes."

The fix is to point the agent at Traefik's internal, unauthenticated API, not the public URL. On the same LXC as Traefik that's normally:

TRAEFIK_API_URL=http://localhost:8080

which needs Traefik's admin API on :8080 (api.insecure: true, bound to localhost - it stays local-only on that box, so it's off the internet). Edit the Environment=TRAEFIK_API_URL=... line in /etc/systemd/system/tma.service, then:

sudo systemctl daemon-reload
sudo systemctl restart tma

You can confirm which endpoint is which by curling from the LXC:

curl -si http://localhost:8080/api/http/routers | head -1    # want: HTTP/1.1 200 OK
curl -si https://your-public-url/api/http/routers | head -1  # this is the one returning 401

Point TMA at whichever returns 200. That's the same internal API the Host Manager uses, which is why it works there but not through the public URL.

One thing that's on me: the agent only returns these errors to the Manager UI and doesn't write them to its own journal, which is why journalctl was a dead end here - a 401 should have been obvious from the start. The next release adds an optional TMA_DEBUG=true that logs each failed Traefik call (status and URL) to the journal, so this is visible next time. Thanks for the detailed reproduction, and thanks @yhay81 for jumping in.

[chr0nzz]

Quick follow-up: rather than only pointing the agent at an unauthenticated API, the next release lets it authenticate to a protected Traefik API directly. Set TRAEFIK_API_USER and TRAEFIK_API_PASSWORD on the agent and it'll send basic auth on every Traefik API call, so you can keep your existing setup as-is. The installer will also ask for it when you tell it the API is behind basic auth. Shipping alongside the TMA_DEBUG logging in the same release. Thanks again for the detailed report - it turned into two improvements.

[shrimphorticulturist]

Thx again and sorry to add you some more work ;-)
My Traefik API is on port 6081. But if I don't use the FQDN to access it, Traefik return à 404 error.

Maybe it's because of my traefik.yml configuration :

  traefik:
    address: :6081
    http:
      middlewares:
        - auth@file
    forwardedHeaders:
      trustedIPs: 10.0.10.0/24
      insecure: false
    proxyProtocol:
      trustedIPs: 10.0.10.0/24
      insecure: false

[yhay81]

The 404 is consistent with a Host rule mismatch, not with the port being wrong. Your secure api@internal router likely matches the FQDN, so a request whose Host is localhost falls through to Traefik's default 404.

You can prove that without changing the config:

curl -si -H 'Host: your-api-fqdn.example' \
  http://127.0.0.1:6081/api/http/routers | head -1

If that changes the result from 404 to 401, the router matched and only Basic Auth remains. Your auth@file middleware on the entrypoint explains the 401.

For the upcoming version, keep the FQDN in TRAEFIK_API_URL and set the new TRAEFIK_API_USER / TRAEFIK_API_PASSWORD. If you want the request to stay inside this LXC while still satisfying the Host rule, map that FQDN to 127.0.0.1 in /etc/hosts; using the FQDN in the URL also preserves TLS hostname validation.

The other safe design is a separate loopback-only API router/entrypoint without auth@file, bound to 127.0.0.1, for TMA. Do not expose an unauthenticated api@internal entrypoint on the LAN. Given that credential support is already coming, the FQDN + Basic Auth approach is the smallest change.

[shrimphorticulturist]

I get a 404 error with this command.

Anyway, I will wait for the implementation of TRAEFIK_API_USER / TRAEFIK_API_PASSWORD to keep the API securized.

Greetings

[chr0nzz]

v1.8.0 is out, and it has two things aimed straight at what you hit here.

You can now keep your authenticated Traefik API and give the agent credentials. Set TRAEFIK_API_USER and TRAEFIK_API_PASSWORD on the agent and it sends HTTP Basic Auth on every Traefik API call, so the 401 goes away without having to expose an unauthenticated endpoint. (Pointing the agent at the internal http://localhost:8080 API still works too, if you'd rather do that instead.)

TMA_DEBUG=true makes the agent log each failed Traefik call - the URL and the returned status - to the journal, so a 401 or a connection error shows up in journalctl -u tma instead of only in the Manager UI.

To upgrade your binary install, grab the new agent binary:

sudo systemctl stop tma
sudo curl -fsSL https://github.com/chr0nzz/traefik-manager/releases/latest/download/tma-linux-amd64 -o /usr/local/bin/tma
sudo chmod +x /usr/local/bin/tma

(swap amd64 for arm64 or armv7 if that matches your box)

Then add the credentials to /etc/systemd/system/tma.service under [Service]:

Environment=TRAEFIK_API_USER=your-username
Environment=TRAEFIK_API_PASSWORD=your-password
Environment=TMA_DEBUG=true

and reload:

sudo systemctl daemon-reload
sudo systemctl restart tma

The startup line now reports whether auth and debug are active, so you can confirm it picked them up:

sudo journalctl -u tma -n 20 --no-pager
# ...listening on :8090 (traefik=..., traefik-auth=true, debug=true)

Give it a try and let me know how it goes. Thanks again for the detailed report - it's what drove both of these.

[shrimphorticulturist]

Hi,

Okay, I made it, TMA is correctly connected to Traefik API with TLS and BasicAuth. Thanks for the functionality.

But it can only see "Certs", "Logs" and "Services" but "Routes" and "Middlewares" are count to 0 despite it seen 8 routes on top charts.

Maybe it's a permission issue on /etc/traefik/conf.d folder ?
drwxr-xr-x 2 traefik traefik 13 Jul 26 11:16 conf.d

Nothing on service journal.

[chr0nzz]

That's not a permission problem either, and it's the same root cause as the 401 was not: the agent runs as root, so it reads /etc/traefik/conf.d regardless of the traefik:traefik ownership.

What's happening: the Routes and Middlewares tabs are built from the dynamic-config files the agent reads at CONFIG_PATH, while Services, Certs, Logs, and the top-of-page counts come from the Traefik API and other paths. Your 8 routes are file-provider (@file), and the agent deliberately does not re-list file-provider routers from the API (they are meant to show from the files themselves). So if CONFIG_PATH is not pointed at the directory holding your router .yml files, Routes and Middlewares come back empty while everything API-based still works.

Check it:

sudo systemctl cat tma | grep CONFIG_PATH

It should be your dynamic-config directory:

Environment=CONFIG_PATH=/etc/traefik/conf.d

Then:

sudo systemctl daemon-reload
sudo systemctl restart tma

One caveat: the agent reads .yml / .yaml files directly in that folder, not recursively, so if your routers live in subfolders point it at the right level. If it is already set to /etc/traefik/conf.d, tell me and we will look closer.