Category Archives: 000NCL

00 - Nextcloud Overview, 000NCL

Admin Dashboard

Welcome to the NZRT Wiki Podcast. Today we’re looking at ⚙️ Admin Dashboard.

If you’re working with Nextcloud at NZRT, the Admin Dashboard is your central hub for keeping everything running smoothly. You can get to it by navigating to the admin section of your Nextcloud settings. From there, you have control over pretty much everything — users, apps, security, and the overall health of the system.

Let’s walk through what you’ll find when you get there.

The dashboard is organized into several core sections. First up is the Overview, which gives you a quick snapshot of system health, storage usage, how many users you have, and which sessions are currently active. Think of it as your at-a-glance health check.

Next is Basic Settings. This is where you configure things like trusted domains, how background jobs are handled, and your email setup. If Nextcloud needs to send notifications or password resets, this is where that gets configured.

Then there’s Security. This section lets you enforce two-factor authentication across your users, set password policies, and configure rate limiting — which helps protect the system against brute-force login attempts.

Sharing settings let you control how files and folders are shared. You can set the defaults for sharing behavior, manage federated sharing with other Nextcloud instances, and control whether public links are allowed and under what conditions.

Users and Groups is where you manage your actual user accounts — adding people, assigning them to groups, and setting storage quotas so nobody accidentally fills up the server.

The Apps section lets you install, enable, or disable apps within Nextcloud and manage what permissions those apps have. This is important for keeping the feature set aligned with what NZRT actually needs.

And finally, Monitoring gives you access to the activity log, the audit trail, and the status of background jobs. If something seems off, this is usually your first stop for investigating what’s happening.

Now let’s talk about some of the common tasks you’ll actually perform in the dashboard. There are six key tasks worth knowing about. Viewing users is done by going to Settings then Users. Enabling two-factor authentication is also under Settings, in the Security area. Configuring LDAP for directory integration lives under Settings in the LDAP section. Managing apps is under Settings then Apps. Viewing logs is under Settings then Logging. And checking storage is available right from the Overview section. So across all six of these tasks, you’re mostly navigating through the Settings menu, which keeps things fairly intuitive once you know the layout.

One of the more technical but important aspects of running Nextcloud is background jobs. Nextcloud needs a process running in the background to handle things like syncing calendars, updating file type databases, sending notifications, and general housekeeping. There are a few ways to set this up — you can use Ajax, which runs jobs when users interact with the system, or you can use a proper system-level scheduled task, which is more reliable.

For NZRT, the recommended approach is system cron, running every five minutes. What that looks like in practice is two scheduled commands that run automatically on that five-minute cycle. The first one updates the file type database so Nextcloud correctly recognizes and handles different kinds of files. The second one syncs birthday calendars from your contacts into the calendar app. Both of these run as the web server user and call Nextcloud’s built-in command-line tool to do their work. Once set up in your system’s cron scheduler, they just happen in the background without you needing to think about them.

In the context of NZRT specifically, the admin role — that’s the xc account — uses the dashboard on a daily basis. The main things you’re checking for are Nextcloud’s overall health, whether user quotas are being respected, what’s showing up in the activity logs, and whether the integrations with Dolibarr and WordPress are still functioning correctly. Those integrations are important to NZRT’s day-to-day workflow, so keeping an eye on them through the dashboard is a routine part of the admin’s responsibilities.

If you want to go deeper on any of the areas covered today, the related wiki notes to look at are the Administration Overview, Apps and Plugins, and Users and Groups pages. Those will give you more detail on each of those specific areas.

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

000NCL, 06 - Administration

Administration Overview

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Administration Overview.

So if you’re working with NZRT’s self-hosted tech stack, Nextcloud is a core piece of infrastructure. It serves over fifty users, and keeping it running smoothly is a shared responsibility between two key roles — the admin account, which is xc, and the database administrator, known as dan. Together they cover everything from keeping apps updated to making sure backups are running and security patches are applied on time.

Let’s walk through what that actually looks like day to day.

There are seven main admin tasks, and each one has a set frequency and an owner. First, updating apps — that happens monthly, and both xc and dan are responsible for it. Second, backing up the database and files — that’s a daily job owned by dan, so it’s happening every single day to make sure nothing is lost. Third, monitoring storage usage — dan handles that weekly, keeping an eye on how much space is being consumed across the system. Fourth, reviewing audit logs — that’s also weekly, but this one belongs to xc. Audit logs are important for spotting anything unusual in user activity or system behaviour. Fifth, user provisioning — that means creating accounts, managing access, and setting up new users — and that’s handled by xc on an as-needed basis. Sixth, performance tuning — this one is quarterly and belongs to dan. It involves things like optimising the cache and tuning the database to keep everything running fast. And seventh, security updates — those get applied as soon as they’re released, and both dan and xc share that responsibility together.

Now, the admin panel is broken down into four main sections. The first is Apps and Plugins, where you can install, enable, disable, and update any of the apps that extend Nextcloud’s functionality. The second is Backups and Maintenance, which covers the backup strategy and how you’d restore data if something went wrong. The third is Performance Tuning, where you’d look at cache optimisation and database settings to keep response times fast. And the fourth is Logging and Monitoring, which gives you health checks, alerts, and log analysis tools to stay on top of what the system is doing.

To get into the admin dashboard, you navigate to your NZRT Nextcloud instance, go to the admin section of the settings area, and log in with the xc account or any other account that has admin privileges. That single page is your central control panel for everything we’ve just discussed.

One thing worth understanding is the broader context here. For NZRT, Nextcloud isn’t just a nice-to-have — it’s mission-critical infrastructure. With over fifty users relying on it daily, the expectation is high availability, solid security, and consistent performance. That’s why responsibility is split the way it is. Dan handles the more technical, scheduled maintenance — daily backups, weekly storage checks, quarterly tuning. xc handles the governance and access side — audit log reviews, user provisioning, and security decisions. It’s a clean division that makes sure nothing falls through the cracks.

If you want to go deeper on any of these areas, the wiki has dedicated notes on each of the four sections we mentioned — Apps and Plugins, Backups and Maintenance, Performance Tuning, and Logging and Monitoring. Each of those goes into much more detail on the specific procedures and tools involved.

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

000NCL, 06 - Administration

Apps Plugins

Welcome to the NZRT Wiki Podcast. Today we’re looking at 📦 Apps & Plugins.

Nextcloud on its own is already a powerful platform, but where it really shines is in its app ecosystem. You can extend what Nextcloud does by installing apps and plugins that plug straight into the core system. At NZRT, there’s a curated list of recommended apps that are either already installed or considered essential additions, and today we’re going to walk through all of that.

So let’s start with the recommended apps. There are three broad categories to think about: core functionality, security, and compliance or performance.

On the core side, you’ve got Talk, which handles chat, video, and calls. Then Calendar for scheduling and events, and Contacts for your address book. Deck handles task management, and Collectives gives you a built-in wiki and documentation space. Rounding out the core apps is Nextcloud Office, which lets you edit documents directly inside Nextcloud.

Then there are the security-focused apps. User LDAP handles Active Directory integration, so your existing user accounts can connect through. Two-Factor Authentication lets you enforce two-factor login across the platform. And Suspicious Login does exactly what it sounds like — it watches for unusual access patterns and flags anomalies.

Finally, from a compliance and performance angle, Audit Logging captures compliance-grade logs of activity on the system, and Full-Text Search indexes your documents so you can actually find things quickly.

Now, when you need to install a new app, you’ve got two ways to do it. The first is through the graphical interface. You go into Settings, then across to Apps, and you use the search field to find the app you want. Once you find it, you hit Install, approve whatever permissions it asks for, and then enable it. That’s the straightforward GUI route — no command line needed.

The second method is through the command line, and this is what system administrators often prefer for consistency and automation. There are two commands you’d run in sequence. The first tells the system to install the app by name. The second command then enables it so it becomes active. Simple two-step process on the server side.

Speaking of permissions — and this is important — whenever you’re installing an app, you should always stop and review what access it’s asking for. There are three main things to look at. First, file access: can this app read or write to user files? Second, user data: can it see usernames and email addresses? And third, admin functions: can it actually change system settings? These aren’t just checkbox exercises. Understanding what an app can access is how you prevent unintended data exposure.

Which brings us to how NZRT actually handles this process. It’s not a free-for-all. There’s a structured approval workflow before any new app hits production. Step one, your admin — that’s xc — evaluates whether the app actually meets the business requirement. Step two, there’s a permissions and security audit to understand what the app touches and whether that’s acceptable. Step three, the app gets tested in a staging environment first, not straight onto the live system. Step four, once it passes testing, it gets deployed to production and users are notified. And step five, the team monitors it after deployment — if something doesn’t look right, the app gets disabled.

The key people involved in that vetting process are xc on the admin side and dan on the security side. Together they make sure nothing goes into production that could cause data leakage or introduce vulnerabilities.

The bigger picture here is that apps are how you make Nextcloud fit NZRT’s actual workflows rather than working around a generic tool. Talk keeps internal communication inside the platform. Deck and Collectives mean project management and documentation don’t have to live in separate external systems. Office means you’re not exporting files to edit them elsewhere. Each app closes a gap, and the approval process makes sure closing that gap doesn’t open a new one.

If you want to dig deeper into related topics, the wiki also covers Administration Overview, Performance Tuning, and Audit Logs — all connected to this area.

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

00 - Nextcloud Overview, 000NCL

Architecture Tech Stack

Welcome to the NZRT Wiki Podcast. Today we’re looking at Architecture & Tech Stack.

So let’s start with what we’re actually talking about here. NZRT runs its own instance of Nextcloud, which is a self-hosted file sync and collaboration platform. You can reach it online at cloud dot nzrtnetwork dot com slash nextcloud. If you’re working locally on Nathan’s laptop, everything syncs down automatically through the Nextcloud desktop client into a folder called Nextcloud2 under the main user directory. So when you’re offline, your files are still right there on disk.

Now let’s walk through the tech stack — in other words, what’s actually powering this thing under the hood. There are seven components worth knowing about. First, hosting. Nextcloud lives on Hoopla, which is a shared Linux hosting environment managed through cPanel. Second, the web server is Apache, and cPanel handles its configuration. Third, PHP — again cPanel-managed, running version 8 or higher. Fourth, the database is MySQL version 8, and the specific database name is nzrtnetw underscore nc. Fifth, storage lives on the cPanel filesystem under the home directory for the nzrtnetw account. Sixth, caching — and this is worth noting — there’s no caching layer available here because shared hosting doesn’t support it. And seventh, search uses Nextcloud’s own built-in search engine. There’s no Elasticsearch, again because shared hosting doesn’t give you that option.

Now let’s talk about the system architecture — how all the pieces connect. Picture it as three layers stacked on top of each other. At the top you have the client layer, which is the Nextcloud desktop client running on the laptop. It connects over a secure HTTPS connection down to the middle layer, which is the Nextcloud web application itself — Apache and PHP running on Hoopla’s shared hosting at that cloud dot nzrtnetwork dot com address. From there, Nextcloud splits into two directions. On one side it talks to the MySQL database to store metadata and application data. On the other side it reads and writes actual files to the cPanel filesystem. And here’s the interesting part — sitting beneath that same database layer, sharing the same cPanel hosting account, you also have Dolibarr and WordPress. So all three applications — Nextcloud, Dolibarr, and WordPress — are running as neighbours on the same Hoopla account.

That shared hosting arrangement is actually central to how NZRT’s systems fit together, so it’s worth keeping in mind when you’re thinking about integrations or troubleshooting.

Speaking of integrations, there are four key ones to know. First, Dolibarr — that’s the ERP system used for document management and business workflows, and it sits right there on the same cPanel instance. Second, WordPress handles the public-facing website and content management, also on the same instance. Third, the desktop client keeps files synced to the laptop at that Nextcloud2 folder path, giving you offline access to the vault and shared folders. And fourth, WebDAV — this is the protocol that agents and automation scripts use to access files programmatically. The WebDAV endpoint lives at cloud dot nzrtnetwork dot com slash nextcloud slash remote dot php slash dav slash.

To wrap it all up — NZRT’s Nextcloud setup is deliberately lean. It’s shared hosting, so you don’t get extras like caching or Elasticsearch, but what you do get is tight co-location with Dolibarr and WordPress, solid file sync to the laptop, and a clean WebDAV interface for automated access. Everything runs under one cPanel account, which keeps the infrastructure simple and in one place.

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

000NCL, 04 - Users & Security

Audit Logs

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Audit Logs.

If you’ve ever needed to know who accessed a file, when a share was created, or whether someone’s been logging in at unusual hours, audit logs are your answer. Nextcloud Audit Logs track all user actions across the platform — file access, edits, shares, permission changes, and logins. For an organisation like NZRT, they’re essential for compliance, security monitoring, and forensic investigations when something goes wrong.

Let’s start with what actually gets logged. There are five main categories of events. First, file operations — that’s any time a file is created, edited, deleted, moved, or copied. Second, sharing events — when a share is created, when permissions on that share change, or when a share link expires. Third, user actions — things like logging in, logging out, changing a password, or setting up two-factor authentication. Fourth, admin actions — creating users, assigning someone to a group, or installing an app. And fifth, security events — failed login attempts, blocked shares, and any unauthorized access attempts. Together, that’s a comprehensive picture of everything happening inside your Nextcloud instance.

Now, how do you actually get to these logs? There are two ways. The first is through the web interface. You go into Settings, then Logging, and you’ll see the last hundred entries right there on screen — no extra tools needed, great for a quick check. The second way is to go directly to the log file on the server. That file lives at a path on the server’s file system, inside the Nextcloud data directory, and it’s called nextcloud.log. If you need to do any serious analysis — searching, filtering, exporting — you’ll want to pull that file directly rather than browsing through the web UI.

Next up is log retention. In Nextcloud’s configuration file, there are two key settings you should know about. The first controls how large the log file can get before it rotates — at NZRT, that’s set to ten megabytes. Once the log hits that size, it starts a fresh file so things don’t spiral out of control. The second setting just tells Nextcloud where to write the log file in the first place, pointing it to that same nextcloud.log location we mentioned. On top of that, logs older than ninety days are archived. That’s not arbitrary — it aligns with GDPR data minimisation principles, meaning you’re keeping what you need for a reasonable period and not holding onto personal data longer than necessary.

Now let’s talk about how NZRT specifically uses compliance monitoring, because different roles have different responsibilities here. There are four roles with distinct monitoring duties. Starting with xc — that’s the administrator — who monitors all actions across the board and gets alerted to things like bulk file deletions or mass sharing events, which could indicate either a mistake or something more serious. Then there’s fin, who focuses on data exports and share activity, with specific alerts for things like exported invoices or new shares being created — important for financial audit trails. Next is han, whose alerts are focused on HR-related activity: access to the HR folder and logins happening outside of office hours, which could signal unauthorized access. Finally, there’s ema, who watches for document changes — specifically anything that looks like an unapproved sync with Dolibarr, NZRT’s ERP system.

