Nextcloud guest accounts and external sharing

Why Nextcloud guest accounts need a sharing policy before launch

Most organizations need to work with contractors, clients and partners who are not employees. Nextcloud offers several ways to share with outsiders: guest accounts, public links and federation between servers. Each route reaches people differently and each needs its own controls, so a sharing policy should be agreed before the first external user is invited. The first real test usually comes with a single project, such as a design agency reviewing files or an auditor receiving a document set, and that is when unplanned sharing starts.

The risk is not that sharing exists but that individual users make the decisions. A user who needs to send a file to a client may create a public link with edit rights, no expiry date and no password, then forward it beyond the intended recipient. Another may invite a guest into a group that also has access to internal folders, or share with a personal email address that the organization cannot later revoke or trace. Accounts created for a project often remain active after the project ends, and federated shares can reach a server that nobody on the admin team has reviewed. None of these actions requires administrator rights, which is why the rules must be set centrally.

Before launch, the admin team should decide who may invite guests (administrators only, a named group, or any user), which groups guests may join and whether guests can see user lists or other shares. The team should also decide whether public links are allowed at all and, if they are, which link permissions, password requirements and expiry limits apply. Federation needs its own decision: whether to permit it, and if so, to which external servers. Finally, name an owner for exceptions and a schedule for reviewing guest accounts and open shares, because cleaning up after many users have shared folders is far harder than preventing the problem.

Treat the admin settings as something to verify, not something to copy from this page. Option names, defaults and the location of each control can change between Nextcloud versions, so confirm every setting against the Nextcloud admin manual for the version you run before writing the policy. Then test the policy on a staging instance with a dummy guest account, a public link and a federated share. If your users sign in through LDAP, OpenID Connect or SAML, also confirm how external identities are created and whether they are provisioned in the directory, because that decides who can be a guest and how quickly access ends.

Which external sharing method fits which outsider

This table compares guest accounts, public share links and federated sharing for people outside your organization who need files from your Nextcloud server. Read each column as one method, and use the rows to match the recipient, their login needs and how you will cut off access. Capabilities and admin settings differ between releases, so confirm them against the installed version before you publish a sharing policy.

Criterion	Guest account	Public share link	Federated share
Who the recipient is	A named person you invite, who gets an account on your server	Anyone holding the URL, who may not be a known or vetted person	A user on another Nextcloud server, identified by their federated address
Persistent login	Yes, a login that stays valid until you change or disable it	No account; access depends only on the link and any password on it	No account on your server; the recipient signs in to their own server
What they can reach	Only items explicitly shared with them, within the permissions you grant	Only the file or folder behind the link, within the link's permissions	Only items shared to them, viewed through their own server's interface
Best fit	Recurring contractors and reviewers you will work with over an extended period	One-off reviewers or a single file sent outside the organization	Partner organizations that already run their own Nextcloud server
How access is revoked	Disable or delete the account, which ends sign-in and access in one step	Delete or expire the link; anyone who saved a copy keeps that copy	Remove the share on your server; the partner server may keep local copies
Admin settings to confirm	Who may create guests, default group membership and default sharing permissions	Link password enforcement, expiration defaults and per-link download or upload limits	Trusted server settings, sharing with federated users and address lookup visibility
Main risk	Accounts that outlive the engagement when no one owns the periodic review	Forwarded links reach people you never vetted, and the link alone grants access	Your protection depends on how the partner administers its server, which you do not control

How to keep guest accounts limited to shared files

Guest accounts in Nextcloud are only as limited as the groups, sharing permissions and directory visibility around them. The four decisions below determine what an outside user can reach, what they can pass on to others and what internal users can discover about them. Confirm each setting in the admin interface of the version you run, because menu labels and defaults change between releases.

Choose the groups guests join

Guests should belong only to groups that grant access to the folders and shares they need, and avoid groups that carry broad file access, such as a department or company-wide group. Group membership controls which shared folders, team folders and app features a guest can reach, so review membership before any invitation is sent. Confirm which groups grant access to team folders and apps in your installed version, and whether a dedicated guest group keeps these accounts separate from staff. Illustrative example: a contractor added to an all-staff group would immediately see every share that group receives.

