[bug]: Persistent "unknown option: tor.cookiepath" Error in LND v0.18.5-beta Despite Correct Config & Permissions (Password Auth Works Fine)

[vicortar]

Environment:
LND Version: 0.18.5-beta (commit=v0.18.5-beta, build=production)
Bitcoin Core Version: 29.0.0 (release build)
Tor Version: [Please insert your Tor version here, e.g., 0.4.8.11]
OS: Raspberry Pi OS [ Bookworm (Debian 12)] on Raspberry Pi 5
Go Version: [ go version go1.21.5 linux/arm64]
LND Running User: lnduser
LND Running Group: lndgroup
Tor Running Group: debian-tor
Issue Description:
I am encountering a persistent and perplexing issue where LND v0.18.5-beta fails to start when configured to use Tor Control Port authentication via the tor.cookiepath option. LND consistently exits immediately upon startup, logging the error: failed to load config: /home/lnduser/.lnd/lnd.conf:59: unknown option: tor.cookiepath (line number may vary slightly).
This occurs despite seemingly correct configurations and verified prerequisites across the stack. Crucially, configuring LND to use password authentication (tor.password) works perfectly fine.
Troubleshooting Steps Performed & Key Findings:
Configuration Verification (Cookie Auth Attempt):
lnd.conf ([Tor] section):
tor.active=true
tor.control=127.0.0.1:9051
tor.cookiepath=/run/tor/control.authcookie (uncommented)

tor.password=... (commented out)

Other necessary Tor options (v3, socks, streamisolation, privatekeypath) are set.
Extensive checks for hidden characters or syntax errors in lnd.conf (using cat -A, manual retyping, simplifying the [Tor] section) did not reveal any issues.
torrc:
ControlPort 9051, CookieAuthentication 1, CookieAuthFileGroupReadable 1 are enabled.
HashedControlPassword is commented out.
bitcoin.conf:
Successfully uses Tor control via cookie (torcontrol, torauth=cookie:...) confirmed working.
Permissions & Ownership Verification:
LND runs as user lnduser, group lndgroup.
User lnduser is confirmed a member of the debian-tor group.
Tor cookie file /run/tor/control.authcookie exists, owned by debian-tor:debian-tor, permissions -rw-r----- (640).
Temporarily loosening cookie file permissions to 644 did NOT resolve the LND "unknown option" error. Permissions were reverted to 640.
Bitcoin Core's cookie file is present and accessible by the lnduser.
Backend Node Verification (Bitcoin Core):
Node is fully synced after a complete fresh Initial Block Download (IBD).
txindex=1 is enabled and getindexinfo reports "synced": true.
Node's UTXO set (chainstate) is confirmed correct via scantxoutset (it successfully finds a specific UTXO known to exist on-chain).
LND Binary Verification:
I have already tried completely removing and reinstalling the LND v0.18.5-beta binaries (lnd, lncli) from the official GitHub release tarball, ensuring correct architecture and permissions. This did NOT resolve the "unknown option: tor.cookiepath" error.
Password Authentication Test (Works Consistently):
As a workaround, I configured Tor (HashedControlPassword), Bitcoin Core (torpassword), and LND (tor.password) to use password authentication.
This configuration WORKS consistently. LND starts normally and successfully initializes the Tor controller when using tor.password. (Previous failures with password auth were due to an incorrect hash value being entered in torrc, this has been rectified and password auth itself is stable).
Current Situation:
Despite a fully functional backend node, correct Tor configuration for cookie auth, verified permissions, and even a fresh LND binary installation, LND v0.18.5-beta persistently fails to recognize the documented tor.cookiepath option. However, switching LND (and Tor/Core) to use password authentication works reliably.
Request for Assistance:
Is this persistent "unknown option: tor.cookiepath" error, despite the option being documented and password auth working, a known issue or potential regression in LND v0.18.5-beta under specific circumstances?
Given that password authentication works, what could possibly cause the configuration parser to specifically fail only for the tor.cookiepath option, even after binary reinstall and config simplification?
Are there any further debugging steps, LND configuration flags, environment variables, or specific log levels I can enable to get more insight into why the config parser rejects tor.cookiepath?
Could there be an obscure incompatibility with my specific system environment (RPi 5, OS version, specific library versions) that only affects cookie path handling but not password handling?
This situation seems highly specific to the tor.cookiepath handling. Any insights or guidance from the development team would be greatly appreciated.
Thank you for your time and consideration.

[starius]

There is no such option tor.cookiepath in LND.

If SAFECOOKIE method is used, then Tor itself provides the path to the cookie file to LND in response to PROTOCOLINFO command.

Temporarily loosening cookie file permissions to 644 did NOT resolve the LND "unknown option" error. Permissions were reverted to 640.

Could you remove tor.cookiepath option from the config file and then loosen cookie file permissions, please? This should work.

Useful links

Tor-related options can be found in sample-lnd.conf file.

There is also very useful Tor setup guide.

[vicortar]

Hi starius,
Thank you so much for your previous reply and clarification!
You were absolutely correct – the root cause of the persistent LND startup failure reporting "unknown option: tor.cookiepath" was indeed that tor.cookiepath is not a valid LND configuration option.
After completely removing the tor.cookiepath line from my lnd.conf file (while ensuring tor.control is enabled and Tor/Core are configured for cookie authentication), LND v0.18.5-beta now starts up successfully and consistently.
The logs confirm that LND is running stably, connecting to the Bitcoin Core backend, connecting to peers over Tor, and synchronizing the channel graph, without any errors related to Tor control port authentication using the SAFECOOKIE method.
I apologize for the confusion caused by my incorrect assumption about this configuration option based on outdated information or misunderstanding. Your guidance directly resolved the startup blocker.

[saubyk]

Converting this to a discussion...