So why does all of this matter in the NZRT context specifically? There are three main compliance areas these logs support. First, Dolibarr EDM compliance — that’s electronic document management — where you need a clear record of who touched which documents and when. Second, HR record confidentiality, because personnel files need to be kept private and audit logs give you proof of who accessed them. And third, financial audit trails, so that any time financial data is exported or shared, there’s a record to point to. The person responsible for archiving and analysing logs at NZRT is dan, who holds the DBA role and steps in when there’s a security incident that needs investigation.

Pulling it all together, audit logs aren’t just a nice-to-have. They’re what lets you answer the hard questions after the fact — who did what, when, and from where. Whether it’s a compliance review, a security incident, or just wanting confidence that sensitive data is being handled correctly, Nextcloud Audit Logs give you the visibility you need. If you want to go deeper, the related wiki pages on Users and Groups, Logging and Monitoring, and Permissions and Sharing are worth reading alongside this one.

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

000NCL, 06 - Administration

Backups Maintenance

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Backups & Maintenance.

If you’re running NZRT’s Nextcloud instance, backups are not optional. They protect against data loss, ransomware, and hardware failure, and they cover Dolibarr and WordPress data too. So let’s walk through exactly how the backup strategy works, what the restore process looks like, and what regular maintenance tasks you need to keep on top of.

First, the strategy at a high level. Backups run on two cycles. Daily incremental backups capture only what’s changed since the last run. Weekly full backups capture everything from scratch. Retention is thirty days for backups you can access online, and one year for archived copies. Storage spans two locations: a local NAS device on-site, and an off-site destination, either an S3 cloud bucket or tape storage. Two important numbers to know here: RPO and RTO. RPO stands for Recovery Point Objective, meaning the maximum amount of data you’re willing to lose. For NZRT Nextcloud that’s four hours. RTO stands for Recovery Time Objective, meaning how fast you need to be back online after a failure. That target is one hour.

Now let’s talk about what actually gets backed up. There are three components. First is the MySQL database, which runs between five and ten gigabytes. That backs up every day at four in the morning using either mysqldump or Percona XtraBackup. Second is the Nextcloud data folder containing all user files, which can range from five hundred gigabytes up to two terabytes. That one backs up weekly, on Sunday nights at two in the morning, using rsync or tar. Third are the configuration files, which are under one gigabyte and back up monthly to the NAS using rsync.

Now let’s walk through the backup script itself. The script is written in Bash and runs automatically. It starts by setting up a destination folder on the NAS and generating a timestamp so every backup file gets a unique name. It then runs a database dump, which exports the entire Nextcloud database into a single SQL file named with that timestamp. Once that’s done, it compresses the file to save space. Next it uses rsync to copy all Nextcloud user files across to the NAS. After that, it sweeps through the backup folder and deletes any compressed database files that are older than thirty days, keeping storage tidy. Finally, if the script detects it’s running on a Sunday, it pushes everything up to the S3 cloud bucket for off-site storage.

So what happens when you actually need to restore? There are four steps, and the order matters.

Step one: put Nextcloud into maintenance mode. This locks out users and prevents any data being written while you’re restoring.

Step two: restore the database. You feed your backup SQL file directly into MySQL and it rebuilds the database from that file.

Step three: restore the files. You use rsync to copy everything from the NAS backup location back into the Nextcloud data directory. You also reset file ownership so the web server process can read and write those files correctly.

Step four: bring Nextcloud back online by switching maintenance mode off. If the database schema looks different from what Nextcloud expects, there’s an additional command you can run that converts the file cache to handle larger integers, which is sometimes needed after a schema change.

Recovery procedures must be tested quarterly. That responsibility sits with xc, the admin. Dan, the DBA, manages the backup infrastructure itself.

On the maintenance side, there are four recurring tasks to stay on top of. The first is a monthly database integrity check, which ensures the internal file tracking database is healthy. The second is a weekly trash cleanup that clears out deleted files from the Nextcloud trash and reclaims storage space. Third is updating the dot-htaccess file, which you run as needed to keep web server rules in sync with Nextcloud’s configuration. Fourth is a weekly file scan that checks all user files are correctly indexed so search and file listings stay accurate.

To wrap up: daily database backups at four AM, weekly file backups Sunday nights at two AM, thirty days online retention, one year archived, local NAS plus S3 off-site, a four-hour data loss ceiling, and a one-hour recovery target. Dan owns the infrastructure, xc tests restores every quarter. Keep those maintenance commands running on schedule and you’ll be in good shape.

For more detail, check the related wiki notes on Administration Overview, Logging and Monitoring, and the occ Command Reference.

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

000NCL, 02 - Collaboration Apps

Calendar

Welcome to the NZRT Wiki Podcast. Today we’re looking at ?? Calendar.

If you’ve ever missed a deadline because someone forgot to tell you about a meeting, or you’ve had to chase a teammate just to find out when a client call is happening, then shared calendaring is exactly what this episode is about. Nextcloud Calendar is the solution NZRT uses to keep the whole team on the same page when it comes to scheduling, events, and time.

So what can Nextcloud Calendar actually do? Let’s walk through the core features. First up, you get shared calendars, which means you can have team-wide, project-specific, or role-based calendars that multiple people can view and contribute to. Next, there are event invitations with RSVP and attendance tracking, so when you send someone a calendar invite, you can actually see whether they’ve accepted, declined, or are still sitting on the fence. You also get recurring events, which are great for things like daily standups, weekly team meetings, or monthly finance reviews where you just set it once and it keeps showing up. Then there’s CalDAV sync, which we’ll talk more about in a moment, colour coding so you can visually tell your calendars apart at a glance, and full time zone support for when you’re working across different regions.

Now let’s look at how NZRT has structured its calendars. There are four main calendars set up. The first is the Team Calendar, owned by xc, with all team members having access. That one is used for company-wide events like public holidays and company announcements. The second is the Sales Calendar, owned by cas, used by the sales team to track client calls and demos. The third is the Finance Calendar, owned by fin, shared with fin and sun, and used for things like payment deadlines and month-end close activities. And the fourth is the HR Calendar, owned by han, shared with han and xc, covering onboarding schedules, performance reviews, and time-off requests. So depending on your role, you’ll likely be a member of one or more of these calendars, each colour coded and kept separate so the right information reaches the right people.

Now, one of the really useful things about Nextcloud Calendar is that it doesn’t just live inside the Nextcloud web interface. You can sync it directly to your phone or your desktop calendar app. There’s a section in the wiki that shows you how to do this, so let me walk you through what it describes. You start by opening your calendar app on iOS or Android, then you add a new account and choose CalDAV or CardDAV as the account type. From there, you enter the server address, which for NZRT is the internal Nextcloud address, then you put in your username and password using your LDAP credentials, the same ones you use to log in to Nextcloud. Once that’s done, your calendar app will automatically sync your events down to your device. So any event added to Nextcloud Calendar by a teammate will show up on your phone, and anything you create on your phone will push back up to Nextcloud. It keeps everything in one place without you having to manually check the web app every morning.

If you’re an Outlook user or you use Apple Calendar on a Mac, the same CalDAV protocol works there too. The process is similar, you point the app at the Nextcloud server using your credentials, and you get two-way sync from that point on.

From a broader NZRT perspective, the calendar isn’t just a standalone scheduling tool. It connects to how the whole organisation operates day to day. If you’re working on a Dolibarr project, you can align your calendar events with project milestones and deadlines. If you’re involved in the WordPress editorial side of things, calendar visibility helps coordinate content publishing schedules. And for the team doing Nextcloud maintenance, having a shared calendar means maintenance windows are visible to everyone before they happen, not after.

For fin and sun in particular, who manage payment schedules and vendor deadlines, the Finance Calendar is a practical tool for making sure nothing slips through the cracks at end of month when things tend to get hectic.

So whether you’re in sales tracking your client calls, in HR managing onboarding timelines, or in finance keeping an eye on payment due dates, Nextcloud Calendar gives your team a single, shared view of what’s happening and when. And with CalDAV sync, that view travels with you on whatever device you prefer to work on.

If you want to dig deeper, the wiki also links out to related notes covering the broader Nextcloud collaboration overview, Contacts, and the combined Email and CalDAV CardDAV integration guide, which is worth a read if you want to get everything connected at once.

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

000NCL, 02 - Collaboration Apps

Collaboration Overview

Welcome to the NZRT Wiki Podcast. Today we’re looking at Collaboration Overview.

If you’ve ever juggled Slack for chat, Zoom for video calls, Google Calendar for scheduling, Asana for task tracking, and a separate wiki for documentation — all while wondering why your team’s data is scattered across half a dozen external platforms — this episode is for you. At NZRT, the answer to that problem is Nextcloud’s built-in collaboration suite, and today we’re going to walk through what it includes, who uses it, and why it matters.

So let’s start with what the collaboration suite actually is. Nextcloud isn’t just a file storage platform. It ships with a set of apps — Talk, Calendar, Contacts, Deck, and Collectives — that together cover almost everything a team needs to communicate and coordinate. And because it’s all self-hosted within NZRT’s own infrastructure, your data stays inside the organisation. No third-party SaaS subscriptions, no data leaving the building, so to speak.

Let’s go through each of those apps one by one.

First up is Talk. This is your chat and video calling tool — and if you’re familiar with Slack or Zoom, Talk covers that same ground. You can send messages, hop on video calls, and share your screen, all from within Nextcloud. At NZRT, Talk is available to everyone across all roles, so it’s the go-to channel for real-time team communication.

Next is Calendar. This is a shared calendar and scheduling tool, similar to Google Calendar. At NZRT, it’s used primarily by xc, sun, and fin — so that covers the executive, the operations side, and the finance function. It keeps scheduling in one place without needing to hand your calendar data over to an external provider.

Third is Contacts. This is the team’s shared address book, and it also connects to CRM-style data. At NZRT, it’s used by xc, pam, and cas — the executive, the project and marketing agent, and the customer and sales agent. If you need to look up a contact or manage relationship data, Contacts is where you go.

Fourth is Deck. Think of this as NZRT’s Kanban board and task management tool — essentially the replacement for Asana. You can create boards, move tasks through stages, and keep project work organised visually. At NZRT, Deck is used mainly by pam and dan — the project agent and the data and analytics agent.

And fifth is Collectives. This is the team wiki and documentation tool. If you need to write up processes, maintain internal docs, or collaborate on written content, Collectives is the place for that. At NZRT, that’s xc, ema, and dai — the executive, the email and comms agent, and the data insights agent.

Now, beyond the individual apps, there are some integration benefits worth understanding, because this is where the suite really earns its place.

The first is single sign-on. Your directory credentials work across all of these apps, so you’re not managing separate logins for each tool. One set of credentials, everything connected.

The second benefit is file integration. Because these collaboration apps live inside Nextcloud, you can share files directly from a chat conversation or attach them to a task on your Deck board. There’s no copy-paste shuffle between a file storage app and your communication tool — it’s all in the same place.

Third is a unified notification hub. Rather than checking five different apps for alerts, Nextcloud consolidates notifications across Talk, Calendar, Deck, and the rest. You get a single stream of what needs your attention.

And fourth is API access. The Nextcloud collaboration apps support automation and third-party integrations, which means agents and scripts can interact with these tools programmatically. That’s important for NZRT’s agent-driven workflow, where automated processes need to read and write data across systems.

Stepping back, the bigger picture here is that all of this — chat, video, calendar, contacts, task boards, and documentation — stays within NZRT’s secure, self-hosted infrastructure. You’re not depending on Slack staying affordable, Zoom’s terms of service, or Google’s data practices. The organisation controls the environment, the data, and the access.

So whether you’re coordinating a project on Deck, catching up on messages in Talk, or pulling up a shared process document in Collectives, it’s all running on the same platform, under the same credentials, with the same security boundary.

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

000NCL, 02 - Collaboration Apps

Collectives Wiki

Welcome to the NZRT Wiki Podcast. Today we’re looking at 📖 Collectives (Wiki).

If you’ve ever needed a central place where your team can write, edit, and find documentation together, Nextcloud Collectives is exactly that. It’s a wiki platform built into Nextcloud, designed for collaborative team documentation. Think onboarding guides, standard operating procedures, runbooks — anything your team needs to know, all in one searchable, version-controlled place.

So what can you actually do with it? Let’s walk through the key features.

First, you get wiki pages. You can write using either a Markdown editor if you’re comfortable with plain text formatting, or a more visual WYSIWYG editor if you prefer something closer to a word processor. Your choice, depending on how you like to work.

Second, pages can be nested. That means you can organise your documentation into hierarchies — a parent page with child pages underneath it, and so on. If you’re familiar with how this Obsidian vault is structured, it works in a very similar way.

Third, Collectives supports real-time collaboration. Multiple people can co-edit a page at the same time, and there’s also a comments system so you can leave feedback or questions right on the document itself.

Fourth, every time someone edits a page, Collectives automatically saves a snapshot. That version history means you can always look back at what changed, when it changed, and roll things back if something goes wrong.

Fifth, you have flexible permission control. You can make a collective public, restrict it to a specific team, or keep it private. That gives you good control over who sees what, which matters when you’re mixing internal-only processes with content you might want to share more broadly.

And sixth, there’s full-text search across all your wiki content. So instead of hunting through folders, you can just search for a keyword and find the relevant page quickly.

Now, to give you a practical sense of what a page might look like, imagine a simple onboarding checklist. The page would have a main heading like Onboarding Checklist, then two sections underneath it. The first section covers IT Setup, and it lists three tasks — creating an LDAP account, which is handled by xc, adding the new person to Nextcloud groups, and issuing a laptop with VPN access. The second section covers Access, and it lists three more tasks — setting up a Dolibarr login handled by fin, granting access to the relevant Nextcloud shared folders, and sending Talk channel invitations. That kind of structured, actionable checklist is exactly the type of content Collectives is built for.

If you want to explore related areas, you might also look at the Collaboration Overview, the Document Management Overview, and the NZRT Folder Structure notes, which all connect to how Collectives fits into the broader way NZRT organises its information.

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

000NCL, 02 - Collaboration Apps

Contacts

Welcome to the NZRT Wiki Podcast. Today we’re looking at 📇 Contacts.

Nextcloud Contacts is our shared address book, and it’s the single source of truth for client and vendor data across the team. It supports CardDAV, which means your contacts can sync automatically to your phone, tablet, or Outlook — wherever you manage your address book day to day.

Let’s talk about what the Contacts app actually does for you. First, you get shared address books, so the whole team is working from the same up-to-date records rather than scattered personal lists. You can store custom fields too — things like deal stage, company name, and phone numbers that make it useful as a lightweight CRM. Contacts can be organised into groups, which makes it easy to filter and find who you need. And when it comes to getting data in or out, you can import and export using VCF or CSV formats.

Now, NZRT has four main contact groups set up. The first is Clients, which is maintained by the pam and cas agents and holds the customer database. The second is Vendors, looked after by sun and fin, covering all supplier contacts. Third is Employees — that’s the internal directory, maintained by han and xc. And fourth is Partners, which xc manages, covering integrations and external service providers.