Receive shares or create them

Decide whether a guest can only receive shares created by an internal user, or can also create shares and invite others. A guest who can reshare can bring in people your organization never vetted, and link shares extend that reach beyond the account itself. Limit guests to receiving shares wherever the installed version allows it, and confirm that the sharing options offered to guests match your data handling policy. Test with a sample guest account before rollout to verify that the share dialog offers only what you intend.

Restrict sharing permissions by group

Sharing permissions can be limited by group so that selected groups cannot create public links, grant edit rights or reshare files. Use these group-level restrictions to keep guest and external collaboration on read or limited edit access, especially for folders that hold regulated or confidential data. Confirm in the admin sharing settings which permissions can be restricted by group, which groups the restriction applies to, and whether it covers link, email and federated shares in your version. A restriction that covers only one share type leaves the others open.

Control guest visibility in search

Sharing dialog autocomplete and user search can expose internal users to guests, and guest accounts may appear to staff in the same results. Decide whether guests can search the full user and group directory or only people who share a group with them, and whether internal users see guest accounts in their own search. Confirm the sharing search and user lookup options for your version, then test from both a guest account and an internal account, because both views affect how much names and group memberships are exposed.

Recheck settings after each upgrade

Guest and sharing behavior can change between Nextcloud releases, and upgrades must proceed one major version at a time with a backup before each step. Record the expected value of every guest, group and sharing setting before an upgrade, then compare them afterward. Confirm behavior changes in the release notes for the target version and rerun the guest test accounts. Disable third-party apps until they are confirmed compatible, since several guest-related features depend on apps.

When federated sharing between Nextcloud servers is the better choice

Choose federated sharing when the person you are collaborating with already has a managed account on another Nextcloud server that their organization runs, and you want the file to stay with its owner. Choose a guest account when the outsider has no server of their own, and you are willing to host their identity and their access on your side. The decision turns on who hosts the data, who controls the account lifecycle, and how much you depend on a server you do not operate. With a guest account, your server holds the shared files and the guest's login. Your administrators create the guest, limit it to shared folders and remove it when the engagement ends. With federated sharing, the file remains on the owning server, and the recipient's server presents a reference to it. The recipient's account lives on their organization's server, so their administrators decide when that person is disabled, moved to another group or deleted. Your team can revoke a share you created, but it cannot stop the partner's staff from managing their own users. The partner's platform changes will reach you. If the partner upgrades Nextcloud, changes its identity provider, or moves users from LDAP to OpenID Connect or SAML, the user identifiers and login paths on their side may change. Shares that rely on those identifiers can break or behave differently until both sides test them. Ask the partner for its upgrade calendar and whether it plans identity changes, and agree on who tells whom before either side makes a change. Federation only works when both servers are configured and kept current. Administrators on each side must enable federated sharing, confirm which remote servers they trust, and check that the other server's address and certificate are the ones they expect. Verify the trust relationship from both directions with a test share before any sensitive work begins. Confirm the federation features your release supports in the Nextcloud admin manual for that version, because support for specific sharing options can differ between releases.

Setting up guest accounts and sharing controls in order

This sequence takes a Nextcloud server from default sharing settings to a tested setup in which outside collaborators can reach only the folders they were invited to. Each step ends with a check you can run yourself, so you finish with evidence that each control works. Admin panel locations and option names vary by version, so confirm each one in the documentation for the version you install before you change production settings.

