Restrict file access in self-hosted Atlassian Data Center at two levels: use each application’s permissions to control who can reach projects, repositories, spaces, issues, or pages, and secure the host directories and database that store the data. These controls are different: application permissions govern normal user access, while host security helps prevent unrelated local accounts from reading stored files directly. Keep the application service account’s required access intact.
Decide what “file access” means
A request to restrict files can mean limiting who may view the content associated with a file, who may upload or delete an attachment, or which local accounts and processes can read the underlying storage. Treat these as separate controls. Choose the application settings for user-facing access and file handling, then protect the storage boundary at the host level. The available settings and inheritance rules depend on the Atlassian product and version.
As an Amazon Associate I earn from qualifying purchases.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Restrict files in Jira Data Center
Limit who can see issue content
Review Jira’s global permissions and the permission schemes assigned to the relevant projects. The Browse Projects permission controls project access; issue security levels can narrow visibility further for selected issues. Comment and work-log visibility settings apply to those content types, not to attachments generally. Atlassian’s Jira permissions overview distinguishes application permissions from access controls in the external environment.
Control who can add or delete attachments
In each relevant project permission scheme, grant Create attachments only to the users, groups, or project roles that need it. If users should be able to remove only files they added, configure Delete own attachments separately. Also check the issue type’s field configuration: if the Attachment field is hidden, users cannot attach files while creating that issue, even if other attachment controls allow it. See Atlassian’s Jira file attachment configuration.
#1 Best Overall
- Pass the Atlassian Managing Jira Projects for Data Center and Server Certification with updated flashcards packed with detailed content aligned to the latest exam blueprint. Cover all core topics without the overload found in lengthy study guides. Get 300+ Atlassian Managing Jira Projects for Data Center and Server Certification flashcards on 8-1/2″ x 11″ perforated card stock.
Set an attachment extension policy
Jira 9.15 and later support allowlisting or blocklisting attachment extensions in attachment security settings. This is an upload policy, not a substitute for deciding who can access a project or for protecting the storage directories. Confirm the setting and its behavior in documentation for the Jira version you run.
Protect Jira’s stored data
Restrict operating-system access to the Jira index and attachments directories to the Jira service account and authorized operational staff. The Jira process needs its required access, so do not apply a restrictive rule that prevents it from reading or writing those directories. Atlassian’s permissions guidance identifies these directories as areas to protect at the filesystem level.
Use the procedures for your actual operating system, filesystem, storage mount, and operations runbook; the required ACL or permission commands are deployment-specific. Do not treat Jira’s application permission schemes as protection against a local account that can read the data files directly. Atlassian’s attachment guide says S3 attachment storage is not supported for on-premises deployments or customers not running Jira in AWS, so it is not an on-premises access-control option.
Restrict files in Confluence Data Center
Control access at global, space, and page levels
Confluence access depends on global permissions, space permissions, and any restrictions on the page. A user must be allowed into Confluence and have permission to view the space; page restrictions can narrow who may view or edit a particular page. Restrictions may be inherited from parent pages. Users with relevant space-administration or system-administrator rights can remove restrictions, so page restrictions should not be treated as a barrier against privileged administrators. Use Atlassian’s permissions and restrictions guidance to review the applicable layers. Confluence Data Center also provides Inspect permissions to help administrators determine a user’s effective access.
Understand the attachment download boundary
Space permissions include Add Attachment and Delete Attachment, which control uploading and removing files. They do not provide a separate download restriction. Atlassian states, “There is no permission that controls downloading attachments.” Anyone who can view a page can download files attached to it, so limit attachment visibility by limiting who can view the page and by setting appropriate space permissions. A link to an attachment is not rendered for someone who cannot view the page containing it. Details are in Atlassian’s attachments documentation.
Secure Confluence storage on the host
Limit which accounts can access Confluence’s installation and home directories, along with any configured attachment, export, or data-pipeline storage locations. Atlassian recommends running Confluence with a dedicated non-root account. Preserve the access Confluence requires, and use the host’s operational runbook for exact permissions and ACL syntax rather than applying generic commands. See Atlassian’s filesystem security guidance.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Restrict repository access in Bitbucket Data Center
Review project and repository permissions
Use project permissions to manage access across repositories in a project, then inspect repository-level permissions for exceptions. Project permissions are inherited by repositories by default. In Bitbucket 8.8 and later, a project setting can prevent repository administrators from managing repository permissions. That setting does not change permissions already set at repository level, so review existing repository grants instead of assuming the project setting removes them. Consult the documentation for your installed version, including Atlassian’s Bitbucket project permissions documentation.
This repository-level model is not evidence of a file-by-file authorization control inside a repository. Keep the access decision at the documented project or repository scope unless documentation for your deployed version establishes a narrower control.
Quick Recap
Apply the controls in a safe order
- Identify the product and version. “Atlassian Data Center” can mean Jira, Confluence, or Bitbucket, each with different permission models. Record the deployed version and where its data is stored.
- Define who needs access. Map users and groups to the appropriate application scope: Jira project and issue settings, Confluence space and page settings, or Bitbucket project and repository settings.
- Review file-handling rights separately. Check Jira attachment creation and deletion permissions or Confluence Add Attachment and Delete Attachment permissions. For Confluence downloads, control access to the page that contains the attachment.
- Protect the host storage. Restrict relevant directories and database access to the application service account and authorized administrators while preserving the service’s required access. Follow the runbook for the actual host, filesystem, and Atlassian version.
- Verify effective access. In Confluence Data Center, use Inspect permissions to check a user’s effective access. In Jira and Bitbucket, validate changes through the product’s administrative and audit procedures and confirm that intended users retain required access.
What to check before considering the change complete
- Scope: Is access meant to be site-wide, project- or repository-wide, space-wide, or limited to an issue or page?
- Action: Does the control govern viewing, uploading, deleting, or administering permissions?
- Storage boundary: Can an unrelated local account still read the files or indexes directly?
- Inheritance and exceptions: Are parent-page restrictions, project inheritance, repository-level grants, or privileged administrators relevant?
- Version and deployment: Are the Jira extension policy and Bitbucket permission-management setting available in the installed versions, and does the storage approach fit the deployment?
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