One of the most important things to understand about Contacts is how it connects to Dolibarr, our ERP system. There are two ways this works. The first is an automated sync — Nextcloud Contacts and Dolibarr customers and suppliers are linked through the REST API, and a nightly task keeps them in step. So changes made in one place flow through to the other overnight. The second method is manual — you can download a CSV from Contacts and import it directly into the Dolibarr CRM. That’s useful for one-off bulk updates or when you need more control over what gets synced and when.

If you want to set up CardDAV on your mobile device, here’s how that works on iOS. You go into Settings, then Accounts, and add a new CardDAV account. The server address is your Nextcloud instance, and you log in with your LDAP username. Once that’s connected, your Nextcloud contacts will appear right alongside your regular phone contacts and stay in sync automatically.

Finally, a quick note on who owns what. The pam agent handles products, cas handles sales, and sun handles procurement. All three of them maintain contact records in Nextcloud, and those records sync through to Dolibarr where they’re used for invoicing and order management. So if you’re ever wondering where the authoritative version of a client or vendor record lives, it starts here in Contacts.

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

000NCL, 03 - Document Management

Document Management Overview

Welcome to the NZRT Wiki Podcast. Today we’re looking at the Document Management Overview.

If you work with documents at NZRT — and chances are you do — this episode covers how everything fits together. We’re talking about how Nextcloud’s document management tools and Dolibarr ERP work in tandem to keep contracts, invoices, and business records organized, versioned, and compliant.

Let’s start with the tools you have available inside Nextcloud. There are five key features in the document management suite. First up is Nextcloud Office, which runs OnlyOffice as an editor built right into the platform. That means you can create and edit documents — word processing files, spreadsheets, presentations — without ever leaving Nextcloud or touching an external cloud service. Everything stays in-house.

Next is the PDF Viewer. This one is more powerful than it sounds. You can annotate PDFs, highlight sections, add comments, and even sign documents. You can also preview a file before you download it, which saves you time when you’re hunting through a busy folder.

Then there’s Tagging. You can organize your documents with searchable tags — things like invoice, contract, or draft. This makes it much easier to find what you’re looking for without needing to remember exactly where you saved something.

Alongside tagging, you’ve got full-text Search. That means Nextcloud can look inside your documents — not just at filenames — and return results based on the actual content. Very useful when you know what a document says but not what it’s called.

And finally there’s Retention. This is an automated feature that removes old documents according to your defined policy. If something has a set lifespan, Nextcloud handles the cleanup for you without any manual work on your end.

Now let’s talk about how documents actually flow through NZRT. There’s a three-stage workflow. It begins in Dolibarr, where documents are created — things like invoices, contracts, and purchase orders originate in the ERP system. From there, they move into Nextcloud for storage and version control. Inside Nextcloud, the Files app handles the actual file storage, Nextcloud Talk supports approval conversations, and Nextcloud Deck helps with tracking where a document is in its lifecycle. The third stage is archiving. Documents that are ninety days old or older get moved out to external storage, and that includes a NAS backup for long-term retention.

Now let’s look at who owns what. There are five document types at NZRT, and each one has a designated owner, an approver, and a defined archive period. Invoices are owned by the finance agent and approved by xc, the executive controller, and they’re kept for seven years to satisfy legal requirements. Contracts are handled by the client and accounts services agent, also approved by xc, and retained indefinitely. Purchase orders belong to the supply and resources agent, are approved by the finance agent, and kept for three years. HR records are managed by the HR and admin agent, approved by xc, stored for seven years, and importantly they’re encrypted. And finally, reports are produced by the data and intelligence agent, approved by xc, and held for five years.

So why does all of this matter in the NZRT context? Document management sits right at the heart of the Dolibarr ERP workflow. Every invoice, contract, and purchase order that moves through the business ends up in Nextcloud for storage, versioning, and approval tracking. That’s not just about staying organized — it’s about staying compliant with both business requirements and legal obligations. Having a clear chain of ownership and defined retention periods means you always know where a document is, who approved it, and how long it needs to be kept.

If you want to go deeper on any of these topics, there are related notes in the wiki covering Nextcloud Office, the PDF Viewer, Tagging and Search, and the Dolibarr integration specifically. Each of those gives you more detail on the individual components covered today.

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

000NCL, 05 - Integrations

Dolibarr Integration

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Dolibarr Integration.

So let’s start with the big picture. Nextcloud and Dolibarr work together through a REST API connection combined with file sync. The goal is to let Dolibarr’s EDM module — that stands for Electronic Document Management — store its documents inside Nextcloud. By doing that, you get all of Nextcloud’s strengths: version history, sharing capabilities, and long-term archival, all feeding into the same documents your ERP system is working with.

Now let’s walk through what actually happens when you create an invoice. The workflow goes like this. First, you create an invoice inside Dolibarr. As soon as that happens, the system automatically saves a PDF copy of that invoice into a specific folder path in Nextcloud — something like Finance, then Invoices, then the year and month, then the invoice filename itself. Dolibarr then records that Nextcloud file path in its own database, so it always knows where the live copy lives. From that point on, you or your colleagues can open, version, or share that invoice directly inside Nextcloud, while Dolibarr keeps pointing to the same file. One document, two systems, no duplication of effort.

Let’s talk about the REST API side of things. There are two key calls that make this work. The first one handles authentication — it sends a request to Nextcloud asking for an access token, passing along a client ID and client secret. Think of it like knocking on the door and showing your credentials before you’re allowed in. The second call actually uploads a file. It uses a PUT request — that’s the web method for placing something at a specific location — and it sends the PDF file to a particular user’s folder path inside Nextcloud. The user and password are passed along with the request so Nextcloud knows who’s doing the uploading. That’s the core of how files move from Dolibarr into Nextcloud programmatically.

Now let’s look at how those files are organised once they’re in Nextcloud. There’s a top-level shared folder, and inside it sits a folder called Dolibarr EDM. Under that, you’ve got three main subfolders. The first is Invoices, which is further broken down by year and month — so April 2026 would have its own subfolder containing individual invoice PDFs like INV-001 and INV-002. The second subfolder is Contracts, which is organised by client — so Client A gets their own folder holding their contract and any amendments. The third subfolder is Purchase Orders, where PO files live in a flat structure by year and reference number. Clean, predictable, and easy to navigate.

Now here’s where the automation really shines — the nightly sync workflow. Every night at two in the morning, a scheduled process kicks off a five-step routine. Step one: it queries the Dolibarr API to find any documents that are new or have been updated since the last run. Step two: it checks Nextcloud to see if any of those documents already exist, so nothing gets duplicated. Step three: any files that are missing from Nextcloud get uploaded. Step four: Dolibarr’s file path references get updated to reflect the current locations. Step five: any documents older than ninety days get moved off to a NAS — a network-attached storage system — for long-term archiving. And at the end of all that, an email report goes out to the Finance role and the EDM role so the right people know what happened overnight. The whole thing runs without anyone needing to touch it.

Finally, a word on how this fits into NZRT specifically. This Nextcloud and Dolibarr connection is described as the backbone of NZRT’s document management. Three roles interact with it most closely. Finance, referred to internally as fin, handles invoices. The EDM role, referred to as ema, manages the document flows. And the Admin role, xc, oversees the whole thing. All three roles collaborate on invoices, contracts, and purchase orders through this single integrated system — so there’s one source of truth rather than files scattered across different tools.

If you want to dig deeper, there are three related wiki pages worth checking out: the Integrations Overview, the REST API and WebDAV guide, and the Document Management Overview. Those will give you more context on the broader architecture this integration sits within.

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

000NCL

Email Caldavcarddav

Welcome to the NZRT Wiki Podcast. Today we’re looking at Email & CalDAV/CardDAV.

If you’ve ever wondered how your Nextcloud calendar and contacts end up on your phone or in your email client without going through Google or Microsoft’s cloud, this episode is for you. The answer is two open protocols called CalDAV and CardDAV, and Nextcloud supports both out of the box.

Let’s start with CalDAV. The protocol is defined under RFC 4791 and it’s the standard that lets calendar apps talk to a server over the web. On the NZRT setup, the endpoint for calendar sync sits at the Nextcloud server address, followed by a path that includes the word “dav”, then “calendars”, then “users”, and then the specific username. So every user gets their own calendar path on that server.

Setting it up on iOS, Android, or Outlook follows the same basic flow regardless of the app. You go into your device or app’s settings, find the calendar section, choose to add an account, and select CalDAV as the account type. You enter the server address, which is the Nextcloud server hostname, your LDAP username, and your LDAP password. Once you save that, the client auto-discovers all the calendars tied to your account. That’s it. No third-party service involved.

Now for contacts, the protocol is CardDAV, defined under RFC 6352. The server path is almost identical to the calendar one, except instead of “calendars” in the URL you’ll see “addressbooks”. The credentials are exactly the same as CalDAV, so you’re using your LDAP username and password again. On Apple Contacts or Android, you go into the contacts settings, add an account, choose CardDAV, enter those same details, and from that point on all your Nextcloud Contacts groups sync down to the device.

For desktop email clients like Outlook or Thunderbird, the calendar subscription works slightly differently. Instead of adding an account, you typically go into the calendar area, find an option to subscribe to a calendar, and paste in the full URL for the specific calendar you want. That URL includes the server address, the same dav path, and then the calendar name at the end. You authenticate with your LDAP credentials and the calendar appears alongside your other calendars in the client.

Now let’s talk about how the sync actually behaves once everything is connected. It runs two ways, meaning changes you make in Nextcloud show up on your phone, and changes you make on your phone sync back to Nextcloud. By default the sync happens roughly every fifteen minutes, though that interval is configurable if you need it more or less frequent. If two devices edit the same event or contact at the same time, the system uses a last-write-wins approach, so whichever change was saved most recently is the one that sticks.

From an NZRT perspective, this setup is particularly useful for keeping the sales team, the finance team, and HR in sync across desktop and mobile. Because everything goes through the internal Nextcloud server, you’re not routing calendar data through external services like Google Calendar or Outlook cloud. Your scheduling data stays within the NZRT environment.

If you want to dig deeper into any of the pieces that make this work, the related topics to look up in the wiki are Calendar, Contacts, and the REST API and WebDAV page.

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

000NCL, 01 - Files & Storage

Encryption

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Encryption.

If you’ve ever wondered how your files stay safe when they’re sitting on a server or moving across the internet, encryption is the answer. Nextcloud gives you a couple of different ways to protect your data, and today we’re going to walk through what those options are, how they work, and how NZRT uses them in practice.

Let’s start with the basics. There are three types of encryption you’ll encounter in Nextcloud. The first is server-side encryption. This protects your files while they’re sitting at rest on the disk, so if someone were to physically steal the hardware, they wouldn’t be able to read your files. It’s great for general file storage. The second type is end-to-end encryption, often called E2EE. This one goes further — it means only users who hold the right decryption keys can ever read the content. Even Nextcloud itself cannot see inside those files. This is the one you want for truly sensitive data. The third type is TLS, which is the encryption that protects your data while it’s travelling across the network. This applies to all traffic and guards against anyone trying to intercept data as it moves between your device and the server.

So to summarise those three: server-side protects files at rest from hardware theft, end-to-end protects from a server breach because not even the server can read it, and TLS protects everything in transit from network snooping.

Now let’s talk about how you actually set up end-to-end encryption. There’s a command-line step involved here. What the setup does is first enable the encryption app on the Nextcloud server — that’s done through the admin apps panel using a server command that activates the encryption module. From there, you can configure specific folders to use encrypted sharing, which involves setting a key passphrase for that folder. So you’re not encrypting everything blindly — you choose which folders get the extra protection.

At NZRT, two folders are currently set up with end-to-end encryption. The first is the HR Payroll folder, which is encrypted and accessible only to the Finance agent and the HR agent. The second is the Finance Bank folder, which is encrypted and restricted to the Finance agent alone.

Now here’s an important decision you’ll need to make when setting up encryption: do you use a Master Key or User Keys? With the Master Key approach, there’s a single key that covers all files. It’s simpler to manage and faster to work with, but it’s less secure because there’s one point of failure. With User Keys, every user has their own unique key. This means you get true end-to-end encryption because no single key can unlock everything. The tradeoff is more overhead to manage.

For NZRT, the approach is split depending on what you’re protecting. For the HR and Finance folders — the ones handling payroll, contracts, and bank statements — User Keys are used. That’s the stronger option and the right call for that level of sensitivity. For general documents that don’t carry that same risk, the Master Key approach is used, which keeps things simpler without unnecessary complexity.

One more important point on key management. At NZRT, encryption keys are not stored on the Nextcloud server itself. They’re backed up in a secure vault separately. This matters because if the server were ever compromised, the keys wouldn’t be sitting there alongside the encrypted files. That separation is a deliberate security decision.

To bring it all together: Nextcloud gives you layered encryption options. TLS handles your data in motion. Server-side encryption handles your data at rest. And end-to-end encryption handles your most sensitive data by making it unreadable to everyone except the people who hold the keys. NZRT uses all three layers, with end-to-end encryption and User Keys specifically applied to HR and Finance workflows where the stakes are highest.

If you want to dig deeper, related topics include File Sharing and Links, Users and Groups, and Backups and Maintenance — all covered in the NZRT wiki.

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

000NCL, 01 - Files & Storage

External Storage

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud External Storage.

So what exactly is external storage in the context of Nextcloud? In simple terms, it is a feature that lets Nextcloud connect to remote file systems and present them to you as regular folders inside the Nextcloud interface. Think of it like a bridge between Nextcloud and storage that lives elsewhere on your network or out in the cloud. Instead of switching between different tools to reach a NAS drive, an FTP server, or a cloud storage bucket, you can see it all in one place through Nextcloud. For NZRT, this is particularly useful because it means the team can access legacy storage and backups without ever leaving the Nextcloud environment.

Let’s talk about what kinds of storage Nextcloud can connect to, because the list is pretty broad. You have SMB and CIFS, which are the protocols used by Windows file shares and popular NAS devices like Synology, QNAP, and TrueNAS. You have NFS, which stands for Network File System and is commonly used with Linux-based NAS setups. There is FTP and SFTP for connecting to remote servers. You have S3 and Swift for cloud object storage. And finally, WebDAV, which lets you connect to another Nextcloud instance or any other WebDAV-compatible server. So whatever storage you are working with, there is a good chance Nextcloud can mount it.

Now let’s look at how NZRT has this set up in practice. The main example is a NAS mount using the SMB protocol. To configure this, you would go into the Settings area and navigate to External Storage. From there, you define a mount point. In NZRT’s case, that mount point is a folder called NAS Archive. You select SMB as the connection type, then provide the host address, which points to the NAS device on the local network. You specify which share on that NAS you want to mount, in this case the archive share. You enter a username and a securely stored password for authentication. And finally, you control which users or groups can see this mount. For NZRT, it is made visible to the finance team, the EDM group, and the Dan user role. That is the entire configuration in a nutshell. A handful of fields, and the storage appears as a folder inside Nextcloud.

