Tag Archives: files

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.

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.

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.

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.

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.