Confirm the sharing policy and approvers
Start with a written sharing policy that names which roles may invite people from outside the organization, which data classes may leave it, and who approves exceptions. Your security or compliance lead and the data owners should sign off, and the platform administrator should record those decisions in the change ticket. Then compare the current sharing and guest settings on the server against the policy, confirming each option name and location in the documentation for your installed version first. Done when every setting the policy governs has a recorded expected value and a named owner.
Choose how guest identities are created
Decide whether guests will be local Nextcloud accounts managed by administrators or will sign in through an identity source your organization already runs. Local accounts are quick to create, but each one needs a removal step that someone owns. If you plan to use LDAP or Active Directory, the LDAP app lets directory users appear in Nextcloud and sign in with their directory credentials. Nextcloud also documents OpenID Connect and SAML as user authentication backends, so confirm which combination your version and identity provider support. Done when you have written down the identity source, the owner of guest accounts, and the removal process.
Create a test group and guest
Create a dedicated test group and one test guest account that belongs to that group and to no other group. Use a mailbox or identity you control so you can complete any invitation or password step yourself. Keep the test guest out of every group that holds production folders. Check that the account signs in and that its group membership matches what you intended. Confirm in the admin interface, using the guest or external user view for your version, that the account and group appear with the expected membership and nothing more. Done when the test guest and group show the intended membership in the admin interface.
Restrict sharing permissions and link behavior
With the test guest in place, set the sharing options the policy requires. Typical items include whether users may share with people outside the organization, whether they may create public links, whether links can require a password or an expiry date, and which share permissions such as read, edit and reshare are offered. Confirm the exact name and default of each option in the documentation for your installed version, since labels and defaults change between releases. Create a test share as a normal user. Done when that share offers only the link and permission types the policy allows, and the server refuses a disallowed type when you try to set it.
Test that guests see intended folders
Create a test folder containing harmless sample files, plus a second folder that the test guest must not reach. Share only the first folder with the test guest, then sign in as that guest in a private browser session. Check the file list, search results, activity feed and any sync client signed in with the guest account. Confirm that the second folder is absent and that a direct URL to its contents is denied. Repeat the test with a group share to confirm that group membership grants the same access and no more. Done when the guest sees the intended folder and nothing else, and you have recorded the result for both direct and group shares.
Confirm revocation removes access
Remove the test share, then disable or delete the test guest, and confirm that access ends on every path the guest used. Check that the web interface, any sync client and any previously created public link no longer return the files. Sessions and app passwords can outlive the account change, so review the active sessions and app password lists for the guest and revoke anything still open. Also remove the guest from the test group and confirm that group-based access ends. Done when a signed-in guest session and an existing link both fail after revocation, and you have noted any files still cached on a client device.
Record the configuration and schedule retests
Copy the settings for sharing, guest identity and permissions into your configuration record. Include the installed version, the policy version, the test results from the folder and revocation checks, and the name of each owner. Store the record where your change process keeps infrastructure documentation. Schedule a retest after each upgrade or app change, because guest-related behavior can differ between versions and upgrades often require third-party apps to be checked for compatibility. Done when a second administrator can repeat the tests from the record and reach the same results.

Security controls to set before external sharing goes live

Each control below is a decision that sets how far an outside person can reach your data and how long that access lasts. Settle them together before the first guest receives a link, because a permissive default left in place tends to become the working practice. For each one, confirm the option and its default in the sharing settings of the release you install.

Password requirements for public links

Decide whether public links must carry a password and how strong that password must be. Enforcing a password protects a link that is forwarded, posted or indexed by mistake, but it adds a step for recipients who expect one-click access and often leads to passwords sent in the same email as the link. Pair the rule with a separate channel for passwords, and check that enforcement can be turned on for link shares and applies to the guest groups you plan to use.

Expiry dates on shares

Decide whether shares expire by default and how long a guest keeps access after the work ends. Expiry dates limit the damage from a forgotten link, but short windows mean project teams must request extensions, and a default that is too strict pushes users toward unmanaged file transfers. Confirm that the release can enforce a default expiry for user and link shares and that the expiry applies to existing shares as well as new ones.

Restrictions on re-sharing

Decide whether a guest or a recipient of a share may share the same item again with others. Blocking re-sharing keeps the list of people who can open a file known to the data owner, but it also stops legitimate chains, such as a partner forwarding a file to its own auditor. Check that the release lets you disable re-sharing for guest accounts and for shares to people outside the organization, then test that a guest cannot create a link to a file they only received.

Logging and review of shares