Now why would you bother doing this instead of just accessing the NAS directly? There are some solid practical benefits. First, centralized access. Your team does not need separate tools or credentials to get into the NAS. They reach it through Nextcloud just like any other folder. Second, transparent versioning. Nextcloud’s versioning features still apply to files on the NAS, so you get that version history even for files that physically live on external storage. Third, unified sharing. You can use Nextcloud’s permission system to control who sees what on the NAS, rather than managing access separately at the NAS level. And fourth, archive integration. For NZRT specifically, old Dolibarr documents stored on the NAS become accessible through Nextcloud without anyone needing to know where those files physically sit.

In terms of who manages all of this at NZRT, that responsibility falls to the DBA role, which maps to the Dan role on the team. Dan is the person configuring and maintaining these external storage connections.

The bigger picture here is that External Storage is one of the key ways NZRT bridges its newer cloud-first infrastructure with older legacy systems. Not everything lives in Nextcloud natively, and not everything needs to be migrated. External Storage lets you meet your existing storage where it is and bring it into a unified interface, without disrupting anything that is already working.

If you want to go deeper, the Files App documentation, the Administration Overview, and the WebDAV Cheatsheet are all related wiki notes worth exploring.

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

000NCL, 02 - Collaboration Apps

Deck Kanban

Welcome to the NZRT Wiki Podcast. Today we’re looking at ?? Deck (Kanban).

If you’ve ever used a physical sticky-note board to track work — with columns for To Do, In Progress, and Done — you already understand the concept behind Nextcloud Deck. Deck is NZRT’s built-in Kanban tool, living right inside Nextcloud, and it’s how our teams organise and track tasks and projects without needing any external software.

Let’s start with how Deck is structured. At the top level, you have boards. A board is your project workspace — think of it as the whole whiteboard. Inside each board, you have columns, which represent the stages of your workflow. Out of the box you might have To Do, In Progress, and Done, but you can customise these to match however your team actually works.

Inside those columns, you have cards. A card represents a single task or work item, and each card can hold quite a bit of information. You can write a description, set a due date, assign it to a specific person, attach labels for easy filtering, and link files directly to the card. So if a task needs a document or spreadsheet, it travels with the card. Cards also have a comments section, which means your whole team can collaborate and leave notes directly on the task — keeping everything in one place rather than scattered across emails.

Beyond the cards themselves, Deck also tracks activity. You can see a history of who moved a card, when they moved it, and what changed. That audit trail is really useful when you need to understand the progress of a project or figure out where something got held up. Boards can also be shared with individual team members, with groups, or made publicly accessible — so you have real flexibility in how you open your workflow up to the people who need it.

Now let’s talk about how NZRT specifically uses Deck. There are five active boards across the team. First, the Marketing Pipeline — owned by pam and used by the Products team for campaign planning. Second, Sales Deals — owned by cas, used by the Sales team to track deal progression. Third, Procurement — owned by sun, where the Procurement team tracks purchase orders. Fourth, Tech Projects — owned by dan on the DBA team, covering system upgrades and Nextcloud maintenance. And fifth, the Editorial Calendar — owned by ema on the EDM team, used to plan and schedule WordPress and blog publishing.

To give you a concrete sense of what a card actually looks like, imagine one titled “Prepare Q2 Sales Report”. It has a description explaining the work — aggregating CRM data and creating visualisations. It is assigned to cas in the Sales role. It has a due date set, labels applied for sales, reporting, and urgency, and a file attached — a sales report template pulled from the Finance folder in Nextcloud. Then there is a comments area where team members can check in and collaborate as the task moves forward.

One of the biggest wins for NZRT with Deck is that it removes the need for external project management platforms. Tools like Asana or Monday dot com are no longer needed, because Deck provides the same core functionality right inside Nextcloud, where your files already live. For the Products team, the Sales team, and the DBA team in particular, Deck has become the go-to for daily task tracking — and it has replaced a lot of the email-based back-and-forth that used to slow things down.

If you want to dig deeper, check out the related wiki pages on the Collaboration Overview, the Files App, and NZRT User Roles and Agents. Those will give you more context on how Deck fits into the broader Nextcloud environment and how the different team members interact with it day to day.

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

000NCL, 01 - Files & Storage

File Sharing Links

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud File Sharing and Links.

If you’ve ever needed to get a document to a client quickly, or make sure only the right people inside your organisation can see a sensitive file, then this is the episode for you. Nextcloud gives you a surprisingly fine level of control over who sees what, how long they can see it, and what they can actually do with it once they have access.

Let’s start with the four main ways you can share something in Nextcloud.

The first is a user or group share. This is your standard internal share where you’re giving a specific person or a team direct access. Think of it as internal team collaboration — the people you share with log in and see the file in their own Nextcloud account.

The second type is a public link. This is what you’d use for external sharing, like sending something to a client or making a file available for download without the recipient needing a Nextcloud account. Public links can be protected with a password and given an expiry date so they don’t stay active forever.

The third type is called a federated share. This one’s a bit more advanced — it lets you share files across completely separate Nextcloud instances. So if a partner organisation runs their own Nextcloud server, you can share directly with them without emailing attachments back and forth.

And the fourth type is resharing. This is where someone you’ve shared a file with can then share it on to someone else — a kind of delegation of access. This can be useful but it’s worth being aware of when you allow it, since it means your original share can spread further than you intended.

Now, when you create a public link, there are several settings you can configure. Imagine you click the share button in Nextcloud and choose to create a link. What you’re looking at is a panel that lets you set an expiry date — by default, seven days from creation. You can also set a password so that only someone with that password can open the link. You control the permissions, which by default are set to view only, meaning the recipient can look at the file but not edit it. And you can choose to notify someone by email so they get the link sent directly to them. A key best practice here: if you’re sharing a sensitive document, consider disabling the download option entirely and keeping it in view-only mode. That way the recipient can read it but can’t save a local copy.

Now let’s talk about how different teams at NZRT actually use these sharing features in practice.

For the sales side of things, the agent known as cas uses public links when sharing contracts with clients. Those links are set with a thirty-day expiry, which gives clients enough time to review without leaving links active indefinitely.

Finance, handled by fin, takes a much more restricted approach. Invoices and financial documents are shared only via direct user shares — no public links at all. That keeps sensitive financial data inside the system and away from the open web.

Human resources, managed by han, goes one step further for things like payroll data. Those shares use end-to-end encryption, which means the content is encrypted on your device before it even reaches the server. Only the intended recipient can decrypt and read it.

And then there’s ema, who manages document retention. Rather than letting old shared files pile up forever, ema applies retention policies that automatically delete documents after ninety days. This is a really useful practice for keeping the file system clean and making sure old shared links don’t become a security risk down the line.

Stepping back and looking at the bigger picture for NZRT as a whole: the goal of all this is to make sure the right things are accessible to the right people, for exactly as long as they need to be. Dolibarr invoices and HR records stay locked down through user-only or encrypted shares. At the same time, external parties like clients and vendors can still get what they need through time-limited public links that expire automatically.

If you want to go deeper on any of this, there are three related topics worth exploring in the wiki. The Files App covers how to navigate and manage your files day to day. The Encryption page goes into detail on how end-to-end encryption works and when to use it. And the Permissions and Sharing page gives you the full breakdown of what each permission level actually allows a recipient to do.

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

000NCL, 01 - Files & Storage

Files App

Welcome to the NZRT Wiki Podcast. Today we’re looking at the Nextcloud Files App.

If you’ve ever wondered where all the team’s documents live and how they stay organised, this is the episode for you. The Nextcloud Files App is the core file management interface — your central hub for uploading, organising, sharing, and collaborating on files across the business.

Let’s start with what it can do. First, you’ve got a web interface and a desktop client, so you can upload, download, and sync files across your devices whether you’re at your desk or on the go. There’s also sharing built right in — you can create public links or share directly with specific users or groups, and you can attach expiry dates and password protection to those links for added control. The app supports tagging too, which lets you label your files with keywords that are searchable across the entire vault, making it much easier to find things when you need them. Versioning is another powerful feature — Nextcloud automatically keeps a history of your files, so if something gets changed or overwritten by mistake, you can go back and restore a previous version. For sensitive material, end-to-end encryption is available, meaning only the intended recipients can read the content. And finally, there’s an activity feed that tracks who changed what and when, giving you full visibility over everything happening in your file space.

Now let’s talk about how files are actually organised. The recommended folder structure has three top-level areas. The first is a Shared folder, which is designed for team collaboration. Inside it you’ll find subfolders for Finance, HR, Sales, and Projects — think of this as the communal workspace where multiple people need access. The second top-level area is a Documents folder, which is your personal storage space. It contains subfolders like Invoices and Reports, things that belong to you individually. The third area is an External folder, which connects to storage outside of Nextcloud itself, such as a NAS backup device. So to summarise: Shared for the team, Documents for yourself, and External for anything coming in from outside the platform.

Now for the NZRT-specific context, and this is important if you’re part of the team. The Files App doesn’t operate in isolation. It integrates directly with Dolibarr, NZRT’s ERP system, which means invoices, contracts, and purchase orders can be stored here and referenced from there. It also connects with WordPress, so media assets and blog drafts can flow through Nextcloud straight into the website. The person responsible for managing folder structure and permissions across all of this is the EDM role, which in NZRT’s agent framework corresponds to the ema agent.

If you want to dig deeper, the wiki links out to related articles on External Storage, File Sharing and Links, Versioning and Trash, and Encryption — each with its own dedicated page.

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

000NCL, 05 - Integrations

Integrations Overview

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Integrations Overview.

If you’ve ever wondered how Nextcloud fits into the broader NZRT tech stack, this is the episode for you. Nextcloud doesn’t just sit on its own — it connects to a whole range of other systems, and today we’re going to walk you through what those connections are, how they work, and why they matter.

Let’s start with the big picture. Nextcloud integrates with four main categories of systems: Dolibarr, which is our ERP platform; WordPress, our content management system; email systems for calendar and contact syncing; and external storage like network-attached storage devices for backup and archiving. On top of those, you can also build custom integrations using Nextcloud’s REST API and webhook support.

Now let’s talk about the integration types in a bit more detail. There are five main ones to know about.

First, the Dolibarr integration. This uses a combination of REST API calls and file synchronisation. The main use case here is electronic document management — what we often call EDM — along with document versioning. So when documents are created or updated in Dolibarr, they can flow into Nextcloud and be properly version-controlled.

Second, the WordPress integration. This also uses the REST API, plus LDAP for directory services. The use cases are user synchronisation — so your user accounts stay consistent across both platforms — and media asset management.

Third, email integration. This one uses the CalDAV and CardDAV protocols. If those sound unfamiliar, think of CalDAV as the standard way calendar data is shared over the internet, and CardDAV as the same idea but for contact information. So through this integration, your calendar events and contacts can stay in sync between Nextcloud and your email system.

Fourth, external NAS integration. NAS stands for Network-Attached Storage — basically a dedicated file server on your network. Nextcloud connects to these using SMB or NFS protocols, which are standard network file-sharing protocols. The use case is backup and archive storage, so older or less-accessed data can be offloaded to external storage while still being reachable through Nextcloud.

Fifth and finally, custom app integrations. These use the REST API combined with webhooks. Webhooks are a way for one system to notify another in real time when something happens — think of them as event triggers. This category is for building your own automation workflows on top of Nextcloud.

Now let’s look at how all of this fits together architecturally. The code block in the wiki shows a hub-and-spoke diagram. Picture Nextcloud at the centre. Radiating out from that hub, you have five connections. Dolibarr sits on one branch, handling ERP data and electronic document management. WordPress is on another, covering user sync and media. Email connects for calendar and contacts. External NAS branches off for archive backup. And custom webhooks extend outward for workflow automation. Nextcloud is the connective tissue holding all of these systems together.

So how does authentication work across all these integrations? There are four methods you might encounter. The first is LDAP and single sign-on, which gives you a unified user directory — one set of credentials that works across systems. The second is API tokens, used by service accounts for automated processes. If a script or agent needs to talk to Nextcloud without a human logging in, it uses a token. The third is OAuth2, the standard for letting third-party apps authenticate securely without exposing passwords. And the fourth is basic authentication — plain username and password — which is considered a legacy approach and is not recommended for new integrations.

Why does all of this matter for NZRT specifically? The core goal is eliminating data silos. Without these integrations, documents in Dolibarr wouldn’t talk to storage in Nextcloud, and media in WordPress would be disconnected from everything else. With these connections in place, an invoice generated in Dolibarr can be stored and versioned in Nextcloud. Media assets in WordPress can be sourced directly from Nextcloud. And custom automation via the API and WebDAV layer means your EDM workflows can be built to fit exactly how NZRT operates, rather than forcing you to work around the tools.

If you want to go deeper, the related docs to look up are the Dolibarr Integration note, the WordPress Integration note, the Email and CalDAV CardDAV note, and the REST API and WebDAV note. Each of those covers the specifics of how those individual connections are configured and maintained.

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

000NCL, 04 - Users & Security

Ldap Sso

Welcome to the NZRT Wiki Podcast. Today we’re looking at LDAP and SSO.

If you’ve ever wondered how a company manages logins across multiple systems without asking staff to juggle half a dozen different passwords, LDAP and Single Sign-On are the answer. Let’s walk through how NZRT uses these technologies to connect Nextcloud, Dolibarr, and WordPress under one unified identity system.

First, let’s cover what LDAP actually is. LDAP stands for Lightweight Directory Access Protocol. Think of it as a central address book for your organisation. It stores user accounts, passwords, and group memberships in one place. That central store is usually either Active Directory, which is Microsoft’s directory service, or OpenLDAP, which is the open-source equivalent. When Nextcloud is connected to LDAP, it doesn’t manage its own user accounts — it asks the directory instead.

So how do you get that connection set up? The first step is enabling the LDAP app inside Nextcloud. There’s a command you run on the server to activate it, and once that’s done you head into the Settings area and look for the LDAP or Active Directory section. From there you configure a handful of key details. You tell Nextcloud the address of your LDAP server — in NZRT’s case that’s an internal address on the local network. You give it what’s called a Base Distinguished Name, which is the root of your directory tree, essentially your organisation’s domain broken into components. You also provide a Bind account — a dedicated service account Nextcloud uses to authenticate with the directory — and then you point it at where your users and groups live within that directory structure.

Now let’s talk about SSO, or Single Sign-On. This is what makes the experience seamless for your users. Once LDAP is connected, a user logs in once and that credential works across all integrated systems. For more advanced setups — say you’re connecting multiple identity providers or need enterprise-grade federation — there’s also a SAML option. SAML is a standard for exchanging authentication data between systems. Enabling that app and pointing it at your SAML metadata in the Security settings gets you there, but for most NZRT scenarios the core LDAP integration handles the heavy lifting.

One thing worth understanding is how groups flow across the integration. In your LDAP directory, groups have names like admin, sales, finance, and HR. When those groups sync into Nextcloud, they map directly to matching Nextcloud groups with the same names. Your admin group in Active Directory becomes the admin group in Nextcloud. Your finance team in Active Directory becomes the finance group in Nextcloud, and so on for sales and HR. You don’t have to manually rebuild your organisational structure inside each application — it comes across automatically.

