claudetools/.claude/skills/owncloud/SKILL.md

name, description

name	description
owncloud	Read-only inventory of ACG's ownCloud server (cloud.acghosting.com / 172.16.3.22, ownCloud 10.16 Community) for GPS backup verification: who has an account, per-user storage used + quota + last login, and which GuruRMM endpoints actually run the ownCloud desktop client. Triggers: owncloud, cloud.acghosting, who backs up to owncloud, owncloud usage, owncloud audit.

ownCloud Skill

Read-only client for ACG's live ownCloud 10.16.0 Community server (cloud.acghosting.com, VM 172.16.3.22, Rocky Linux 9.6). Answers the GPS backup-audit question: which customers back up here and how much data do they hold - and, with --rmm, which enrolled machines actually run the ownCloud desktop client. It never writes.

This skill is one of the backup-verification siblings alongside seafile, b2 (Backblaze) and datto-workplace.

Running

OWNCLOUD=".claude/skills/owncloud/scripts/owncloud.py"
py "$OWNCLOUD" status                 # SSH ok + occ version / edition
py "$OWNCLOUD" users [--json]         # all users + enabled/quota/used/last login
py "$OWNCLOUD" usage [--json]         # per-user rollup, used GB desc (the audit view)
py "$OWNCLOUD" audit [--client NAME] [--rmm] [--json]

Add --json to users / usage / audit for machine-readable output. --host overrides the server IP (default 172.16.3.22).

Access channel

There is no ownCloud admin web / OCS account in the vault, so the channel is SSH + the occ CLI, not the OCS HTTP API (the OCS endpoint is reachable at https://cloud.acghosting.com/status.php but we lack an OCS admin cred). The client SSHes to root@172.16.3.22:22 with paramiko (password auth, AutoAddPolicy) and runs occ as the web user:

sudo -u apache php /var/www/owncloud/occ <cmd>

Credentials load lazily from the SOPS vault (never hardcoded): infrastructure/owncloud-vm.sops.yaml -> credentials.username (root) / credentials.password.

The occ / DB commands it settled on

• status: occ status --output=json (+ occ -V for the display version).
• users: occ user:list --show-all-attributes --output=json -> per user: uid, displayName, email, quota, enabled, lastLogin, creationTime, home, backend. lastLogin/creationTime are Unix epoch seconds (0 = never); the client renders them as UTC.
• used bytes: occ has no user:info / per-user usage on this version, so used storage is read from ownCloud's own filecache (the exact figure the UI shows). DB creds are read live from config.php (we already have root), then: SELECT s.id, fc.size FROM oc_storages s JOIN oc_filecache fc ON fc.storage=s.numeric_id WHERE s.id LIKE 'home::%' AND fc.path=''; Each row is home::<uid> -> root size in bytes.

What the data means

• used_bytes is the authoritative per-account storage used; an enabled user with non-zero usage is actively backing up here. usage/audit roll this up, sorted desc, with a total.
• quota is a string: default, none (unlimited), or a byte/size value.
• Usage is concentrated: as of the build (2026-07-05) a single account (pavon) holds ~14 TB and sysadmin ~2.9 TB, dwarfing the rest - ownCloud is used by a handful of clients, not the whole GPS base.

The "both" cross-check (--rmm)

Server-side (occ) tells you who has an account; --rmm adds the endpoint half. It logs in to GuruRMM (infrastructure/gururmm-server.sops.yaml) and, for each agent (filter with --client), runs a read-only detection PowerShell reporting installed products / running processes / config folders matching ownCloud. An agent is reported only if the client is actually present. This dispatches a command to live endpoints - always scope with --client rather than sweeping all 350+ agents.

Notes / gotchas / limitations

• Dirty filecache (-1): if a user's cached root size is -1 (cache not yet computed), the client falls back to du -sb <home>/files for that one user. That du can take minutes on a multi-hundred-GB home (timeout is generous, 900s); used_source in --json reports filecache vs du per user. At build time one account (anaise) was dirty and resolved via du (~0.6 TB).
• Orphan storages: the filecache can contain home::<uid> rows for deleted users (e.g. a former QWM-Sheila); the skill keys off the live occ user:list, so orphans do not appear in users/usage.
• No OCS/web API: deeper per-file / sharing queries would need an OCS admin cred we do not have; occ + filecache cover the audit needs.
• Shared plumbing (repo-root resolve, vault read, GuruRMM client + endpoint detection) lives in .claude/scripts/backup_common.py, used by all the server-backup skills. Detection patterns must be precise per backend - this skill uses ownCloud (not a bare cloud, which would over-match).