Welcome to the NZRT Wiki Podcast. Today we’re looking at occ Command Reference.

If you’ve ever needed to manage Nextcloud from the command line, the occ tool is your best friend. occ stands for ownCloud Console, and it’s Nextcloud’s built-in command-line interface. You’ll find it sitting in the Nextcloud root directory, and you run it either directly as occ or as php occ depending on your server setup. Let’s walk through the main command categories and what you can do with each one.

Starting with user management, which is probably where you’ll spend the most time. You can create a new user, delete one, list all users or filter that list by a search term, reset passwords, disable or enable login access, check when someone last logged in, and pull a full user report showing their email, login history, and quota. You can also get or set individual user preferences. For example, there’s a command specifically for setting a user’s storage quota, like capping someone at a hundred gigabytes. And if you want everything about a specific user in one go, the info command gives you a detailed breakdown.

Groups work in a very similar pattern. You can create and delete groups, list them or search for one, see who’s in a group, add or remove individual users, and pull group details.

Next up is app management. You can list every app installed on your Nextcloud instance, filter that list to show only enabled or only disabled apps, install new apps by name, enable or disable them without uninstalling, update individual apps or update everything at once, and completely remove an app. There’s also a code check command that’s handy for development work.

For file management, the scan commands are particularly important. You can trigger a full index of all user files across the entire instance, or narrow it down to a single user or a specific path. There’s a cleanup command that removes files sitting in the trash for more than thirty days, and a dry-run option that shows you what would be deleted before you commit. You can also transfer all of a user’s files to another user, which is useful for offboarding, or limit that transfer to a specific folder.

Database commands tend to be occasional maintenance operations. These include converting the file cache to support larger sixty-four-bit IDs for big file sets, adding missing primary keys or indices that the database might have lost, converting between database types, and even running a raw SQL query directly if you need to drop down to that level.

Configuration is handled through a consistent set of commands. You can get or set values at the app level or the system level, delete config keys, list the entire configuration, and import or export config as a file. This makes it straightforward to move settings between environments or back things up before a change.

If your Nextcloud is connected to an LDAP directory, there’s a dedicated category for that too. You can test the connection, view or update LDAP settings, sync users and groups from your directory into Nextcloud, list users not yet confirmed, and clear cached mappings when you need a fresh start.

Maintenance commands are ones you’ll want to know before doing any upgrade or significant change. You can check the overall system status, toggle maintenance mode on or off to block or allow user access, and switch to single-user mode for admin-only access. There are also commands for refreshing the Apache config file, upgrading themes, and updating the MIME type database.

Background jobs have their own section too. You can check the status of the pending queue, list everything in it, execute the next job in line, or target a specific job by its ID. For monitoring more broadly, you can tail the Nextcloud log in real time, set a size limit on it, and find out exactly where the log file lives on disk.

There’s also two-factor authentication management, where you can enforce or disable two-factor auth for individual users and check the current state across the system. Sharing commands let you list all shares, filter by user, create a new share, or transfer share ownership between users.

Now, the wiki includes some practical NZRT examples worth explaining. The first walks through creating a new finance team user by reading the password from an environment variable rather than exposing it in plain text, then adding that user to the finance group, and setting their quota to two hundred gigabytes. The second example is a scheduled overnight task set to run at two in the morning, running as the web server user, to automatically sync LDAP users into Nextcloud. The third schedules a three-in-the-morning daily job that first cleans up old trash and then rescans all files. And the fourth runs every five minutes to check the background job queue and append status output to a log file for monitoring.

In the NZRT environment specifically, it’s the database administrator and system administrator roles that rely on these commands for day-to-day maintenance, user provisioning, and troubleshooting.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.