Now let’s look at why this actually matters in practice. There are four key benefits. The first is a single password. When a user changes their LDAP or Active Directory password, that change flows through everywhere. They don’t need to update it separately in Nextcloud, Dolibarr, or WordPress. The second benefit is automated provisioning. When IT creates a new Active Directory account for a new hire, Nextcloud automatically picks that up and creates the corresponding user account — no manual steps needed. Third is deprovisioning. If someone leaves the organisation and IT disables their Active Directory account, their Nextcloud access is removed at the same time. You’re not relying on someone remembering to go into three different systems and disable the account manually. And fourth is group sync, which we already covered — your organisational structure stays consistent across every platform without extra effort.

For NZRT specifically, this integration spans Nextcloud, Dolibarr, and WordPress. The practical workflow is simple. When someone joins the team, IT creates one Active Directory account. From that single action, LDAP automatically syncs the user across all three systems. When they leave, one account gets disabled and access is revoked everywhere. That’s the power of centralised identity management — less administration overhead, fewer security gaps, and a much better experience for your users.

If you want to explore related topics, this wiki page connects to the Users and Groups documentation, the Two Factor Authentication guide, and the Dolibarr Integration notes.

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

000NCL, 06 - Administration

Logging Monitoring

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Logging & Monitoring.

Nextcloud generates logs constantly in the background, and understanding where those logs live and what they’re telling you is a core part of keeping the system healthy. At NZRT, logging ties directly into security auditing, performance monitoring, and catching issues before they become outages. So let’s walk through how all of this fits together.

First, let’s talk about where the logs actually are. There are five main log files you need to know about. The primary one is the Nextcloud application log, sitting at var www nextcloud data nextcloud dot log. This captures all Nextcloud events and is your first stop when something goes wrong. Next is the Apache access log at var log apache2 access dot log, which records every HTTP request hitting the server. Then the Apache error log at var log apache2 error dot log, which captures web server errors specifically. You also have the PHP-FPM log at var log php-fpm dot log for PHP-level errors, and finally the MySQL error log at var log mysql error dot log for anything going wrong at the database layer.

Now, how is logging configured? Inside Nextcloud’s main configuration file, there are a handful of settings that control this. The log type is set to file, so everything writes to disk. The log file path points to that nextcloud dot log location we just mentioned. There’s a log level setting that runs from zero to four — zero being debug, which logs everything including very verbose output, one for informational messages, two for warnings, three for errors, and four for fatal events only. NZRT runs at level two, so warnings and above get captured. The timezone is set to UTC for consistency, and there’s an automatic rotation setting — once the log file hits ten megabytes, it rolls over automatically so you’re not filling up your disk with a single enormous log file.

Next up is health checks. Nextcloud exposes a server info endpoint you can call to get a snapshot of system health. When you query that endpoint with admin credentials, the response tells you the current Nextcloud version, which PHP version and modules are loaded, the database connection status, current disk usage figures, how many users are active, and the state of background jobs. This is your go-to for a quick system pulse check, and it’s also something you can script to run on a schedule.

Speaking of schedules, let’s talk about monitoring thresholds. NZRT watches six key metrics. Disk usage triggers a warning at eighty percent and goes critical at ninety percent. Active concurrent users above one hundred is a signal to think about upgrading your plan. Database connections above eighty percent of the configured maximum need attention. Failed logins exceeding ten per hour are flagged as a potential attack. Background job queues with more than one hundred pending jobs indicate something is backed up. And Redis memory usage above eighty percent of its allocation means your cache is under pressure.

For alerting, there’s a bash script that runs on a cron schedule. What it does is check the current disk usage percentage for the Nextcloud data directory. If that number is above eighty, it sends an email alert to the admin address. It’s a simple but effective early warning for one of the most common failure modes — running out of space.

Now, how do you actually look at the logs day to day? You have two options. Through the web interface, you go into Settings, then Logging, and you’ll see the last entries displayed right there in your browser — no terminal needed. If you prefer the command line, you can stream the log live as events come in using tail, which is great for watching what’s happening in real time during a troubleshooting session. You can also search the log file for error entries and pull just the most recent twenty, which is usually enough to identify a pattern quickly.

To put this all in NZRT context — logging and monitoring aren’t just housekeeping. Failed background jobs can mean the Dolibarr sync isn’t running. A spike in failed logins could be a brute force attempt on the platform. Slow database queries show up in logs before they become user-facing problems. That’s why Dan, our DBA, reviews the logs on a daily basis. Catching something early in the logs is almost always cheaper than dealing with the downstream consequence.

If you want to go deeper, check out the related wiki notes on Administration Overview, Audit Logs, and the occ Command Reference. Those give you more detail on how to act on what the logs are telling you.

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

000NCL, 08 - Reference

Nextcloud Apps Directory

Welcome to the NZRT Wiki Podcast. Today we’re looking at 📱 Nextcloud Apps Directory.

So if you’ve been wondering what apps NZRT recommends layering on top of Nextcloud, this episode walks you through the full catalog — what each app does, who at NZRT uses it, and whether it’s considered essential or just optional.

Let’s start with the core communication apps. These are the ones that keep the team connected day to day. First up is Talk, which handles chat, video calls, and screen sharing — version 17 or higher, and it’s used by everyone across the org. Then you’ve got Calendar for shared scheduling, mainly used by xc, sun, and fin. Contacts gives you an address book and light CRM functionality, and that’s in the hands of xc, pam, and cas. Mail is also available for email integration, though it’s flagged as optional and mainly relevant to fin and han.

Moving into productivity and project management apps. Deck is a Kanban-style board for task management — think cards and columns — and pam, cas, sun, and dan all rely on it. Collectives is a wiki-style documentation tool, used by xc and ema for team knowledge bases. Nextcloud Office integrates OnlyOffice so you can edit documents right inside Nextcloud — that’s a core app for ema, fin, and pam. Tasks and Notes round out this category as optional tools available to everyone if they want lightweight to-do lists or quick note capture.

For file management, most of the heavy lifting comes from built-in apps. You’ve got the core Files app, Groupfolders for setting up team folders with proper permissions, External Storage for mounting things like NAS drives or S3 buckets, and then the usual suspects — Trash for the recycle bin, Versions for file history, and Sharing for passing files and folders around. All of these are available to everyone, with a few like Groupfolders and External Storage being managed by xc or dan.

Now security and admin — this section matters a lot. User LDAP connects Nextcloud to directory services for authentication. Two-Factor Auth enforces 2FA at the platform level. Suspicious Login watches for anomalous login patterns. Audit Logging keeps compliance records. And Brute-Force Protection throttles repeated failed login attempts. All of these are core and sit firmly in xc’s domain, with dan also involved in LDAP and audit logging. On top of those, you’ve got optional extras: OTP for one-time passwords, and FIDO2 WebAuthn if you want hardware key support.

Integration and automation apps are next. Webhooks let you trigger automation based on events inside Nextcloud — that’s useful for dan and ema. The REST API and WebDAV support are built in and used by everyone for file sync and system integrations. OAuth2 is available optionally for third-party authentication flows, managed by dan.

For search and performance, Full-Text Search with Elasticsearch integration lets you search inside documents, not just filenames — that’s recommended and looked after by dai and ema, with dan handling the Elasticsearch side. Redis is the caching backend and is core infrastructure managed by dan.

In the Office and Document category, Nextcloud Office appears again because it’s that central — ema and fin use it for document collaboration. PDF Viewer supports annotation and viewing, used by fin, cas, and han. Text is a plain text editor available to all as optional. Markdown Editor is also optional and mainly used by ema and dai.

For CRM and ERP integration, the REST API built into Nextcloud is what connects to Dolibarr and WordPress. Webhooks can be layered on top for event-driven sync. Both are managed by ema and dan.

Backup and disaster recovery wraps things up. There’s a Backup app for built-in backups managed by dan, and External Storage doubles as a backup mounting point for NAS.

There’s also a short list of apps NZRT does not recommend. Nextcloud Hub is noted as already built in, so no separate install needed. Pricing Plans is a SaaS-only concept that doesn’t apply here. Custom Apps require vetting before use. And Third-Party Cloud Storage is skipped in favour of the External Storage app instead.

Now, the wiki includes an installation script — and rather than reading you lines of code, here’s what it does in plain terms. It defines a list of recommended app names — things like talk, calendar, contacts, deck, collectives, the Nextcloud Office package, user LDAP, two-factor auth, suspicious login, full-text search, audit logging, and groupfolders. It then loops through that list one by one, installs each app, enables it, and prints a confirmation message so you can see what’s been set up. It’s a clean, repeatable way to get a fresh Nextcloud instance up to NZRT standard in one go.

To zoom out: the whole point of this app catalog is to make Nextcloud actually work for NZRT’s specific setup. That means tight Dolibarr integration via the REST API, team communication through Talk and Calendar, and solid document workflows through Office and PDF Viewer. Every app on the core list has a clear owner and a clear job.

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

000NCL, 08 - Reference

Nextcloud Cli Cheatsheet

Welcome to the NZRT Wiki Podcast. Today we’re looking at 🎯 Nextcloud CLI Cheatsheet.

If you manage a Nextcloud installation, you’ll quickly discover that the command line is your best friend. Nextcloud ships with a built-in tool called occ — short for ownCloud Console — and it handles just about everything you’d ever need to do from the server side. Let’s walk through the key things you can do with it.

Starting with user management. You can create a new user, delete one, or just pull up a list of everyone on the system. If someone forgets their password, there’s a command to reset it. You can also temporarily block a user from logging in by disabling their account, then re-enable them when needed. Setting storage quotas is straightforward too — you specify the user and a size value, and Nextcloud enforces that limit. You can also check when a user last logged in, which is handy for auditing inactive accounts.

Group management works in a similar way. You create a group by name, add users to it, remove users from it, and delete the group when it’s no longer needed. There are commands to list every user inside a specific group, and also to look up which groups a particular user belongs to — both directions covered.

For app management, occ lets you install, enable, disable, update, and remove apps without touching the web interface. You can list everything currently installed, check info on a specific app, or update all apps in one go. This is especially useful when you’re doing maintenance windows and want to script the whole thing.

File management is where things get really practical. If you’ve added files directly to the server — bypassing the web upload — Nextcloud won’t know they exist until you run a file scan. You can scan all users at once or target a specific user. There’s also a cleanup command that permanently removes trash items older than thirty days, a cache check for flagging file database inconsistencies, and commands to transfer all of one user’s files to another user, or to clear the file cache entirely.

On the database side, there are a few important housekeeping commands. One converts the file cache table to support larger integer values, which is something you’ll need on big installations. Another checks for and adds missing primary keys. You can also run raw database queries directly through occ if you need to inspect table sizes or check on the database state.

Configuration management is powerful. You can get or set configuration values for any app, delete config keys you no longer need, or list all configuration currently active on the system. System-wide settings work the same way — for example, you can read or update the list of trusted domains that Nextcloud will respond to.

Maintenance mode is something you’ll use before any major update or restore. One command turns it on, blocking all user access, and another turns it off again. You can also check the current system status, find out where the data directory lives, and get help on any specific command if you’re unsure of its options.

For sharing, you can list all active shares on the system, create a new share pointing to a file or folder, delete a share by its ID, or transfer share ownership from one user to another. This is useful when staff members leave and you need to reassign their shared content cleanly.

Logging and monitoring are covered too. Rather than using occ directly for logs, you’ll tail the main Nextcloud log file — you can view the last fifty lines, watch it in real time as events come in, or search it for error-level entries specifically. Background jobs have their own set of commands: you can check the queue status, list pending jobs, or manually trigger one job to run immediately.

Backup and restore rely on standard Linux tools alongside occ. For the database, you use mysqldump to export everything to a SQL file, and then restore by piping that file back into MySQL. For the Nextcloud application directory itself, you compress it into a tar archive for backup and extract it to restore. Always combine both steps — database and files — for a complete backup.

Finally, if you’re running LDAP for centralised user authentication, occ has you covered there too. You can test whether your LDAP connection is working, view the current LDAP configuration, sync users and groups from your directory, and inspect the mapping between LDAP entries and Nextcloud accounts.

At NZRT, both xc as the admin and dan as the DBA work with these commands regularly — for provisioning new users, managing groups, running maintenance, and troubleshooting issues as they come up. If you want to go deeper, the related notes in the wiki cover the full occ command reference and the administration overview.

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

000NCL, 03 - Document Management

Nextcloud Office

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Office.

If you’ve ever wished you could edit a Word document, a spreadsheet, or a presentation without leaving Nextcloud — that’s exactly what Nextcloud Office gives you. It integrates OnlyOffice directly into the Nextcloud interface, so everything stays on NZRT’s own infrastructure. No Microsoft Office subscription, no Google Docs, no third-party SaaS tools — just your files, in your cloud, with a full-featured office editor built right in.

Let’s start with what file types you can work with. On the document side, you’ve got the standard Word formats — docx, odt, and doc — so whether you’re coming from Microsoft Word or LibreOffice, you’re covered. For spreadsheets, you can open and edit xlsx, xls, and ods files. And if you need to work on a presentation, pptx, odp, and ppt are all supported. That covers the formats most teams will ever need.

Now let’s talk about what you can actually do inside those files. Nextcloud Office supports real-time collaboration, which means multiple people can be editing the same document at exactly the same time. You can see where everyone else’s cursor is sitting, live, as they type. That’s the co-editing feature, and it’s particularly useful when your team is spread across locations.

There’s also a comments and change tracking system built in. You can leave comments, make suggestions, and have other people review and accept or reject those changes — the same workflow you’d expect from a mature office suite. And if something goes wrong, or you just want to see what a document looked like before the last round of edits, version history has you covered. Nextcloud takes automatic snapshots before each edit session, so you’ve always got a trail to roll back to.

One more thing worth mentioning — mobile support. If you’re on a tablet and need to review or edit a document on the go, the Nextcloud mobile app gives you access to Nextcloud Office as well. So you’re not tied to a desk.

Now, NZRT has a set of standard document templates stored in the Shared Templates folder. There are four of them. First, a budget spreadsheet used by the finance team for budgeting work. Second, a Word document for legal contracts. Third, a presentation file used by the sales team for putting together proposals. And fourth, another Word document for standard operating procedures. If you’re creating any of those kinds of documents, start from the template rather than from scratch.

Let me touch briefly on how Nextcloud Office gets configured under the hood. There’s a command-line tool that Nextcloud uses for administration. To get Nextcloud Office running, you first enable an application called richdocuments — that’s the connector between Nextcloud and the OnlyOffice engine. Then you tell Nextcloud where the OnlyOffice document server is running. In NZRT’s setup, that server runs locally, and the configuration just points Nextcloud at its address. Once those two steps are done, the editor becomes available to everyone in Nextcloud automatically.

