Open Settings → Admin → System Logs at /admin/system-logs.
Access requires an admin role and recent MFA verification. The viewer uses
the existing admin-only /api/logs/audit endpoint. Legacy /dev/system-logs
bookmarks redirect to the admin page; other /dev surfaces remain blocked
in production. These are application audit logs, not Caddy or Docker logs.
The system logs infrastructure provides comprehensive logging for all file operations across cloud storage services. Key features include:
Consolidated Search: Unified search across operation IDs, request IDs, and user identifiers.
Enhanced User Display: Shows both email addresses and user IDs for better readability.
Multi-Service Support: Works across Google Drive, OneDrive, Dropbox, Box, pCloud, and Jupiter.
Terminal Status Finalization: Activity logs are finalized from both SSE and polling status paths, so fallback polling still records complete/error phases.
Batch Delete Consolidation: Multi-item deletes are sent as one request, logged as one delete-batch timeline, and shown as a single visible row in activity/system logs after completion.
Singular Operation Labels: copy-batch and move-batch entries render as Copy or Move when the request only contains one item, while true multi-item requests continue to show Copy Batch and Move Batch.
Failure Diagnostics: Partial transfer entries now preserve failed-item previews and expose the same diagnostics in the activity details view when Fly/rclone reports them.
Google Drive to OneDrive Validation: Copy, move, backup, and sync launches fail fast when Google Drive contains sibling file/folder name collisions that OneDrive cannot represent.
Folder Conflict Policies: Folder copy and folder move currently support only skip and overwrite conflict handling across services; rename/ask are rejected until folder-level rename mapping exists.
Operation Logging with Resolved Paths
Purpose
The operation logging system includes resolved file and folder paths alongside their IDs, making logs more human-readable and easier to debug by showing actual file paths (e.g., /Documents/Projects/Report.docx) instead of opaque IDs (e.g., abc123xyz).
Features
1. Enhanced Log Entries
All operation logs now include:
File/Folder IDs: The original cloud storage identifiers.
Resolved Paths: Human-readable full paths when available.
Fallback Handling: Graceful degradation to ID-only display if resolution fails.
2. Supported Operations
Path resolution is applied to all logged file and folder operations:
Copy operations (single file, single folder, batch).
Move operations (single file, single folder, batch).
Delete operations.
Rename operations.
Download operations.
Upload operations.
Any other file/folder operations.
3. Multi-Service Support
Works across all supported cloud storage services:
Google Drive.
OneDrive.
Dropbox.
Box.
pCloud.
Jupiter.
Data Structures
OperationItem Interface
exportinterfaceOperationItem{ id?:string;// Cloud storage ID name:string;// File/folder name type?:"file"|"folder"; sizeBytes?:number; mimeType?:string; relativePath?:string; checksum?:string; resolvedPath?:string;// NEW: Full path resolved from ID}
OperationEndpoint Interface
exportinterfaceOperationEndpoint{ service?:ServiceType; accountId?:string; folderId?:string; path?:string; remoteName?:string; label?:string; rootPath?:string; resolvedPath?:string;// Full path resolved from folderId}
Path Resolution Utilities
resolvePathsForLogging()
Main utility function for resolving paths in logging context:
The system logs page at /admin/system-logs has been enhanced with consolidated search fields and improved user display functionality, following the same patterns implemented for activity logs.
Features Implemented
0. Terminal Completion Finalization for Polling Fallbacks
Activity log completion/error entries are now finalized from both status paths:
/api/ops (SSE stream).
/api/rclone/operations/[id] (polling endpoint).
This ensures operation logs reach a terminal phase even when clients fall back from SSE to polling in production environments (for example, during cold starts or transient SSE connection failures).
0.5. Consolidated Operation Type Filtering
Operation filtering now uses category-level options instead of separate single/batch options:
Uploads.
Downloads.
Copy/Move.
Delete.
Create/Modify.
Sync.
Backup.
Each category expands to one or more concrete operationType values in the API request, so existing backend filters continue to work unchanged.
1. Consolidated Operation/Request ID Search
Before: Two separate input fields for operationId and requestIdAfter: Single unified search field that searches both fields with OR logic
Benefits:
Simplified UI (reduced from 6 filter columns to 5).
Easier to use - type once to search both fields.
Consistent with activity logs UX.
2. Enhanced User Search
Before: Exact match on userId field only
After: Partial matching across multiple user identifier formats:
// Before: 6 columns with 3 separate text inputs<div className="grid gap-3 sm:grid-cols-2 md:grid-cols-6"><Input placeholder="Filter by operation ID"/><Input placeholder="Filter by request ID"/><Input placeholder="Filter by user ID"/></div>// After: 5 columns with 2 consolidated inputs<div className="grid gap-3 sm:grid-cols-2 md:grid-cols-5"><Input placeholder="Search by operation ID or request ID"/><Input placeholder="Search by user ID or email"/></div>
Usage Examples
Example 1: Searching by Operation ID
Search: "6b24aa81"
Results: All logs with operationId or requestId containing "6b24aa81"
Example 2: Searching by User Email
User Search: "example.com"
Results: All logs for users with email addresses containing "example.com"