Most Odysseus Portable issues fall into a small set of categories: port conflicts, model memory pressure, filesystem limitations on USB drives, or platform security restrictions on downloaded binaries. The sections below cover each scenario with specific diagnostic steps and fixes. If none of these solve your problem, the combined log file is always the best starting point — see Reading Logs at the end of this page.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/techjarves/Odysseus-Portable/llms.txt
Use this file to discover all available pages before exploring further.
Port is already in use
Port is already in use
Symptoms: The orchestrator prints an error like
The orchestrator automatically detects occupied ports and increments to the next available one. For example, if port If the auto-selection still fails, find and stop whatever process is holding the port:To permanently use different ports, set environment variables before launching:
EADDRINUSE: address already in use or a service fails to start.Odysseus Portable uses three ports by default:| Service | Default Port | Environment Variable |
|---|---|---|
| Odysseus web UI | 7070 | ODYSSEUS_PORT |
| API proxy | 8080 | ODYSSEUS_PROXY_PORT |
| llama-server | 10086 | ODYSSEUS_LLAMA_PORT |
7070 is taken it will try 7071, 7072, and so on. Check the console output for a line like:GGUF model fails to load or Out of Memory (OOM)
GGUF model fails to load or Out of Memory (OOM)
Symptoms: Each step restarts If To check current VRAM usage:
llama-server crashes shortly after a model is selected, the proxy returns a 5xx error, or you see out of memory / failed to allocate in the logs.The proxy server catches memory errors from llama-server and automatically retries with a smaller context window, stepping down through this ladder:llama-server with a lower --ctx-size value. The console will print:llama-server still fails after stepping down to 2048 tokens, the model is too large for your current hardware. Options:- Download a smaller quantization of the same model (e.g. Q2_K instead of Q8_0)
- Download a smaller parameter model (1.5B or 3B instead of 7B/8B)
- Force a lower starting context to avoid repeated restarts:
exFAT or FAT32 USB drive symbolic link errors
exFAT or FAT32 USB drive symbolic link errors
Symptoms: Warnings in the console about symlink creation failures, or models not appearing in the server’s model list despite being present in the
models/ folder.exFAT and FAT32 filesystems do not support symbolic links. When llama-server scans nested model folders (e.g. HuggingFace hub cache structure), the orchestrator tries to create a flat symlink in the models/ root for each nested GGUF file. On FAT-based drives this fails.The orchestrator handles this automatically in two ways:- Archive extraction: Archives are extracted to a temporary directory on the host’s local filesystem (
~/.cache/odysseus-portable/temp-extract/), symlinks inside the archive are resolved to real file copies, and the result is copied back to the drive. - Model linking: If
fs.symlinkSyncfails, the code falls back tofs.linkSync(a hardlink). If hardlinks also fail, a warning is logged but the model path is still registered.
- Ensure the drive is mounted with write permissions (not read-only mode)
- On macOS, check System Settings → Privacy & Security → Files and Folders
- On Linux, verify the mount options with
mount | grep <drive-label>and remount withoutroif needed
macOS Gatekeeper "cannot be opened" error
macOS Gatekeeper "cannot be opened" error
Symptoms: macOS shows a dialog like “llama-server cannot be opened because it is from an unidentified developer” or “cannot be opened because Apple cannot check it for malicious software”.The orchestrator automatically strips Gatekeeper quarantine attributes from downloaded binaries after extraction:If you still see the dialog, it may be on the
start.sh script itself or on the Node.js binary. Fix it manually:You may need to approve the binary once in System Settings → Privacy & Security → Allow anyway on macOS Sequoia and later, even after removing the quarantine attribute.
Python dependencies fail to install
Python dependencies fail to install
Symptoms: The orchestrator stops during the “Installing dependencies” step, prints a pip or uv error, and exits with a non-zero code.The dependency installation method differs by platform:For any dependency failure, check the full error output in
- Windows
- macOS / Linux
Windows uses an embedded Python 3.12 extracted to
odysseus/bin/python/.- Verify the Python executable exists:
- If it is missing, delete
odysseus\bin\python\and relaunch — the orchestrator will re-download and re-extract the embedded Python. - If Python exists but pip is missing, the orchestrator re-bootstraps pip automatically. If that also fails, delete
odysseus\bin\python\entirely and relaunch.
logs/combined_<timestamp>.log — the specific package name and error message will be there.Odysseus web app does not open in browser
Odysseus web app does not open in browser
Symptoms: The orchestrator completes startup but no browser window appears, or the browser opens to a blank page or connection error.The orchestrator opens the browser using the OS’s default handler (
start on Windows, open on macOS, xdg-open on Linux) after confirming the web server is listening. If the browser does not open automatically:- Wait for the console to print:
- Navigate manually to
http://127.0.0.1:7070(or whichever port is shown in the console output). - If the connection is refused, check the console for a “Selected next free port” message — the actual port may differ from 7070.
- If the Odysseus Python process failed to start, the console will print an exit code error. Check
logs/combined_<timestamp>.logfor the Python traceback.
Login credentials not working
Login credentials not working
Symptoms: The Odysseus login page rejects username/password combinations.The default credentials seeded at first run are:
If you have overridden these with environment variables, use those values instead:After signing in for the first time, change the default password in the Odysseus user profile settings.
| Field | Default Value |
|---|---|
| Username | admin |
| Password | techjarves |
llama-server crashes immediately on startup
llama-server crashes immediately on startup
Symptoms: The orchestrator prints
[Error] llama-server terminated unexpectedly with code <N> within seconds of starting, or the inference backend never becomes ready.Diagnostic steps:-
Check the log — the last 40 lines of
logs/combined_<timestamp>.logare printed to the console on crash. Look for a specific error fromllama-server. -
Linux CUDA: Ensure your NVIDIA driver is current. The CUDA runtime bundled by the orchestrator requires a minimum driver version:
-
macOS quarantine: Even if the app launched once, a macOS update can re-quarantine binaries. Strip the attribute again:
-
Force binary re-download: If the binary is corrupted or mismatched for your system, delete it and let the orchestrator fetch a fresh copy:
-
Missing GGUF models:
llama-serverin router mode starts without a model loaded. If it still crashes before any model is requested, the binary itself may be incompatible with your OS version.
Reading Logs
All output from the orchestrator, the Odysseus web server, andllama-server is captured in a single combined log file created at startup:
logs/ directory is cleared at the beginning of each launch, so there is always exactly one log file corresponding to the current or most recent session.
To read the log in real time while Odysseus is running:
start.sh or start.bat — the fatal error message will be printed there before the process exits.