From an NZRT operations perspective, this matters because it removes the need for Microsoft Office licenses entirely. The finance agent, the sales agent, and the EDM agent all work directly in Nextcloud on budgets, proposals, and contracts. Version history means every change is tracked, giving you a clear audit trail of who edited what and when — and that matters a lot for any document with legal or financial weight.

If you want to dig deeper, there are related wiki pages on Document Management Overview, Tagging and Search, and Versioning and Trash — all of which connect to how Nextcloud Office fits into the broader document workflow at NZRT.

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

00 - Nextcloud Overview, 000NCL

Nextcloud Overview

Welcome to the NZRT Wiki Podcast. Today we’re looking at 📚 Nextcloud Overview.

So, what is Nextcloud? At its core, Nextcloud is an open-source platform that handles file hosting, team collaboration, and communication — all in one place. Think of it as NZRT’s self-hosted alternative to something like Google Workspace or Microsoft 365. The key word there is self-hosted, which means NZRT owns and controls the infrastructure rather than relying on a third-party cloud provider. That matters for privacy, security, and integration flexibility.

For NZRT specifically, the Nextcloud instance runs on the Hoopla cPanel server — that’s the live, online server, not anything local. You can reach it at cloud dot nzrtnetwork dot com forward slash nextcloud. If you’re on the desktop, you’ll also find it synced locally to a folder called Nextcloud2 under the main user profile. So changes you make on the server show up on your machine and vice versa — that’s the sync client doing its job.

Now let’s walk through what Nextcloud actually does. There are six main capability areas worth knowing.

First, file sync and sharing. This is the bread and butter. You get cross-platform sync clients, so whether you’re on Windows, Mac, or mobile, your files follow you. You can create secure sharing links and set granular permissions, meaning you can control exactly who can view, edit, or download a file.

Second, collaboration tools. Nextcloud includes a built-in chat feature called Talk, which handles both text messaging and video calls. There are also shared calendars and something called Deck, which is a task board tool — similar to Trello if you’ve used that. So team coordination happens inside Nextcloud without jumping to external apps.

Third, the office suite. Nextcloud integrates with OnlyOffice, which lets you create and edit documents, spreadsheets, and presentations directly in the browser. No sending files to Google Docs or Microsoft 365 — it all stays within the NZRT ecosystem.

Fourth, document management and Dolibarr integration. This is a big one for NZRT. Nextcloud syncs with Dolibarr, which is the ERP system used for invoices, contracts, and project management. That connection means documents like invoices and contracts can be stored in Nextcloud with full version control, and Dolibarr can reference or manage them through its document module. It creates a proper approval and versioning workflow without manual file juggling.

Fifth, the API and WebDAV support. Nextcloud exposes a RESTful API and supports the WebDAV protocol. In plain terms, that means other systems and automation scripts can talk to Nextcloud programmatically — uploading files, reading folder contents, creating share links, all without a human clicking through the interface. This is how NZRT’s agents and scripts interact with Nextcloud behind the scenes.

Sixth, security. Nextcloud offers end-to-end encryption for sensitive files, supports single sign-on and LDAP directory integration, two-factor authentication, and keeps audit logs so you can track who accessed or changed what.

Now, zooming out to the NZRT picture — Nextcloud sits at the centre of NZRT’s self-hosted infrastructure and acts as the collaboration backbone. It’s the central file hub that the whole team works from, which means there’s no dependence on external cloud services for day-to-day document work. It bridges into Dolibarr for things like invoice storage, contract versioning, and document approval workflows. It also ties into WordPress, helping manage media assets and supporting author collaboration on content. And as mentioned, the Talk feature replaces external chat tools like Slack for internal team communication. Calendars and contacts round it out, feeding into scheduling and CRM use cases.

The service code for Nextcloud within NZRT’s systems is 000NCL — you’ll see that referenced in tickets, repos, and documentation whenever something relates to the Nextcloud platform.

If you want to go deeper, there are related wiki notes covering the architecture and tech stack, installation and setup, the admin dashboard, and NZRT-specific Nextcloud configuration. Those are worth exploring if you’re working on anything infrastructure-related or need to understand how the system was put together.

The short version: Nextcloud is NZRT’s self-hosted Google Workspace equivalent, running live on Hoopla, synced to your desktop, wired into Dolibarr and WordPress, and accessible via API for automation. It’s not just file storage — it’s the connective tissue for how the team works, shares, and communicates.

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

000NCL, 07 - NZRT Configuration

Nzrt Folder Structure

Welcome to the NZRT Wiki Podcast. Today we’re looking at NZRT Folder Structure.

If you’ve ever wondered how NZRT organises its files in Nextcloud, this episode walks you through the whole picture — from the top-level layout all the way down to individual folders for finance, HR, sales, and more. The structure is designed to match how the business actually works, and it ties directly into Dolibarr ERP, WordPress, and the various agent roles you might already be familiar with.

Let’s start at the top. There are four main areas sitting at the root level of Nextcloud. You’ve got Shared, which is the main team workspace. Then WordPress, which holds content for the website. Then Public, for sharing files with clients and vendors outside the organisation. And finally Archive and External, which handle long-term storage and connections to backup systems like a NAS drive or cloud archive on S3.

The Shared folder is where most of the action happens, and it’s owned by the EDM agent, ema. Inside Shared, you’ll find dedicated folders for Marketing, Sales, Procurement, Finance, HR, Analytics, Database, and a few others. Each one is scoped to a specific role — so for example, pam has read and write access to Marketing, cas handles Sales, sun looks after Procurement, fin owns Finance, han manages HR, and dai works across Analytics. There’s also a credentials folder that only xc, the admin, can access.

Let’s look at some of these in more detail.

The Finance folder sits under Shared and contains subfolders for invoices organised by month, purchase orders split into active and completed, bank statements which are end-to-end encrypted, budget files, and monthly reports. Access is limited to fin and xc. Bank statements require encryption — that’s non-negotiable. And everything in Finance is kept for seven years to meet legal requirements.

HR follows a similar pattern. You’ve got an Employees folder with subfolders for active and departed staff, and within each employee’s folder you’ll find things like their offer letter, contract, and performance reviews. There’s also a Payroll folder — also end-to-end encrypted — containing monthly payroll spreadsheets and reports. Then Onboarding, with checklists and forms, and a Policies folder holding documents like the code of conduct and benefits guide. Only han and xc can access HR, and like Finance, retention is seven years.

Sales is managed by cas and gives read access to pam as well. Inside you’ll find a Clients folder where each client gets their own subfolder containing contracts and quotes. There’s also a Proposals folder, a Deals area with a shared spreadsheet linked to the project board, and a CRM Export folder where Dolibarr contact exports land as CSV files. Public share links are enabled for contracts, but they expire after thirty days. Sales records are kept for three years.

Procurement, managed by sun, holds purchase orders organised by year, a Vendors folder where each vendor has their own space for contracts and pricing, a folder for requests for quotation, and a folder for invoices received from vendors. Finance also has read access here. Retention is three years.

There’s a Templates folder that all users can read but only ema can update. It contains finance templates like invoice and budget spreadsheets, sales templates including proposal slides and contract documents, HR templates for offer letters and NDAs, and general templates for things like standard operating procedures and meeting minutes.

The Analytics folder is owned by dai and is used for aggregating data across systems. You’ll find weekly and monthly report folders, and an Exports section with data pulled from Dolibarr and other systems. This folder rolls over on a one-year cycle.

The Database folder is managed by dan and stores daily and weekly backups, system logs, and a yearly archive. Daily backups are kept for thirty days, and weekly backups are retained for a full year.

One of the more technically interesting folders is Dolibarr EDM. This is where Nextcloud and Dolibarr connect directly. Documents generated in Dolibarr — invoices, contracts, purchase orders — are automatically synced into this folder every night at two in the morning via a webhook and REST API integration. You’ll also find a Sync Log folder that records what happened during each sync, including any errors. The folder is owned by ema.

To bring it all together — every folder in this structure maps to a real business role, has defined access permissions, specifies whether encryption is required, and sets a retention period. Nothing is left ambiguous. Whether you’re fin looking for an invoice from three months ago, or dan checking a database backup log, you know exactly where to go.

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

000NCL, 08 - Reference

Occ Command Reference

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.

000NCL, 03 - Document Management

Pdf Viewer

Welcome to the NZRT Wiki Podcast. Today we’re looking at the Nextcloud PDF Viewer.

If you’ve ever found yourself downloading a PDF just to highlight a line or scribble a note, then uploading it again and emailing it to someone who needs to sign it — you know how tedious that loop can get. The Nextcloud PDF Viewer is built to cut that cycle out entirely. Everything happens right inside your browser, inside Nextcloud, without touching external software.

So let’s walk through what it can actually do for you.

First, the basics. When you open a PDF in Nextcloud, you get a fast, responsive viewer right in the browser. No waiting for Adobe to load, no plugin errors. From there, you’ve got a full set of navigation controls — you can zoom in and out, rotate pages, jump to bookmarks in longer documents, and select and copy text directly from the file. That last one is handy when you need to pull a quote from a contract without retyping it by hand.

Now, where it gets really useful is annotations. You can highlight text, underline it, strike through it, and attach notes — all without altering the original file in a destructive way. And you can digitally sign PDFs directly inside Nextcloud, embedding your signature right there in the document.

Let’s talk about how that annotation workflow actually looks in practice. You open your PDF in Nextcloud, then click the Annotate button. From there, you add your highlights, your notes, your signature — whatever the document needs. When you save, Nextcloud automatically creates a new version of the file, so the original is preserved and you’ve got a clean audit trail. Then you can share a link directly with whoever is next in your approval chain. No downloading, no re-uploading, no email attachments bouncing back and forth.

Now let’s talk about how NZRT teams actually use this day to day. There are four main areas where PDF Viewer makes a real difference.

Finance uses it to review invoices and contracts, and to add approval signatures without anyone needing to print a single page. Sales uses it to annotate proposals with client feedback — so when a client marks up a quote, those notes live right alongside the document in Nextcloud rather than in a separate email thread. HR uses it to sign offer letters and NDAs, again without printing. And on the document management side, annotated files can be archived with Dolibarr integration, so your signed and reviewed documents feed directly into your ERP records.

On the technical side, getting the PDF Viewer running on your Nextcloud instance is straightforward. There are two commands you’d run on your server. The first enables the PDF viewer app itself. The second enables a companion app for e-books, so your Nextcloud instance can handle that format as well. Both are single-line commands run through the Nextcloud command-line tool, and once they’re done, the functionality is live for your users.

To put it simply, for NZRT the big win here is eliminating the download-edit-reupload cycle entirely. The three roles that benefit most are Finance, Sales, and HR — referred to internally as fin, cas, and han. These are the people who are regularly handling contracts, proposals, and HR documents that need review and sign-off. By keeping all of that inside Nextcloud, you speed up approval workflows, reduce version confusion, and keep your document history tidy in one place.

If you want to dig deeper into related topics, the wiki also covers Document Management Overview, Nextcloud Office for live document editing, and Permissions and Sharing for controlling who can see and annotate your files.

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

000NCL, 06 - Administration

Performance Tuning

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Performance Tuning.

If you’ve ever noticed Nextcloud feeling sluggish when a lot of people are using it at once, or when you’re dealing with large files, this episode is for you. At NZRT, performance tuning comes down to three main areas: caching, PHP configuration, and database optimisation. Let’s walk through each one.

First up is caching, and the tool NZRT uses here is Redis. Redis is an in-memory data store, and Nextcloud integrates with it really well. The configuration lives in Nextcloud’s main config file, and what it does is tell Nextcloud to use Redis for three things. Local memory caching, which is the everyday object cache that reduces how often Nextcloud has to hit the database. Distributed locking, which prevents conflicts when multiple users access or modify the same files at the same time. And session storage, which is what makes logins feel fast. You point Nextcloud at Redis running on localhost, on port 6379, and give it a password. That’s the core setup. The payoff is fewer database queries, faster page loads, and much smoother performance for things like Nextcloud Talk and the Calendar app, which are especially chatty with the cache.

Next is PHP-FPM tuning, and this one is about making sure PHP can handle many users at once without running out of workers. The configuration file for Nextcloud’s PHP pool sets a dynamic process model, meaning the number of running PHP processes scales up and down with demand. The key numbers here are: a maximum of 100 child processes so you can handle heavy load, 20 processes started at boot so you’re ready to go immediately, a minimum of 10 spare servers sitting idle waiting for requests, and a maximum of 50 spare servers at any given time. Each worker also resets itself after 500 requests, which keeps memory usage healthy over time. On top of that, the PHP settings themselves are tuned for large files. Upload limits and the maximum post size are both set to 2 gigabytes, and the memory limit per PHP process is set to 512 megabytes. If you’re handling Dolibarr invoice exports or large WordPress media uploads through Nextcloud, these limits matter.

Now let’s talk about database optimisation. NZRT runs MySQL, and there are a couple of things you can do here. First, you can enable query caching through Nextcloud’s own command-line tool, which tells Nextcloud to cache the results of repeated database queries rather than running them every time. Second, you can run an optimise command directly against the file cache table in MySQL. This table can grow quite large over time and optimising it reclaims space and improves read performance. Third, you can use Nextcloud’s system info command to pull diagnostic output and check database health at a glance.

For file input and output, the recommendation is to use an SSD for your primary Nextcloud data directory, because fast random write performance makes a noticeable difference when many users are uploading files. If you’re mounting network storage, like a NAS, you want to use asynchronous writes and tune your SMB mount options. The mount command you’d use includes flags like async to avoid blocking on writes, hard and intr so the system handles network interruptions gracefully, and you can specify the protocol version to match your NAS setup. NZRT uses this approach for archival storage mounted from a local network path.

Finally, monitoring. You want to keep an eye on three things. Redis cache hit rate, which you can check using the Redis command-line tool’s stats output. This tells you how often Redis is actually serving data versus falling through to the database. PHP-FPM pool status, where a simple process list filtered to your Nextcloud pool shows you how many workers are active. And slow query logging in MySQL, where you can turn on a slow query log and set a threshold of two seconds, so any database query taking longer than that gets flagged for review.

To put this all in context, NZRT’s Nextcloud instance supports over 50 concurrent users who regularly work with large files. Redis caching is considered essential, particularly because Talk and Calendar generate a lot of short, repeated calls that would otherwise hammer the database. Getting these settings right means the system stays responsive even during busy periods.

If you want to go deeper, the related wiki notes on Administration Overview, Architecture and Tech Stack, and Logging and Monitoring are good next stops.

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

000NCL, 04 - Users & Security

Permissions Sharing

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Permissions & Sharing.

If you’ve ever wondered how NZRT controls who can see what inside Nextcloud, this episode walks you through exactly that. Permissions in Nextcloud are what keep sensitive documents safe, making sure that the Finance team’s payroll data isn’t visible to Sales, and that HR records stay strictly internal. That separation is achieved through a system of folder-level access controls, which we call ACLs, or access control lists.

