[BUG] Fresh Ubuntu installation missing required ~/ots/ subdirectories

[TX-RX]

Summary

Fresh installations of OpenTAKServer 1.7.7 on Ubuntu are missing critical subdirectories in ~/ots/ that should be automatically created during installation. This causes TAK.gov plugin downloads to fail and potentially impacts other features that depend on these directories.

Affected Versions

• OpenTAKServer 1.7.7 (confirmed on Ubuntu 22.04)
• Likely affects earlier versions

Environment

• OS: Ubuntu 22.04 LTS (or similar Debian-based distributions)
• Installation Method: Standard Ubuntu installer script
• Impact Areas: TAK.gov Integration, Data Package uploads, SSL certificates

Missing Directories

The following directories are not created during a fresh installation and must be manually created:

1. ~/ots/packages/ - TAK.gov plugin downloads and ATAK plugin packages
2. ~/ots/uploads/ - User-uploaded data packages
3. ~/ots/ca/ - Certificate Authority files
4. ~/ots/data/ - Application data storage
5. ~/ots/certs/ - Client certificates

These are standard directories expected by the OpenTAKServer application and should be created as part of the initial installation process.

Symptoms

• TAK.gov plugin downloads fail when attempting to save plugins
• Data package uploads may fail
• Unclear file permission errors in logs
• Users unaware of the issue cannot use advertised features

Steps to Reproduce

1. Perform fresh installation of OpenTAKServer 1.7.7 on Ubuntu
2. Log into OpenTAKServer Web UI
3. Navigate to Tools > Link TAK.gov Account
4. Successfully link TAK.gov account
5. Attempt to download any available plugin
6. Result: Download fails with file not found error

Expected Behavior

All required subdirectories should be automatically created in ~/ots/ during the installation process with appropriate permissions (755).

Actual Behavior

Users must manually create these directories for the application to function:

mkdir -p ~/ots/{packages,uploads,ca,data,certs}
chmod 755 ~/ots/{packages,uploads,ca,data,certs}

Impact

• TAK.gov plugin plugin feature is non-functional out of the box
• Data package upload functionality may be impaired
• Users are unable to use documented features without manual intervention
• Installation appears incomplete to end users

Workaround

Users can manually create the required directories:

mkdir -p ~/ots/packages ~/ots/uploads ~/ots/ca ~/ots/data ~/ots/certs
chmod 755 ~/ots/{packages,uploads,ca,data,certs}

Then restart OpenTAK Server and retry the operations.

Suggested Fix

Update the Ubuntu installer script to ensure all required directories are created during installation:

# In installer script
mkdir -p $OTS_DATA_FOLDER/{packages,uploads,ca,data,certs}
chmod 755 $OTS_DATA_FOLDER/{packages,uploads,ca,data,certs}

Root Cause

The installer script does not create the complete directory structure expected by the OpenTAKServer application.

Related Documentation

TAK.gov integration: https://docs.opentakserver.io/link_account.html
Data Packages: https://docs.opentakserver.io/data_packages.html

[Knobee]

I ran into this same issue and investigated the codebase. Here's what I found:

The only real missing directory is packages/, and only in one code path — tak_gov_link_api.py:304 (POST /api/takgov/plugin), which writes the downloaded plugin file without ensuring the directory exists first. PR #281 fixes this by adding os.makedirs(..., exist_ok=True) before the write.

The other directories listed in this issue are already handled:

Directory	Status
~/ots/uploads/	Created at startup by defaultconfig.py:189-190
~/ots/ca/	Created by certificate_authority.py:29 during CA initialization
~/ots/logs/	Created at startup by app.py:219 and eud_handler.py:79
~/ots/data/	Not a real OTS directory — doesn't appear in the codebase
~/ots/certs/	Not a standalone directory — certs live under ~/ots/ca/certs/, created by certificate_authority.py:129

The manual upload path (POST /api/packages in package_api.py:188) already calls os.makedirs before writing — it's only the TAK.gov download path that was missing it.

So the fix is narrower than the issue suggests — PR #281 should resolve the actual failure described in the reproduction steps.

[Knobee]

PR #281 has been merged as of today. This issue should be resolved.