Decide which share events are logged, who reviews them and how often. Recording share creation, link access and permission changes lets administrators answer who opened a file and when, but logs only help if someone reads them, and volume grows with every guest. Confirm which sharing events the installed release writes to its activity log, how long entries are kept, and whether they can be forwarded to your existing monitoring system.

Handling guests whose engagement has ended

Decide what happens to a guest account and its shares when a project, contract or consultancy ends. Options include disabling the account, revoking shares, transferring file ownership to an internal user and deleting the account after a retention period. Disabling blocks sign-in while keeping files and history, but shares may still need revoking separately, so assign an internal owner to each guest when the account is created. Confirm in your release whether guests can be disabled and whether their shares can be listed and revoked in bulk.

Effect of sharing rules on encryption

Decide which sharing methods are allowed for files that sit under server-side or end-to-end encryption. Some encryption modes limit what can be shared with people who have no account on the server, and public links can behave differently from user shares. Settle this before rollout, since changing the rule later can make existing shares unreadable or force users to re-share. Confirm in the encryption documentation for your release which sharing paths work with each mode, and test them with a guest account before you announce the service.

Keeping external sharing governed after launch

Guest accounts and external shares need a standing review cycle after go-live, because the risk they carry changes with time even when no one touches the configuration. A guest who was invited for one project may still hold a login months later, and a public link created for a single handover may still be reachable. Plan a recurring review of the guest accounts list and the sharing reports, and assign a named owner for each guest account and each open share. Ask whether the sponsoring internal user still exists and whether the collaboration still needs the access. Record the outcome of each review so an auditor or your own team can see what was checked and when.

Offboarding is where guest governance most often breaks down. When a project ends, the guest account, its group memberships and every share granted to it should be removed or disabled together, and public links should be expired or deleted. Confirm in your own environment whether disabling a guest account stops existing links from resolving, and whether files the guest uploaded remain owned by the internal folder owner. Write the procedure as a checklist that the project sponsor signs off, and test it once on a non-production account so the steps are known to work before the first real project closes.

Monitoring for unusual sharing activity depends on what your deployment logs. Decide which events matter, such as new public links to sensitive folders, shares to unfamiliar external domains, large downloads by guest accounts, or repeated failed guest logins, and confirm that your Nextcloud logging configuration and any forwarding to a SIEM capture them. Set thresholds with the data owners rather than leaving them to the default, and agree who reviews the alerts and how quickly. Treat the first few months as a baseline period in which you adjust alerts to reduce noise without removing the events that would indicate misuse.

The sharing policy itself has to move as outside collaborators change. New partner organizations, different data classifications and changes to who may invite guests all require updates to group settings, sharing permissions and the rules your administrators apply. Keep a change record for each policy adjustment with the reason and the approver. Upgrades, changes to the identity provider and newly installed apps can all alter sharing behavior without any policy change on your side. A new major release, a change to how LDAP or OpenID Connect attributes map to groups, or an app that adds its own share types can each change who sees what. For that reason, add a sharing policy test to the change process for every upgrade and identity change: create a guest, attempt the sharing paths your policy allows and blocks, check the results, and record them before the change is approved. Confirm the exact test cases with your security team, since they depend on the configuration you deploy.

Limits to confirm in your environment

Guest accounts and external sharing depend on details that differ by edition, directory backend, server version and encryption mode. Each card names one limit to test on a staging server or confirm in the vendor documentation before you commit to a sharing model.

Sharing features by edition

Confirm which guest, link and sharing options exist in the community edition and which sit in Nextcloud Enterprise, since the paid tiers are sold with a 100-user minimum. Check the admin panel of a test server running the exact release you plan to deploy, then compare the result with the vendor's edition documentation and pricing page. Record the answer in writing, because a feature assumed from an older release or a forum post can change the design of the whole sharing model.

Guest behavior under LDAP

Nextcloud's LDAP app lets directory users appear in Nextcloud and sign in with their directory credentials. Test whether guest accounts for outside collaborators can coexist with your LDAP user filter, whether a guest can ever match a directory object, and what happens to existing share links when a user is disabled in the directory. Document the outcome for each backend you plan to run.

OIDC and SAML sign-in paths

