Files
HomeAudit/dev_documentation/infrastructure/STORAGE_FIXES_SUMMARY.md
admin 705a2757c1 Major infrastructure migration and Vaultwarden PostgreSQL troubleshooting
COMPREHENSIVE CHANGES:

INFRASTRUCTURE MIGRATION:
- Migrated services to Docker Swarm on OMV800 (192.168.50.229)
- Deployed PostgreSQL database for Vaultwarden migration
- Updated all stack configurations for Docker Swarm compatibility
- Added comprehensive monitoring stack (Prometheus, Grafana, Blackbox)
- Implemented proper secret management for all services

VAULTWARDEN POSTGRESQL MIGRATION:
- Attempted migration from SQLite to PostgreSQL for NFS compatibility
- Created PostgreSQL stack with proper user/password configuration
- Built custom Vaultwarden image with PostgreSQL support
- Troubleshot persistent SQLite fallback issue despite PostgreSQL config
- Identified known issue where Vaultwarden silently falls back to SQLite
- Added ENABLE_DB_WAL=false to prevent filesystem compatibility issues
- Current status: Old Vaultwarden on lenovo410 still working, new one has config issues

PAPERLESS SERVICES:
- Successfully deployed Paperless-NGX and Paperless-AI on OMV800
- Both services running on ports 8000 and 3000 respectively
- Caddy configuration updated for external access
- Services accessible via paperless.pressmess.duckdns.org and paperless-ai.pressmess.duckdns.org

CADDY CONFIGURATION:
- Updated Caddyfile on Surface (192.168.50.254) for new service locations
- Fixed Vaultwarden reverse proxy to point to new Docker Swarm service
- Removed old notification hub reference that was causing conflicts
- All services properly configured for external access via DuckDNS

BACKUP AND DISCOVERY:
- Created comprehensive backup system for all hosts
- Generated detailed discovery reports for infrastructure analysis
- Implemented automated backup validation scripts
- Created migration progress tracking and verification reports

MONITORING STACK:
- Deployed Prometheus, Grafana, and Blackbox monitoring
- Created infrastructure and system overview dashboards
- Added proper service discovery and alerting configuration
- Implemented performance monitoring for all critical services

DOCUMENTATION:
- Reorganized documentation into logical structure
- Created comprehensive migration playbook and troubleshooting guides
- Added hardware specifications and optimization recommendations
- Documented all configuration changes and service dependencies

CURRENT STATUS:
- Paperless services:  Working and accessible externally
- Vaultwarden:  PostgreSQL configuration issues, old instance still working
- Monitoring:  Deployed and operational
- Caddy:  Updated and working for external access
- PostgreSQL:  Database running, connection issues with Vaultwarden

NEXT STEPS:
- Continue troubleshooting Vaultwarden PostgreSQL configuration
- Consider alternative approaches for Vaultwarden migration
- Validate all external service access
- Complete final migration validation

TECHNICAL NOTES:
- Used Docker Swarm for orchestration on OMV800
- Implemented proper secret management for sensitive data
- Added comprehensive logging and monitoring
- Created automated backup and validation scripts
2025-08-30 20:18:44 -04:00

5.8 KiB

STORAGE CONFIGURATION FIXES - COMPLETE

Fixed Stack Files to Use Existing Storage Infrastructure
Generated: 2025-08-29
Status: COMPLETE - All stack files updated


🎯 EXECUTIVE SUMMARY

Fixed 9 application stack files to use existing SMB shares and NFS exports instead of non-existent paths. All services now reference storage that actually exists on OMV800.

Storage Strategy Applied:

  • Use existing SMB shares for user data and media files
  • Use existing NFS exports for service configurations
  • Keep database storage local for performance
  • Maintain existing directory structure as much as possible

📋 FIXES APPLIED

1. Jellyfin (stacks/apps/jellyfin.yml)

Fixed:

  • :/export/jellyfin/config:/export/jellyfin
  • :/export/media/movies:/srv/mergerfs/DataPool/Movies
  • :/export/media/tv:/srv/mergerfs/DataPool/tv_shows

Rationale: Use existing Movies and tv_shows SMB shares for media, existing jellyfin NFS export for config

2. Immich (stacks/apps/immich.yml)

Fixed:

  • :/export/immich/data:/srv/mergerfs/DataPool/immich

Rationale: Use existing immich SMB share for photo data storage

3. Nextcloud (stacks/apps/nextcloud.yml)

Fixed:

  • :/export/nextcloud/html:/srv/mergerfs/DataPool/nextcloud

Rationale: Use existing nextcloud SMB share for file storage

4. Paperless-NGX (stacks/apps/paperless.yml)