Let’s start with the four permission levels you’ll encounter. The first is Read. When you have Read access, you can view a file but you can’t change it, delete it, or share it with anyone else. This is the right level for things like archives or finalised documents you just need to reference. The second level is Edit. Edit access adds the ability to make changes to files on top of viewing them, which makes it the go-to level for anything that involves collaborative work. Third is Create, which lets you add new draft documents to a folder. And finally, there’s Manage. Manage is the highest level — it combines viewing, editing, deleting, and sharing all in one, and it’s typically held by whoever owns the folder or the team responsible for it.

Now let’s talk about how those permission levels are actually applied across NZRT’s folder structure. There are five key folders to know about, and each one has its own owner, read access list, edit access, and manage rights.

The Finance folder is owned by fin, which is the Finance agent. Both fin and xc can read it. Only fin can edit it. And xc holds Manage rights, meaning xc can audit and control access at the top level. The HR folder works similarly — it’s owned by han, the HR agent, with han and xc having read access, han holding edit rights, and xc managing it overall.

Sales is owned by cas, the CAS agent. Both cas and pam can read it, cas can edit, and again xc manages. The Shared Templates folder, owned by ema, is the most open of the bunch — all users can read from it, ema can edit it, and xc manages it. Finally, the Dolibarr EDM folder is also owned by ema, with read access limited to ema and xc, edit belonging to ema, and xc in the Manage seat.

So the pattern you’ll notice is that xc, the admin account, holds Manage rights across the board. This is deliberate — it gives xc the ability to audit access logs and adjust permissions without getting in the way of day-to-day work by individual teams.

Now, how do you actually set these permissions? There are two ways. The first is through the Nextcloud graphical interface. You right-click on a folder, go to Sharing, and then open Advanced settings. That’s the quickest route for one-off changes. The second way is through the command line, using Nextcloud’s built-in tool called occ. With occ you can do things like transfer ownership of a folder from one user to another. You can also add a group to a folder and assign it a specific numeric permission code. For example, adding the Finance group to the Sales folder with read and write access combined uses the number thirty-one, because permissions in Nextcloud are represented as numbers that add up depending on what you want to allow. You don’t need to memorise those numbers day-to-day, but it’s good to know that the CLI method is there when you need to make bulk or scripted changes.

The third area covered in this wiki page is public sharing — the ability to generate a link you can send to someone outside NZRT. Public sharing is selectively enabled across folders. Sales links and Finance vendor portal links can be shared publicly, because those involve external clients and partners. But HR is internal only, so no public links there, and Finance invoices are restricted to named user shares rather than open links.

When public sharing is enabled, two policies apply. Every external share must have a password — no exceptions. And every share has an expiry date, set somewhere between seven and thirty days depending on the document type. This limits the window of exposure if a link ends up in the wrong hands.

To pull everything together: permissions in Nextcloud exist to create data isolation. Finance can’t browse HR payroll. Sales can’t see Procurement cost data. The ema role is responsible for managing folder hierarchies and the EDM structure, while xc retains oversight through Manage rights and access log auditing. If you need to go deeper, the related topics to check out are Users and Groups, File Sharing and Links, and Audit Logs.

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

000NCL

Podcast Folder Structure

Welcome to the NZRT Wiki Podcast. Today we’re looking at Podcast Folder Structure.

So, if you’ve ever wondered where all the NZRT Wiki Podcast audio files, transcripts, animated videos, and RSS feeds actually live, this episode answers that. Everything is stored in a structured folder inside Nextcloud, which is NZRT’s cloud file system hosted at cloud.nzrtnetwork.com. If you’re working locally, that same folder syncs down to your machine under your Nextcloud2 drive, inside Shared, then Content, then Podcasts.

Let’s talk about what that Podcasts folder actually looks like when you open it up. At the top level, the first thing you’ll notice is a file called feed.xml. That’s the master RSS feed — it covers every episode across every service. Sitting alongside it are a bunch of per-service feeds, each named with a service code. So you’ve got one for the x402 Knowledge Base API, one for Dolibarr, one for Blockchain, one for Flarum, one for GitHub, one for the LLM work, one for Nextcloud, one for Obsidian, one for WordPress, and so on. Each of those feeds covers only the episodes belonging to that particular service. There’s also a HOME.md file in there, which acts as an index document for the whole folder.

Below all those top-level files, you’ll find subfolders — one for each service code. So there’s a folder for 000API, one for 000DOL, one for 000BCH, one for 000NCL, and so on. Inside each subfolder you’ll find the actual episode files for that service. As an example, the 000API folder contains an mp3 file for the x402 overview episode, a txt file which is the full transcript for that same episode, and an mp4 file which is an animated visual companion for it.

That brings us to the three file types you’ll find for each episode. First, you have the mp3 file — that’s the actual audio, generated using a text-to-speech tool with an American English voice called Guy Neural. Second, there’s a txt file containing the full narration transcript — essentially the script you’re hearing right now, in text form. Third, some episodes also have an mp4 file, which is an animated visual version, created where that’s been set up for a particular episode.

Now, how do these audio files get shared publicly so podcast clients can actually play them? Each mp3 file gets a public, read-only share link created through Nextcloud’s sharing system. That link is set up as a public link with read-only access. The direct download URL from that share is then inserted into the RSS feed as what’s called an enclosure tag — that’s the standard way podcast apps know where to fetch the audio file from.

On the feed generation side, there’s a Python script called create_podcast.py that handles updating both the master feed and the relevant per-service feed each time a new episode is produced. Those feeds use the iTunes podcast namespace, which means they’re compatible with standard podcast apps. If you need to process a whole batch of wiki pages at once, there’s also a batch version of that script called create_podcast_batch.py, which will work through all the markdown files in a given wiki subfolder in one go. Both scripts live in the 000AGT repository on your local machine.

That’s really the full picture. A clean root folder with a master feed and per-service feeds, subfolders organised by service code, three file types per episode, public share links powering the RSS enclosures, and a pair of Python scripts keeping everything up to date.

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

000NCL, 05 - Integrations

Rest Api Webdav

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud REST API and WebDAV.

Nextcloud gives you two different ways to interact with it programmatically. The first is WebDAV, which stands for Web Distributed Authoring and Versioning. The second is a REST API. Both of these let you automate tasks, integrate third-party tools, and perform bulk operations without ever having to touch the web interface manually. Let’s walk through what each one does and how you’d actually use them.

Starting with WebDAV. This is the protocol you use for file operations — uploading, downloading, listing, and deleting files. Every WebDAV request you make goes to a base URL on your Nextcloud server, followed by a path that includes the username of the account you’re working with and then the folder path inside that account.

So, uploading a file — let’s say a PDF into a Finance folder — you’d make a PUT request, authenticate with a username and password, and point it at the exact path where you want the file to land. Nextcloud places it right there.

Downloading works the opposite way. You make a standard GET request to that same file path, authenticate, and tell your tool where to save the output locally. The file comes back to you.

Listing the contents of a folder is a little different. WebDAV uses a special request type called PROPFIND for this. You point it at a folder path, include a small XML body that tells Nextcloud you want the properties of everything inside, and it returns an XML response with details about every file and subfolder in that location.

Deleting a file is the simplest of all — a DELETE request to the file’s path, with your credentials, and it’s gone.

Now let’s move on to the REST API side of things. This is what you use for user management, sharing, and app-level operations. These requests go to a different base endpoint — the OCS API path on your Nextcloud server.

Creating a new user requires admin credentials. You send a POST request, include a special header that tells Nextcloud this is an API request rather than a browser session, and pass the new username and a temporary password. That’s it — the account exists.

Adding a user to a group follows a similar pattern. Another POST request, again with admin credentials and that same API header, but this time you target a URL that includes the username you want to update, and you pass the group name you want to add them to.

If you want to list all the shares belonging to a particular user, you send a GET request to the file-sharing endpoint with that user’s credentials and the API header. You get back a list of everything they’ve shared.

Creating a share link — the kind where anyone with the link can access a file — is also a POST request to the file-sharing endpoint. You pass the file path, a share type value of three which means public link, and a permissions value of one which means read-only. Nextcloud returns a share URL you can distribute.

Now, a quick note on authentication. There are three ways to authenticate with Nextcloud. The first is basic auth, which is just a username and password combination. This works well for development and scripting but isn’t ideal for production. The second is app tokens — these are long strings you generate inside Nextcloud and use in place of your actual password. They’re more secure and the right choice for production automation. The third is OAuth2, which is the three-step flow you’d use for integrating third-party applications that need to act on behalf of a user.

Let’s look at how NZRT actually uses these capabilities in practice. There are two main automation examples worth knowing about.

The first is a nightly invoice sync. This script queries the Dolibarr database for any invoices created in the last day, then loops through each one and uploads the corresponding PDF file into a Finance folder on Nextcloud under the ema account. This runs automatically each night, keeping Nextcloud in sync with what Dolibarr knows about.

The second is bulk user provisioning. This script reads from a CSV file — a spreadsheet with columns for name, email, and role. For each row, it makes two API calls. The first creates the user account in Nextcloud. The second adds that user to the appropriate group based on their role. So you could spin up ten new user accounts in the time it takes to run a single script.

In terms of which NZRT agents use these capabilities — dan, who handles database and backend work, uses this for automating backups and bulk provisioning. Dai, the data agent, uses the API for extracting reports and making analytics calls. And ema, who handles document and records management, uses WebDAV to sync documents from Dolibarr and run archiving workflows.

If you want to dig deeper, the related wiki articles on Integrations Overview, Dolibarr Integration, and the Nextcloud CLI Cheatsheet are good next steps.

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

000NCL, 03 - Document Management

Tagging Search

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Tagging & Search.

If you’ve ever dug through a shared drive looking for one specific contract or invoice and come up empty, this episode is for you. Nextcloud’s tagging and search features exist to solve exactly that problem — helping everyone at NZRT find documents quickly, stay organized, and meet record retention requirements without a lot of manual hunting.

Let’s start with the tag system. At NZRT, tags aren’t just freeform labels — admins create and maintain a standardized set so that everyone is tagging consistently. There are eight standard tags you’ll encounter across the vault, and each one has a defined purpose and a specific set of people responsible for applying it.

The first is “invoice,” which you’d apply to financial documents. That one is handled by our Finance agent and xc. Next is “contract,” used for legal agreements, applied by our Client & Strategy agent and xc. Then there’s “draft,” which marks anything still in progress — and that one is for everyone to use, not just a specific role.

Once something has been signed off or finalized, it gets the “approved” tag, and that’s applied by xc, Finance, or Client & Strategy depending on the document. The “confidential” tag marks restricted access files and is controlled by xc and our Handling agent. If a document has been synced across to the Dolibarr ERP system, it gets tagged “dolibarr,” and that’s managed by our Email & Integration agent and xc. Similarly, blog and website content gets a “wordpress” tag, applied by the Email and Publishing agents. And finally, anything heading into long-term storage picks up the “archive” tag, courtesy of our Data agent or xc.

So those eight tags give you a clean, shared vocabulary across the whole team. Instead of everyone inventing their own labels, you’ve got a consistent layer of metadata that makes searching reliable.

Speaking of searching — let’s talk about how the full-text search capability works under the hood. There’s a configuration step that enables the full-text search feature in Nextcloud. In plain terms, two extensions get switched on: one that provides the search interface inside Nextcloud itself, and one that connects it to Elasticsearch, which is the underlying search engine doing the heavy lifting. Once those are active, you run an indexing command that goes through all your existing documents and makes their contents searchable. So it’s not just searching file names — it’s looking inside PDFs, Word documents, and other files to find the actual words you’re looking for.

Once that’s set up, you can run some pretty powerful queries. Think of these like structured search requests. For example, you could search for all invoices from 2026 that were tagged by the Finance role — the system would return every document matching all three of those criteria at once. Or you could ask for all approved contract PDFs — filtering by file type, tag, and approval status simultaneously. You’re essentially layering filters together rather than doing one broad search and then manually sifting through results.

Now, why does all of this matter in the NZRT context? Tagging is tied directly to compliance. When documents are consistently tagged, it becomes much easier to apply and verify record retention policies — you know what’s been approved, what’s still a draft, what’s confidential, and what’s been archived. Without that consistency, things slip through the cracks.

There are also two agents with specific roles in keeping this system healthy. EDM — that’s our Email and Integration agent, ema — manages the tag hierarchy itself. So if you think a new tag should be added or an existing one needs changing, that goes through ema. And our Data agent, dai, uses tags as part of reporting and analytics work — so good tagging discipline directly feeds into the quality of the data that drives decisions.

If you want to go deeper, there are a few related topics worth exploring in the wiki. Document Management Overview gives you the broader picture of how files are structured and governed. The Files App article covers the day-to-day interface you’re working in. And NZRT Folder Structure explains how the directory layout is set up, which pairs naturally with tagging to give you both location-based and label-based ways to find what you need.

The short version: tag consistently using the standard set, use the search system to filter across multiple criteria at once, and you’ll spend a lot less time hunting for documents and a lot more time actually working with them.

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

000NCL, 02 - Collaboration Apps

Talk Chat Video

Welcome to the NZRT Wiki Podcast. Today we’re looking at 💬 Talk (Chat & Video).

So let’s set the scene. If you’ve ever wondered why NZRT isn’t using Slack for team chat or Zoom for video calls, this episode answers that question. The answer is Nextcloud Talk — a secure, self-hosted communication platform that lives entirely on NZRT’s own infrastructure. No third-party servers, no external subscriptions, and no data leaving the building, so to speak.

Nextcloud Talk covers the full range of communication you’d expect from any modern team tool. You’ve got direct messages for one-on-one encrypted conversations, group chats for teams, projects, or topics, and video and audio calls that can handle up to one hundred participants at a time. Those video calls run on WebRTC, which is an open, encrypted standard, so your calls are protected end to end. Beyond that, you can share your screen during calls — either your whole desktop or just a specific window — and you can record calls for later review. Notifications are covered too, whether that’s desktop alerts, email, or mobile push notifications.

Now let’s talk about how NZRT actually organises its channels in Talk. There are a few different types you’ll encounter. First, you have persistent channels — these are the always-on rooms that the whole team uses day to day. Think of channels for general conversation, team-wide announcements, and a dedicated tech channel. Then you have project-specific channels, which are spun up for focused work — things like a channel for a Dolibarr deployment, another for a WordPress redesign project, or one specifically for Nextcloud administration tasks. Third, you have direct messages, which are just your standard private one-on-one conversations. And finally, there are read-only channels, which are used for announcements — only the admin account, xc, can post in those, so they stay clean and authoritative.

Now, let’s look at how Talk is configured for NZRT’s specific needs. The settings used here cover a few important areas. The maximum number of participants in a call is set to fifty. Public calls are required to have a password before anyone can join. Call recording is switched on automatically — this is tied to NZRT’s Electronic Document Management requirements, meaning recordings are kept as part of the organisation’s compliance record. And speaking of compliance, recordings aren’t kept forever — they’re set to automatically delete after ninety days, keeping the archive manageable without losing anything that’s needed for audit purposes.

