Tag Archives: sharing

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.

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.