Nextcloud Team Folders: moving departmental shares into managed team spaces
Team Folders are admin-managed shared spaces in Nextcloud, configured with group permissions, quotas, advanced permissions and trash handling, and they are the usual target when departmental network drives need to move onto the same platform as the rest of the organization's files. If you run IT or platform engineering, you probably recognize the starting point: a set of SMB shares built up over many years, where access was granted to individual users, nested groups were added during reorganizations, and nobody holds a complete list of who can read or change what. Team Folders shift control to the administrator. Access is assigned to groups that your directory already maintains, and space limits and recovery rules are set centrally so that each team's habits no longer decide them.
Teams usually implement Team Folders for a small set of reasons. The first is replacing SMB shares that have outlived their server or their permission model. The second is consolidating duplicate drives, where the same department has copies on several file servers and no one is sure which one is current. The third is adding controls the old shares never had, such as quotas per space and a recovery path for deleted files. Each reason changes the scope. A pure replacement is mostly a copy and cutover exercise, while consolidation requires a decision about which copy becomes the source of truth and what happens to the others. Confirm the exact quota, advanced permission and trash retention options in the Team Folders documentation for your Nextcloud version before you write them into a design.
Installation is the smallest part of this work. The main effort is planning, identity mapping and migration. Identity mapping means deciding how each Team Folder's access groups are sourced: from LDAP or Active Directory through the LDAP user and group integration, or from group claims passed through OpenID Connect or SAML. You need to know which groups are security groups, which are distribution lists, and which are nested, because nested groups can produce access that nobody intended. Migration means inventorying existing ACLs, deciding one Team Folder per team or per data set, handling file names and path lengths that Nextcloud may reject, and testing sync clients against the new paths before users move. Each of these steps has an owner, and most delays come from ownership questions rather than from technical ones.
Whether to use an internal team or an implementation partner depends on how many shares, groups and owners are involved and how much permission history has to be reconciled. Ask any partner for a written scope that lists the share inventory method, the group mapping approach, the migration waves, the test and sign-off steps and the handover documentation. Separate the one-time costs, which are planning, mapping, migration and testing, from the recurring ones, which are administrator time for quota and group reviews and the upgrade work that comes with each Nextcloud major release. Nextcloud requires one major version at a time and a backup before every upgrade, so the recurring work should be in the plan from the start. A quote is only comparable when it states which of these items it covers.
What Nextcloud Team Folders do according to the platform docs
Team Folders give an administrator one shared folder with access granted to groups, not individual users. The behavior an administrator configures and the behavior a user experiences both depend on the Nextcloud version you deploy, so confirm each option against the Team Folders documentation for that version before you write your access model.
Group-based access to a folder
An administrator attaches a Team Folder to one or more groups from the directory or local group list, then sets the permission level each group receives. Users see the folder in their file list only when they belong to a granted group, so membership changes in the directory change access without touching the folder. Confirm how group sources are resolved when you connect LDAP or Active Directory, and whether nested groups are included in your version.
Quotas per folder
A Team Folder can carry its own storage limit, separate from the user quota that applies to personal space. Administrators set the limit in the Team Folder settings, and users see the used and available space when they open the folder. Confirm whether the folder quota counts file versions and trash in the same way your version's quota documentation describes, because that changes how much space a team actually has.
Advanced permissions beyond read and write
Team Folders support permission sets that go beyond read and write, such as allowing users to share files, to create or delete, or to see files they did not create. Administrators choose these per group, and users only see the effects in their sharing and file actions. List the permissions your teams need, then map each one to the option names in the documentation for your Nextcloud version before you grant them.
Trash and deleted-file handling
Files deleted from a Team Folder move to a folder-level trash rather than disappearing from the team's view at once. Retention of trashed items and versions is governed by server settings, and the same retention applies to every member of the team. Confirm the retention defaults and who can restore items in your version, since a user who deletes a file may not be the only person who can recover it.
Access from sync clients and the web interface
Team Folders appear in the Nextcloud web interface and in the desktop and mobile sync clients for members of a granted group. Administrators should test how the folder mounts in each client, how selective sync treats it, and how file locking and conflicts behave when two people edit the same document from different clients. Confirm client version support and sync behavior in the documentation for the release you deploy.
How group membership, quotas and advanced permissions interact in a Team Folder
The decision that matters most is which layer decides each user's access, because a Team Folder check combines several sources. Access starts with membership: users reach a folder only through the groups the administrator assigns to it, so effective rights come from the groups the user holds in Nextcloud at the moment of access. If your directory feeds those groups through the LDAP app, the directory is the source of truth, and a removal there reaches the folder only after the next synchronization. Confirm the sync interval and whether a removed member loses access immediately or at the next login. Record which group receives which folder permission set in a table you can hand to an auditor and to the next administrator.
Advanced permissions sit on top of the basic read, write, create, delete and share rights. Their job is to narrow access for part of a group, and depending on the rule type, to extend it, so the effective right is the result of both layers. A group granted write at folder level may still be blocked from deleting if an advanced rule restricts that action, while a second group with narrower basic access may gain a capability through a rule. Before rollout, list every advanced rule per folder, note which groups it targets and confirm with the vendor documentation for your release how multiple matching rules are evaluated. Do not assume the order in which rules were created decides the outcome.
Support tickets often start with nested and overlapping membership. A parent group in your directory does not grant Team Folder rights on its own unless its members are resolved into the Nextcloud groups that the folder references, so confirm how your LDAP or Active Directory group nesting is imported. A user who belongs to several teams usually receives the combined grants from each group, which surprises administrators who expected the most restrictive group to win. Quota is shared across everyone with access to the folder, so one busy team can exhaust space another team relies on. Test each overlap case explicitly instead of assuming the directory structure carries over unchanged.
Quotas fill in ways users do not expect. The usage shown for a folder can include files in the trash and earlier file versions, not only the current files, so a team that deletes large files may still find the folder full. Confirm in your release whether trash and versions count against the team folder quota, and what users see when the limit is reached, such as blocked uploads, partial saves or warnings. Set trash and version retention together with the quota, since changing one changes how much space the other consumes. Ask the vendor or your test results to show the usage figure before and after a delete.
Close the design by building a test folder that copies your actual group structure, including nested directory groups, a user in several teams, a disabled account and a team with a small quota. For each combination of group, basic permission, advanced rule and quota state, write the expected result before testing, run the action as a test user and record what happened. Where the result differs from the expectation, fix the design or the documentation before production. Repeat the matrix after each upgrade and after any directory change, and only then move the permissions into production. The combinations in this matrix are illustrative, so adapt them to your own teams.
Which configuration decisions shape a Team Folders rollout
This table compares the six configuration decisions that shape a Team Folders rollout, with the options for each and the organizational conditions that make each option fit. Read each row against your directory, storage and records policies before choosing a setting. The main takeaway is that group source and permission model are the decisions most costly to change once users have data in place, so settle them first.
| Decision | Options | When each option fits |
|---|---|---|
| Group source | Local groups; LDAP or Active Directory groups through the LDAP app; groups from OpenID Connect or SAML | Local groups fit a small pilot with no directory. LDAP or Active Directory fits when departments already have directory groups. OpenID Connect or SAML fits when the identity provider is the source of truth for membership. |
| Folder structure | One folder per department; one per project; one per function | Departments fit stable reporting lines. Projects fit time-boxed work with clear owners. Functions fit shared services such as finance or HR, where roles outlast reorganizations. |
| Quota policy | No quota; a default quota per folder; quotas set per team | No quota fits pilots or storage already capped at the infrastructure level. A default fits teams with similar needs. Per-team quotas fit groups with very different storage demands. |
| Permission model | Basic permissions; advanced permissions | Basic fits teams where members read and write and admins manage the folder. Advanced fits teams that need read-only or delete-restricted roles. Confirm which permission options your Nextcloud version exposes. |
| Trash and version retention | Default retention; retention set by the administrator | Default retention fits content with no records duty. Administrator-set retention fits data that must be kept or purged on a schedule. Confirm the rules with your records owner before go-live. |
| External sharing of team content | Allow external shares; internal users only; external shares for named groups only | External shares fit client-facing projects. Internal only fits confidential or regulated departments. Named-group allowance fits teams that work with a few known partners. |
The rollout sequence, from share inventory to decommissioning network drives
The sequence moves a team from departmental network drives to Nextcloud Team Folders without losing access control or data. Each step closes with a named artifact, from a signed-off access matrix to a decommissioning record, so the project can be paused or reviewed at clear points. The order matters because permissions and quotas are only meaningful once owners and identity groups are settled.
Inventory existing shares and their access lists
Before any build starts, list every departmental share with its path, size, owner of record, and the users and groups that can reach it, exported from the file server or NAS. Include shares mapped by login script or group policy, since those are easy to miss. Confirm the target Nextcloud version against the release schedule before the build starts, because the version determines which server, database and PHP requirements apply. Output: a share inventory the data owners can review. Decision owner: the IT lead who holds file server access. Done when every share has a named owner of record or is flagged as unowned.
Agree the team model with named data owners
Decide how teams map to Team Folders: one folder per department, per project, or per cross-functional group, and whether sub-folders inherit the parent permissions. Each folder gets one named data owner who approves who may be granted access and how external access is handled. The data owners make these decisions, and the CISO or IT governance lead signs off the model. Output: a short team model document listing each folder, its owner and its purpose. Done when every proposed folder has an owner who has accepted it in writing.
Map identity groups to intended folder access
Connect the directory groups that already reflect job roles to the access levels each Team Folder needs, such as read, write or manage. Where users come from LDAP or Active Directory through the LDAP app, confirm which groups are synchronized and which are created locally in Nextcloud. Test that a membership change in the directory reaches the folder access you expect, including removal. Output: a signed-off access matrix pairing each folder with its groups and access levels. Decision owners: the data owners approve their rows, and the identity team approves the group source.
Configure a pilot Team Folder on a test instance
Build the pilot on a non-production Nextcloud instance that matches the planned production stack, including database, PHP version and web server. Enable the Team Folders app, create one folder for a willing team, and attach the groups from the access matrix. Before any version change during the project, confirm that it moves one major version at a time, with a backup taken before each upgrade and third-party apps disabled until confirmed compatible. Output: a configured pilot folder and a written test script. Decision owner: the platform lead.
Set quotas and advanced permissions
Set a storage quota for each Team Folder based on the sizes captured in the inventory and the growth the data owner expects. Configure advanced permissions for sensitive folders, such as restrictions on resharing, and decide how trash and file version retention apply to deleted team files. Confirm how trash behavior works in the version you run before you set the policy. Record each setting so the quota and retention behavior can be explained to auditors later. Output: a settings record per folder, reviewed against the access matrix. Decision owners: the data owner for quota and retention, and the security lead for sharing restrictions.
Migrate and test the pilot
Copy a representative set of files from the pilot share into the Team Folder, preserving the folder structure. Compare file counts, sizes and checksums against the source, then run the test script: sign in as a user in each group, confirm read, write and denied access, check sync to desktop and mobile clients, and confirm quota warnings appear. Log every failure and fix it before moving to the next step. Output: a tested pilot with recorded results. Decision owner: the data owner accepts the pilot in writing before wider rollout.
Run a parallel period and cut over by team
Run the old share and the Team Folder side by side for each team, with users told which location is authoritative for new work. Move teams in batches, syncing remaining changes from the share at each cutover, and set the old share to read-only once a team has moved. Track support requests and access complaints during the period to find gaps in group mapping. Output: a cutover plan with a schedule per team and a rollback step for each batch. Decision owners: the IT change manager runs the plan, and each data owner approves their team's cutover.
Retire the old shares and record decommissioning
When every team has cut over and no access requests remain open for the old shares, remove the share mappings from user devices, login scripts and group policy. Archive or delete each share according to the retention rule agreed in the team model step. Record the removal date, who approved it, and where any archived copies are held. Output: a decommissioning record that an auditor can trace back to the original inventory. Decision owners: the data owners approve deletion, and the CISO or records owner approves archive handling.
Migrating network drives into Team Folders without losing access intent
Copying files is the easy part of this migration. What usually breaks is access intent. Network share permissions often work through nested groups, direct user grants and rights inherited from parent folders, and these do not map one to one onto the group permissions a Nextcloud Team Folder applies. Before anything moves, export the current access control entries for each share and record which principal holds which right and where that right comes from. Then decide which directory groups will carry access into each Team Folder and which direct user grants need a group of their own.
Run a pre-copy scan on every share. Look for duplicate file names, names that differ only by letter case, and names with characters or trailing spaces or dots that Windows clients or the Nextcloud server will reject. Flag very deep paths, since they can exceed path length limits on the target or on client machines. Identify locked or open files that will change during the copy, and large files that need a resumable transfer. Finally, list files owned by departed users, because their ownership must be reassigned or their content archived before cutover. Confirm the length and character limits for your server and client versions, and keep the scan results with the migration record.
The next decision is whether to rebuild permissions by hand or from a written mapping. Hand rebuilding can work for a few small shares, but it is slow, depends on memory and leaves no reviewable record. A mapping table, with one row per source principal giving the target group, the Team Folder permission set and any exception, is repeatable and can be checked by someone who did not build it. Deny rules and inheritance breaks have no direct equivalent, so the mapping must name how each one is handled. Test the mapping on a copy of one share and compare effective access for a sample of users in both systems before you rely on it.
Bandwidth and sync client load determine how long the cutover window stays open. The final delta copy must run while writes to the source share are frozen, so its duration depends on the data that changed and on the throughput between the source and the Nextcloud server. Desktop clients that reconnect after cutover can also pull large amounts of data at once, so stagger users into the new Team Folders in groups. Ask your network team for the sustained throughput available during the window, and confirm that your copy tooling supports incremental passes. Confirm the copy method and tooling for your share type, such as an SMB file server, a NAS or DFS namespace, because the information supplied for this page does not cover SMB migration tools.
What drives Team Folders effort and how to keep it down
This table lists the factors that change how much work a Team Folders rollout takes, what each one does to effort, and what the team can do to reduce it. Read the one-time and recurring notes in the last rows alongside the rows above them, because they decide what a quote should cover.
| Driver | Effect on effort | How to reduce it |
|---|---|---|
| Number of shares and depth of access lists | Each Team Folder needs a permission design, group mapping and a test pass. Nested groups and per-user exceptions multiply the checks and the support questions after go-live. | Agree a folder inventory before build. Map access to a small number of groups from the directory, and limit direct user grants to documented exceptions. |
| State of the directory: duplicate accounts, stale groups, unclear ownership | Cleanup usually takes longer than the Nextcloud configuration. Duplicate accounts and orphaned groups must be resolved before they are copied into new permissions, and unowned folders need a named owner before access can be approved. | Run a directory audit before scoping. Decide who owns each folder, retire unused groups, and confirm which identity source is authoritative for each user population. |
| Total data volume and file types | Volume drives migration duration, transfer windows and verification. Large numbers of small files, long paths, special characters and legacy formats add checks and exceptions to the migration of existing network drives. | Profile shares for size, file count, path length and file types. Archive or exclude data that no team needs, and agree a migration sample for validation. |
| Number of quota and retention rules to define | Every quota tier, trash retention setting and advanced permission rule needs a business decision, a configuration and a test. Rules that differ by team multiply this work. | Limit the number of quota tiers and retention profiles. Write the rules down with their owners before configuration starts so changes are not negotiated during the build. |
| User communication and client rollout | Users need notice of the new locations, access changes and desktop or mobile client setup. Each department that needs a different message or training session adds time, and sync client problems create support load. | Prepare one communication plan per user group. Pilot the client setup with a small team, and document the steps for drive mapping changes and retirement of old shares. |
| Integrations with other Nextcloud apps and identity sources | Linking group membership to an LDAP or Active Directory source, or to an SSO provider, adds mapping and testing. Dependencies on other apps, such as sharing, auditing or antivirus, widen the test matrix. | Confirm which identity source supplies group membership, and test group sync with real accounts. Keep integrations in the first release only when they are needed for go-live. |
| Upgrade cadence during the project | Nextcloud releases a new major version every four months and requires one major version at a time. A project that spans a release needs extra regression testing, and third-party apps may need to be confirmed as compatible before each step. | Choose the target major version at scope time, and freeze the upgrade schedule for the project window. Check the release schedule and third-party app compatibility before the build begins. |
| One-time work: design, cleanup, migration and training | These costs are paid once for the rollout. They rise with the number of shares, the dirty directory state and the data volume, and they are the largest part of most first-time projects. | Ask for each item to be listed separately in the quote so the reader can see which parts shrink when the directory is cleaned up first. |
| Recurring work after go-live: access reviews, quota changes and upgrades | Team access changes, new folders, quota adjustments and each Nextcloud upgrade continue after launch. Without a named owner, access drift and unreviewed exceptions return within a few reporting cycles. | Set a folder owner register and a review cadence in the handover. Ask whether support, upgrades and reviews are covered by a retainer or by separate work orders. |
How Team Folders connect to identity, editing and the rest of the platform
Team Folders take their users, groups and editing behavior from systems around them. Each connection needs a decision about who owns the source, which features the folder depends on, and how the combination is tested before teams rely on it.
LDAP and Active Directory groups
Team Folder permissions are usually granted to groups, so the directory decides who can reach each folder. Agree which LDAP or Active Directory groups map to which folders, who maintains those groups, and how nested groups and disabled accounts are handled. Test a joiner, mover and leaver before go-live. Confirm the group filter and attribute settings in the LDAP user authentication documentation for your version.
OpenID Connect and SAML sign-in
Federated sign-in changes how users reach their folders, but group information must still reach Nextcloud for Team Folder permissions to work. Agree which claim carries group membership, how accounts are created at first login, and what happens to sessions when the identity provider changes. Test with a user who belongs to several groups. Confirm claim mapping and provisioning in the authentication backend documentation before relying on defaults.
Nextcloud Office or Collabora Online
Editing happens inside the folder, so the office service has to respect the same permissions as the file itself. Decide between Nextcloud Office and Collabora Online, then agree who operates the document server, how users' browsers reach it, and how it is updated. Test editing, read-only shares and a user without edit rights on a Team Folder. Confirm connector requirements and supported versions in the vendor documentation for your release.
Collectives and Deck beside files
Teams often keep wiki pages and task boards next to their folders, and those items have their own sharing model. Decide which team owns each Collective or board, whether attachments stay in the Team Folder, and how membership changes are reviewed. Test that a removed member loses access to the board and to any linked files. Confirm how Collectives and Deck set or inherit permissions in their own documentation.
BorgBackup-based backups
The All-in-One installation includes BorgBackup-based backups, which should cover Team Folder data together with the database and configuration. Agree the backup schedule, retention period, offsite copy and who holds the repository passphrase. Run a restore into a test environment and check that files, versions and permissions for a folder come back intact. Confirm what the backup component includes and excludes in the All-in-One documentation.
ClamAV antivirus scanning
The All-in-One installation bundles ClamAV, and scanning matters most where teams receive files from outside the organization. Decide which upload paths must be scanned, how infected files are reported and isolated, and who responds to alerts. Test with a standard antivirus test file to confirm that detection and notification work. Confirm scan triggers, file size limits and failure behavior in the antivirus feature documentation for your version.
How much does a Nextcloud Team Folders implementation cost and how long does it take
What does a Nextcloud Team Folders implementation cost?
The cost is the labor to plan, build, migrate and hand over the setup, plus the infrastructure it runs on. DeployOpen does not publish a price list, and a quote follows from the written scope. One-time costs usually cover permission and folder design, identity group mapping, migration of existing network drives, testing, documentation and handover training. Recurring costs cover hosting, storage, backups, monitoring, patching and any Nextcloud subscription. Costs rise with the number of teams and folders, the volume and file types in current shares, and the number of approvals needed from data owners. When you request a quote, ask for a list of deliverables, the assumptions behind each line, what is excluded, who performs data cleanup, the acceptance criteria, and which costs recur after go-live.
How long does a Team Folders rollout take?
The duration depends on the drivers of the work, not on a fixed period. The main drivers are the number of teams and folders, how complex the permission model is, the amount of data to migrate, how quickly identity groups are ready, and how many review rounds data owners need. Migrations that run in waves usually take longer to close but reduce risk for each team. A pilot group with a small set of folders helps you measure real effort before committing to the full estate. Ask for a timeline in the written scope with milestones for design sign-off, pilot, each migration wave, and cutover, along with the dependencies that could move those dates.
What do identity, storage and data owner teams need to provide?
Identity teams need to supply the groups that will map to Team Folders, usually from LDAP or Active Directory, with stable names and clear membership ownership. Nextcloud's LDAP user backend lets directory users sign in with their existing credentials, so confirm the directory structure and a bind account early. Storage teams need to confirm capacity for current shares plus growth, the performance profile of the storage behind Nextcloud, and the backup targets. Data owners decide who owns each team folder, approve the permission and quota model, classify sensitive content, and confirm what must be migrated, archived or deleted. Missing decisions from these groups are one of the most common causes of delay.
Can an internal team implement Team Folders without a partner?
An internal team with Nextcloud administration experience can implement Team Folders, since the feature is managed by administrators and does not require custom development. The question is whether the team has time and skills for the parts that are easy to get wrong. A partner usually helps with permission model design across many teams, scripted migration and validation of file counts and permissions, performance and backup restore testing, upgrade planning for the first major release after go-live, and operational documentation. Compare the internal effort with the same scope as a written quote. Consider who will run the platform after handover, because that person needs to understand the design decisions.
Does the Nextcloud license tier change implementation work?
The license tier mainly changes support and maintenance, and it is separate from the implementation work. Nextcloud's pricing page lists Enterprise tiers named Standard, Premium and Ultimate, with a 100-user minimum. The list prices start at 71.29, 104.99 and 204.75 euros per user per year respectively for 100 or more users, with lower rates from 200 users. According to the same page, Standard includes one year of maintenance, Premium adds a maintenance lifecycle of five or more years plus extended support hours and clustered instance support, and Ultimate adds support up to 24/7 with response times down to one hour. Confirm current prices and terms with Nextcloud, because the implementation scope is the same whichever tier you choose.
How do Nextcloud upgrades during the project affect team folders?
Nextcloud does not allow skipping major releases, so each upgrade moves one major version at a time. Administrators should back up before every upgrade and disable third-party apps until they are confirmed compatible, according to Nextcloud's upgrade documentation. For Team Folders, this means you should test folder permissions, quotas, group mappings and migrated content on each target version before upgrading production. Confirm the app's compatibility with each version in your own environment, and schedule upgrades so they do not overlap with migration waves. If a major release lands during the project, plan the upgrade as a separate step with its own test and rollback criteria, and record which version each team folder was validated on.
What happens to deleted or trashed files during migration?
Files that are already deleted or sitting in the source trash are not usually part of a migration unless someone decides they should be. Decide the policy before the first wave: exclude them, archive them separately, or migrate them into the trash of the new folder. Nextcloud keeps deleted files in its trash for a retention period set by the administrator, so confirm how that setting applies to migrated content and what happens when a file is restored after cutover. Retention obligations may come from legal or compliance teams, so involve them early. Ask for the chosen rule to be written into the design and tested with a sample of deleted and restored files before the full migration runs.
How DeployOpen scopes and delivers a Team Folders rollout
DeployOpen starts by mapping your existing departmental file shares, their permissions and their owners before any Team Folder is created. The rollout is then built, tested and documented inside your own Nextcloud environment, with the handover designed around the admins who will run it.
How we scope
- Inventory existing network drives, their folder trees, group permissions and largest shares before choosing Team Folder boundaries
- Agree in writing which teams get Team Folders, who manages each one, and the quota and advanced permission rules applied to it
- Define the trash and retention behavior for deleted Team Folder content so it matches your data governance policy
- Confirm the identity source for group membership, such as LDAP or Active Directory, that drives access to each folder
How we build
- Configure Team Folders, group access, quotas and advanced permissions in a staging instance that mirrors your production setup
- Run a test migration of a sample network drive into a Team Folder and check file names, paths, timestamps and permissions
- Verify that sync clients, sharing links and trash restore behave as the written scope describes before production cutover
- Plan the migration of remaining network drives in waves, with rollback steps for each wave
How we hand over
- Deliver written documentation of each Team Folder, its owners, quotas, advanced permissions and the group rules behind them
- Train your administrators on creating, changing and retiring Team Folders, and on handling trash and restore requests
- Hand over the migration record showing which network drives moved into which Team Folders and what was left in place
- Document the upgrade checks to run before each Nextcloud major version change, following the one-major-at-a-time rule
How we support
- Offer ongoing support, upgrades and maintenance for Team Folders as a retainer after the fixed-scope rollout ends
- Review quota usage and permission drift with your administrators on a schedule agreed in the retainer
- Test Team Folder configuration again when a new Nextcloud release or an app update changes how permissions behave
- Ask for a written support scope that states response expectations, since these vary by agreement