That combination of auto-record and timed expiry is worth understanding because it’s not just a housekeeping measure. The EDM function at NZRT — handled by the ema role — is responsible for records retention, and Talk feeds directly into that workflow. When a call finishes, the recording doesn’t just sit in someone’s downloads folder. It integrates with Nextcloud’s archival system, so it’s stored, managed, and eventually disposed of according to the retention policy. That’s a level of record-keeping that most external video platforms can’t give you without paying for enterprise add-ons.

And that brings us to the bigger picture of why Talk exists in the NZRT stack at all. Every Slack message on an external platform and every Zoom call lives on someone else’s server. For a consultancy that takes data sovereignty seriously, that’s a problem. By running Talk on NZRT’s own data centre infrastructure, all communications stay internal. There are no licensing fees for Slack seats or Zoom licences, and there’s no dependency on a third-party service going down or changing its pricing model. It’s a deliberate choice to own the stack.

If you want to explore related areas, the wiki connects Talk to a few other topics worth knowing about. The Collaboration Overview gives you the broader picture of how NZRT’s tools fit together. The Users and Groups page explains how access is managed across Nextcloud, which naturally affects who can join which Talk channels. And the Email and CalDAV CardDAV note covers the other communication channels that sit alongside Talk in the stack.

So to summarise what you’ve learned today: Nextcloud Talk is NZRT’s all-in-one, self-hosted replacement for Slack and Zoom. It supports direct messages, group channels, encrypted video calls for up to one hundred people, screen sharing, and call recording. NZRT’s channels are organised into persistent team rooms, project-specific rooms, direct messages, and read-only announcement channels. Calls are configured to require passwords, auto-record for compliance, and delete recordings after ninety days. And the whole system feeds into the ema role’s records retention workflow, keeping NZRT audit-ready without relying on any external platform.

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

000NCL, 04 - Users & Security

Two Factor Auth

Welcome to the NZRT Wiki Podcast. Today we’re looking at Two Factor Auth.

So, what is two-factor authentication, and why does it matter for NZRT? At its core, two-factor auth, or 2FA, means that when you log in to Nextcloud, you don’t just enter your password and walk straight in. You also need to prove your identity a second way. That second step is what makes it so much harder for someone to get into an account even if they’ve somehow got hold of your password.

NZRT supports a few different ways to do that second step, so let’s run through them. There are three methods available.

The first is TOTP, which stands for Time-based One-Time Password. You set it up by scanning a QR code, and from that point on you use an app on your phone like Google Authenticator or Authy to generate a six-digit code whenever you log in. This is the recommended method for most NZRT users.

The second method is Backup Codes. When you set up 2FA, Nextcloud generates ten single-use codes for you. These are for the situation where you’ve lost your phone or can’t access your authenticator app. Generating and securely storing these backup codes is mandatory for everyone using 2FA, not optional.

The third method is FIDO2, which uses a physical USB security key. You plug it in and touch it to authenticate. This one is optional and at NZRT it’s currently only in use by the xc account.

Now, how does NZRT actually enforce 2FA for people who need it? Through the Nextcloud admin settings, under the Security section, an administrator can turn on enforcement for specific groups. At NZRT that means the admin group, the finance group, and the HR group. When enforcement is switched on, anyone in those groups sees a prompt to set up 2FA the next time they log in. There’s also a grace period of seven days, which gives users a window to get it configured before they’re locked out of their workflow.

Let’s walk through what the TOTP setup actually looks like from a user’s perspective. First, you head into your Account Settings and enable 2FA. Nextcloud then shows you a QR code. You open Google Authenticator or Authy on your phone and scan that code. The app will immediately start showing you a six-digit number that changes every thirty seconds. You type that number into Nextcloud to confirm the link worked. Then, crucially, you save your backup codes somewhere safe, a password manager or a secure printed copy somewhere offline. From that point on, every time you log in you’ll enter your password as usual, and then you’ll be asked for the current six-digit code from your app.

So who at NZRT actually needs to do this? The policy splits into three tiers. Two-factor auth is mandatory for three accounts: xc, which is the admin account; fin, the finance role; and han, the HR role. It’s strongly recommended for two more: ema, who handles email and digital marketing, and dan, the database administrator. For everyone else in the organisation, 2FA is optional but still a good idea.

Why are finance and HR singled out as mandatory rather than just recommended? Because those roles handle sensitive personal and financial data. Data protection regulations require that access to that kind of information is properly secured, and relying on a password alone doesn’t meet that bar. If a credential gets compromised, whether through a phishing email, a reused password, or a data breach somewhere else, 2FA is the thing that stops an attacker from just walking in. The second factor, the code on your phone or the key you have to physically touch, is something an attacker very rarely has even when they have your password.

The broader point here is that 2FA isn’t about distrust of users. It’s about recognising that passwords alone are no longer a reliable defence. Credential compromise is one of the most common causes of account breaches, and adding that second step dramatically reduces the risk for the accounts that matter most.

If you’re in one of the mandatory groups and you haven’t set this up yet, now is the time. Head into your Nextcloud account settings, find the security section, and follow the TOTP setup steps. Make sure you save those backup codes. And if you have any questions, check the related notes in the wiki covering Users and Groups, Permissions and Sharing, and the Administration Overview.

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

000NCL, 01 - Files & Storage

Versioning Trash

Welcome to the NZRT Wiki Podcast. Today we’re looking at ?? Versioning & Trash.

If you’ve ever accidentally overwritten a file — or needed to roll back a document to an earlier state — Nextcloud’s built-in versioning and trash features are what save the day. Let’s walk through how they work and how NZRT uses them.

First, the basics. Every time you change a file in Nextcloud, the system automatically takes a snapshot of it. You don’t have to do anything — it just happens in the background. So if you edit a contract, update a spreadsheet, or revise a report, Nextcloud quietly keeps a copy of what that file looked like before your changes.

What can you actually do with those snapshots? Quite a lot. You can revert a file to any previous version with a single click — just pick the version you want and restore it. You can also download an older version as a brand new file, which is handy if you want to compare two drafts side by side without touching the current one. On top of that, Nextcloud keeps an activity log for each file, so you can see who changed what and when. That’s genuinely useful in a team environment where multiple people work on the same documents.

Now, versioning doesn’t come for free — it uses storage. By default, the system holds versions for up to thirty days, or up to fifty versions per file, whichever limit is reached first. Both of those numbers can be adjusted by an administrator.

Here’s where storage planning matters. The way to think about it is this: take your total active file storage, multiply it by the average number of versions you’re keeping per file, and that gives you the extra space versioning will consume on top of your normal storage. To put that in NZRT terms — if you have five hundred gigabytes of active documents, and each file has an average of five versions saved, you’re looking at an additional two and a half terabytes of storage overhead. That’s significant. For non-critical documents, the recommended approach is an aggressive cleanup schedule — clearing old versions every seven days rather than waiting out the full thirty-day window.

That brings us to trash, which works like a recycle bin. When you delete a file in Nextcloud, it doesn’t vanish immediately — it moves to the trash folder, giving you a window to recover it if you change your mind. Administrators can configure how long deleted files sit there before being permanently removed. The system can handle this automatically, letting Nextcloud decide based on available storage. There’s also a command-line tool admins can run to preview what would be cleaned up before anything is actually deleted — a dry run — so you can check what’s going before you commit to it.

For NZRT specifically, versioning is treated as critical infrastructure, not just a nice-to-have. The main reason is how tightly Nextcloud is woven into Dolibarr document workflows. Think about contract amendments — when a contract goes through multiple rounds of negotiation, each revision needs to be traceable. Invoice corrections, purchase order revisions — all of these benefit from a clear version trail. If something looks wrong on a document, you want to be able to pull up exactly what it said last Tuesday.

The EDM agent — you might know her as ema — is responsible for managing retention policies across NZRT’s document library. Different document types get treated differently. A working draft might be cleaned up aggressively to save space, while a signed contract or financial document gets a much longer retention window.

If you want to go deeper on any of this, the related areas to explore in the wiki are the Files App documentation, the occ Command Reference — which covers the command-line tools admins use to manage Nextcloud — and the Backups and Maintenance section.

The key takeaway is this: versioning and trash in Nextcloud are automatic safety nets, but they cost storage. Understanding your retention settings and planning your cleanup schedule is how you keep that cost under control without losing the ability to recover from mistakes.

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

000NCL, 08 - Reference

Webdav Cheatsheet

Welcome to the NZRT Wiki Podcast. Today we’re looking at WebDAV Cheatsheet.

WebDAV is a protocol that lets you interact with files stored on a server over HTTP. For NZRT, that means you can upload, download, move, copy, and delete files on Nextcloud programmatically, without ever opening a browser. Every operation you’ll see today targets a base endpoint on the Nextcloud server, structured around a path that includes the word “dav”, then “files”, then your username. That username part is important — every command you run needs to be tailored to the account you’re working with.

Let’s start with the basics. To upload a file, you send a PUT request to Nextcloud using curl. You authenticate with your username and password, point curl at the file on your local machine, and specify the destination path on Nextcloud where you want it to land. That’s it — one command, file is uploaded.

Downloading is the reverse. You send a GET-style request with your credentials, provide the remote file path, and tell curl where to save it locally. Simple and reliable.

Now, listing files works a little differently. WebDAV uses a special request type called PROPFIND, which asks the server to return properties about files and folders. You add a header that tells the server you want to look one level deep — so you see the contents of a folder without recursing into subfolders. You also pass a small XML body that asks for file properties. The server responds with an XML document describing everything in that folder.

Deleting a file is straightforward — you send a DELETE request with your credentials and the path to the file. No confirmation prompt, so be deliberate.

Creating a folder uses another WebDAV-specific request type called MKCOL, short for “make collection.” You point it at the path where you want the new folder, authenticate, and Nextcloud creates it.

Copying a file involves a COPY request. You point curl at the source file, and you add a Destination header that specifies where the copy should end up. Both paths need to be full URLs on the server.

Moving or renaming a file works the same way — you use a MOVE request instead, with a Destination header pointing to the new path or new name. One command handles both renaming and relocating.

If you need file metadata — things like content type, file size, last modified date, or an internal file ID — you use PROPFIND again, but this time against a specific file rather than a folder, and you pass a more detailed XML body listing exactly which properties you want back.

Now for the more powerful stuff. There’s a bulk upload script that loops through all PDF files in your current directory and uploads each one to a specific remote folder on Nextcloud. You set four variables at the top: the server URL, your username, your password, and the remote path — in the example that’s a Finance invoices folder for April 2026. The script then iterates over every PDF it finds and fires off a PUT request for each one, printing a confirmation line after each upload.

The bulk download script does the opposite. It first runs a PROPFIND to list files in a remote folder, extracts the file paths from the XML response, then loops through them and downloads each one to your current local directory.

You can also mount Nextcloud as a drive on Linux. You install a package called davfs2, then run a mount command pointing at the WebDAV URL, specifying a local mount point and your username. You’ll be prompted for your password. Once mounted, you interact with Nextcloud files exactly like a local folder. To disconnect, you run the unmount command.

On Windows, it’s even simpler. Open File Explorer, choose Map Network Drive, paste in the WebDAV URL with your username at the end, check the option to connect with different credentials, and enter your Nextcloud username and password. Nextcloud appears as a mapped drive in Explorer.

There’s also a practical NZRT example in the cheatsheet — a nightly invoice sync. This script queries the Dolibarr database for invoices created in the last day, then uploads each matching PDF from the local Dolibarr invoices folder to Nextcloud under the Finance invoices path. This is the kind of automation WebDAV was built for: bridging your ERP system and your file server without any manual steps.

To put it in context for NZRT — WebDAV is the glue that connects Nextcloud to your other systems. Whether you’re syncing Dolibarr invoices, running nightly backups, or building integrations with third-party tools, WebDAV gives you a consistent, scriptable interface to your Nextcloud storage. Related topics worth reading alongside this one include the REST API and WebDAV overview, the Nextcloud CLI Cheatsheet, and the Dolibarr Integration notes.

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

000NCL, 05 - Integrations

WordPress Integration

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud WordPress Integration.

If you work with NZRT’s content or user management systems, this episode is going to give you a clear picture of how Nextcloud and WordPress talk to each other — and why that connection matters for your day-to-day work.

Let’s start with the big picture. Nextcloud and WordPress are integrated across three main areas: user authentication, media asset storage, and collaborative content editing. Nextcloud acts as the media library backend for WordPress, meaning it’s the central place where files live, and WordPress pulls from it rather than managing everything on its own.

Let’s talk about user sync first. NZRT uses something called LDAP and single sign-on, or SSO, to connect accounts between the two systems. What that means for you practically is this: when a new Nextcloud user is created, a corresponding WordPress user gets created automatically. And you only need one password for both platforms. You log in once and you’re covered across both systems — no separate credentials to manage.

Now let’s look at media management. WordPress media assets — things like images, photos, and press release files — are stored in Nextcloud rather than sitting inside WordPress itself. This happens through the REST API, which is essentially a way for the two systems to communicate and pass data back and forth. The specific folder in Nextcloud that handles this is called WordPress Media, and it’s shared with the content team. Featured images and uploads get automatically backed up there too, so you have version control and an archive without any extra effort on your part.

To give you a sense of how the technical side is configured, there is a setup that points the WordPress LDAP plugin to an internal server address, specifies a base directory location for user accounts, and sets a user path within that directory. On the Nextcloud side, there is an API endpoint pointing to the WordPress Media folder, using a combination of a username and a token to verify access. You do not need to memorise any of that, but it is worth knowing these two systems are talking to each other constantly in the background.

Now let’s walk through the actual content workflow, because this is what you will interact with most. An editor logs into WordPress using their normal single sign-on credentials. From there, an author writes a blog post inside WordPress. But here is where Nextcloud steps in: draft documents live in a Nextcloud folder called WordPress Drafts, and the team can edit those directly using Nextcloud Office, the built-in collaborative editing tool. Once a post is ready to publish, the featured image auto-syncs from the Nextcloud media folder into WordPress. And when the post goes live, a version is saved into a Nextcloud archive folder for long-term storage.

So you can think of it as a two-track system. WordPress is your publishing front-end — it is where the post goes live and where readers see it. Nextcloud is your back-end storage and collaboration layer — it is where files live, where the team edits together, and where everything gets archived.

Speaking of folders, here is how the Nextcloud WordPress directory is structured. At the top level there is a folder called WordPress. Inside that you have a Media folder, which contains three subfolders — one for Blog images, one for Press Releases, and one for Photos. Then there is a Drafts folder, where you would find documents like a named blog post file for a specific month. And finally there is a Published Archive folder, where completed posts are stored for reference.

The key people working within this integration at NZRT are pam and ema — the content team — who use Nextcloud Office to collaborate on blog posts before they go live. By keeping media assets in Nextcloud rather than relying on WordPress alone, the team gets version control, easy sharing, and a reliable archive all in one place.

If you want to dig deeper, there are a few related topics worth exploring. There is an Integrations Overview document that gives you the wider picture of how NZRT’s systems connect. There is also a dedicated page on LDAP and SSO if you want to understand the authentication side in more detail. And Nextcloud Office is worth a look if you are going to be collaborating on drafts.

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