Fixed:

  • :/export/paperless/data:/export/paperless
  • :/export/paperless/media:/srv/mergerfs/DataPool/pdfs

Rationale: Use existing pdfs SMB share for document storage, existing paperless NFS export for config

5. Gitea (stacks/apps/gitea.yml)

Fixed:

  • :/export/gitea/data:/export/gitea

Rationale: Use existing gitea NFS export for repository storage

6. AppFlowy (stacks/apps/appflowy.yml)

Fixed:

  • :/export/appflowy/minio:/srv/mergerfs/DataPool/appflowy

Rationale: Use existing appflowy SMB share for data storage

7. Vaultwarden (stacks/apps/vaultwarden.yml)

Fixed:

  • :/export/vaultwarden/data:/export/vaultwarden

Rationale: Use existing vaultwarden NFS export for password database

8. AdGuard (stacks/apps/adguard.yml)

Fixed:

  • :/export/adguard/conf:/export/adguard

Rationale: Use existing adguard NFS export for configuration

9. Home Assistant (stacks/apps/homeassistant.yml)

Fixed:

  • :/export/homeassistant/config:/export/homeassistant

Rationale: Use existing homeassistant NFS export for configuration


📊 STORAGE MAPPING SUMMARY

SMB Shares Used (Direct Mergerfs Access):

Movies: /srv/mergerfs/DataPool/Movies
tv_shows: /srv/mergerfs/DataPool/tv_shows
immich: /srv/mergerfs/DataPool/immich
nextcloud: /srv/mergerfs/DataPool/nextcloud
pdfs: /srv/mergerfs/DataPool/pdfs
appflowy: /srv/mergerfs/DataPool/appflowy

NFS Exports Used (Bind Mounted):

jellyfin: /export/jellyfin
paperless: /export/paperless
gitea: /export/gitea
vaultwarden: /export/vaultwarden
adguard: /export/adguard
homeassistant: /export/homeassistant

Local Storage (Databases):

PostgreSQL: Local volume (performance)
MariaDB: Local volume (performance)
Redis: Local volume (performance)

VERIFICATION CHECKLIST

Storage Paths Verified:

  • Movies: /srv/mergerfs/DataPool/Movies (exists)
  • TV Shows: /srv/mergerfs/DataPool/tv_shows (exists)
  • Immich: /srv/mergerfs/DataPool/immich (exists)
  • Nextcloud: /srv/mergerfs/DataPool/nextcloud (exists)
  • PDFs: /srv/mergerfs/DataPool/pdfs (exists)
  • AppFlowy: /srv/mergerfs/DataPool/appflowy (exists)
  • Jellyfin: /export/jellyfin (exists)
  • Paperless: /export/paperless (exists)
  • Gitea: /export/gitea (exists)
  • Vaultwarden: /export/vaultwarden (exists)
  • AdGuard: /export/adguard (exists)
  • Home Assistant: /export/homeassistant (exists)

Stack Files Updated:

  • stacks/apps/jellyfin.yml
  • stacks/apps/immich.yml
  • stacks/apps/nextcloud.yml
  • stacks/apps/paperless.yml
  • stacks/apps/gitea.yml
  • stacks/apps/appflowy.yml
  • stacks/apps/vaultwarden.yml
  • stacks/apps/adguard.yml
  • stacks/apps/homeassistant.yml

🚀 NEXT STEPS

Immediate Actions:

  1. Test NFS connectivity from worker nodes
  2. Deploy corrected Caddyfile to fix service conflicts
  3. Complete Docker Swarm cluster setup
  4. Deploy database services first (PostgreSQL, MariaDB)

Service Deployment Order:

# 1. Deploy databases first
docker stack deploy -c stacks/databases/postgresql-primary.yml postgresql
docker stack deploy -c stacks/databases/mariadb-primary.yml mariadb

# 2. Deploy simple services
docker stack deploy -c stacks/apps/adguard.yml adguard
docker stack deploy -c stacks/apps/vaultwarden.yml vaultwarden

# 3. Deploy complex services
docker stack deploy -c stacks/apps/jellyfin.yml jellyfin
docker stack deploy -c stacks/apps/immich.yml immich
docker stack deploy -c stacks/apps/nextcloud.yml nextcloud

📈 EXPECTED RESULTS

Benefits:

  • Services will start successfully (no missing storage errors)
  • Data integrity maintained (using existing storage)
  • Performance optimized (direct mergerfs access for media)
  • Simplified migration (no storage reconfiguration needed)

Risk Mitigation:

  • No data loss (using existing storage)
  • No service disruption (existing shares remain active)
  • Easy rollback (can revert to original paths if needed)

Document Status: Complete
Next Action: Proceed with Docker Swarm setup and service deployment
Risk Level: LOW - All storage paths verified and existing