Nextcloud documents OpenID Connect and SAML as user authentication backends. Before you rely on either for outside collaborators, confirm how identity provider group claims map to Nextcloud groups, whether guests can be provisioned from the identity provider or must be created locally, and whether identity provider multi-factor sign-in applies to share link recipients. Each path also determines how deprovisioning removes access, so test a revoked identity end to end.

Federated sharing and server versions

Federated sharing lets a user on one Nextcloud server share files with a user on another, and it requires the feature to be enabled on both servers and a version pairing the vendor supports. Check the federation setting on each side, confirm the server versions involved against the vendor's maintenance and release schedule, and test a share in both directions after every upgrade. Also confirm that firewalls and DNS allow the server-to-server requests the feature makes.

Link settings with encryption and access rules

Link passwords, expiry dates and download restrictions interact with server-side encryption, end-to-end encrypted folders and file access control rules in ways that are easy to assume incorrectly. On a test instance, confirm whether a share link can expose a file that an access rule would otherwise block, whether an end-to-end encrypted file can be shared by link at all, and whether the chosen encryption mode lets a link recipient read the content. Record the result for each encryption mode you offer.

Upgrade timing and support window

Nextcloud publishes a new major version every four months and supports each one for a year through monthly maintenance releases. Sharing behavior can change between majors, and the vendor's upgrade guidance does not allow skipping a major release. Confirm the end-of-life date for your current version, plan the path one major version at a time, and re-test guest and federated shares on a copy of production before each step.

What external sharing setup costs and what it needs from your team

What drives the cost of setting up external sharing in Nextcloud?

The main drivers are how many outside groups need access, how those people sign in, whether partner servers must exchange files through federation, and how many sharing rules you must encode.

Outside groups: each group needs its own role boundaries, share scope and a named internal owner.
Identity integration: guests federated from LDAP, Active Directory, OpenID Connect or SAML need attribute and group mapping plus test logins.
Federation: partner servers add trust setup, coordinated changes and a shared test plan.
Policy complexity: link expiry, password rules, download limits and invitation rights each add configuration and sign-off.
Testing and documentation: these are often the largest effort and are easy to underestimate.

Ask any quote to itemize these components separately so you can see what each one costs and what changes if scope grows.

Can our internal team set up Nextcloud guest accounts without a partner?

Yes, a team that already runs Nextcloud and its identity provider can configure guest accounts and link policies using the admin documentation.

The harder questions are whether the team has time to design the sharing policy, build test accounts for each outside group, test each upgrade step and write the runbook. Internal teams often struggle with the boundary between guest and full user roles, with federation trust to partners, and with keeping settings consistent through major upgrades. Nextcloud major versions arrive every four months, each supported for one year, so the maintenance load recurs.

A useful test is whether someone outside the build team can explain who may share what, and reproduce it. If not, a fixed-scope review or build may cost less than learning under pressure in production. Confirm your team's skills in identity integration and upgrades before deciding.

How long does external sharing setup take and what sets the timeline?

The timeline depends on scope, and no fixed duration applies to every deployment, so ask for a schedule built from your own inputs.

The main factors are how many outside groups and partner servers are in scope, how many identity sources must be connected, how many policy decisions need sign-off, and how much testing the change requires. Scheduling also depends on your change windows and on the availability of an identity administrator and a sharing policy owner for review sessions.

A fixed-scope agreement sets deliverables and timing in writing before work starts, so the duration appears in that document. Ask for milestones that name who must act at each one, and confirm that the plan includes time for test accounts, rollback checks and documentation.

What does our team need to provide before external sharing work starts?

Your team needs to supply the decisions, access and test resources that the build depends on.

Identity sources: details of the LDAP, Active Directory, OpenID Connect or SAML source, plus admin access to configure it.
Sharing policy owner: one named person who decides what outsiders may access and who signs off on rules.
Test accounts: at least one test guest for each outside group, and a contact at each partner server if federation is in scope.
Change window: agreed times for configuration changes, upgrades and rollback.
Current environment access: the installed Nextcloud version, the list of installed apps, and recent backups.

Missing inputs are the most common reason guest work slows down, so confirm each item before the design phase begins.

Why does a fixed-scope agreement matter for guest and sharing work?

A fixed-scope agreement is written before work starts, so scope, deliverables and timeline are on paper before any change is made. For this topic that matters because cost moves with the number of outside groups, identity sources, federated partners and policy rules.

Ask that the agreement name the outside groups, the identity sources, whether partner federation is included, which tests are delivered and what documentation you receive. Ask how changes requested after signing are scoped and priced. Also confirm who owns the sharing policy after handover.

DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue audit reports and certifications, so keep that boundary in the agreement.

What do Nextcloud Enterprise subscription prices mean for this project?

Nextcloud Enterprise is a separate paid subscription from Nextcloud GmbH, sold in Standard, Premium and Ultimate tiers with a 100-user minimum.

Nextcloud's pricing page lists per-user yearly prices from 71.29 euros for Standard, 104.99 euros for Premium and 204.75 euros for Ultimate, for 100 or more users, with lower rates from 200 users. These are list prices. Confirm them with Nextcloud before budgeting, since they can change and may not match your negotiated terms.

The tiers differ in maintenance lifecycle, support hours and response times, so compare those features against your requirements. Subscription is a recurring cost, while DeployOpen's services are quoted separately from the written scope. Whether you need an Enterprise tier at all depends on your support and lifecycle needs.

Which identity source should guest logins use in Nextcloud?

Choose the source that already governs the outside identities you trust, then confirm that your Nextcloud version supports that backend.

Nextcloud's LDAP app lets directory users appear in Nextcloud and sign in with their directory credentials. Nextcloud also documents OpenID Connect and SAML user authentication backends. Guests from outside your directory usually have no directory account, so an OIDC or SAML identity provider, or locally managed guest accounts, may fit better.

Test each path with a sample guest for login, group mapping, share visibility and sign-out. Keep group mapping simple so guests cannot inherit internal roles. Confirm the chosen backend and any extra apps against the version you plan to run before design sign-off.

What must you check after a Nextcloud major upgrade that touches sharing?

After each major upgrade, recheck guest login, group mapping, link policies and federation trusts using the test accounts you built.

Nextcloud does not allow skipping major releases, so upgrade one major version at a time. Back up before every upgrade, and disable third-party apps until they are confirmed compatible with the new version. Sharing settings depend on apps and identity configuration, so an upgrade can affect them even when the core features look normal.

Nextcloud 35 was released on 16 September 2026, and new major versions arrive every four months, each supported for one year. Confirm each step against the upgrade documentation and the system requirements for that version, including PHP and database versions. Record results in the runbook so the next upgrade repeats the same checks, and schedule a change window long enough to roll back.

How DeployOpen scopes and delivers guest and sharing controls

DeployOpen plans guest accounts and external sharing as one design inside the Nextcloud deployment, alongside identity and storage. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Each sharing rule is tested against the documented behavior of the Nextcloud version you run.

How we scope

The written scope lists which user groups may be invited as guests and which folders they can reach.
Public link policy, expiry defaults, password rules and reshare settings are listed and agreed before the build starts.
Federated sharing with other Nextcloud servers is covered only where the scope names the partner servers and their administrators.

How we build

Where guests authenticate through your identity provider, the integration is configured and tested against the chosen authentication backend.
Sharing permissions, group restrictions and link settings are applied and checked with test accounts for each role.
Test cases cover guest access to shared files only, expired shares, password-protected links and attempts to reach unshared folders.

How we hand over

A configuration record documents every sharing setting, its default, its owner and the reason it was set.
Administrators receive a runbook for onboarding and offboarding guests, revoking shares and reviewing external access.
Test results and open items are delivered with the system so your team can repeat the checks.

How we support

Ongoing support is available as a retainer, covering upgrades, guest policy reviews and changes to sharing rules.
Each Nextcloud major upgrade is checked against sharing and guest behavior before it reaches production users.
Changes to guest access are re-tested after each update, and access reviews can be scheduled with your team.