Jira Attachment Permissions: Who Can See Your Files
The short version: Jira does not have per-attachment permissions. If a user can see an issue, they can see and download every file attached to it. There is no setting that changes this, and it surprises a lot of teams the first time it matters.
Here is the full picture.
The three permissions that do exist
Jira’s project permission scheme has exactly three attachment-related entries:
- Create Attachments controls who can upload a file.
- Delete Own Attachments controls who can remove files they uploaded themselves.
- Delete All Attachments controls who can remove anyone’s files.
Read that list again and notice what is missing. None of them controls who can view or download a file. Viewing is not a separate permission at all. It follows from whether the user can see the item the file is attached to.
An administrator finds these under Project settings then Permissions on Data Center, or the equivalent permission scheme on Cloud.
Why you are seeing “permission attach denied”
This is the most common attachment error, and it is almost always one of two things:
- Your account does not have Create Attachments in that project’s permission scheme. Someone with admin rights needs to add your group or role to that permission.
- Attachments are disabled globally. On Data Center this lives under Settings, System, Attachments, where an administrator can turn attachments off entirely or set the maximum file size. If attachments are off, no permission scheme will help.
A third, rarer cause is a file size or type restriction: the upload is rejected rather than the permission denied, but the message can read similarly. Data Center defaults to a 10 MB limit and administrators often change it.
The gap that matters
Because viewing follows item visibility, every attachment on an item is exposed to the item’s full audience. That is fine for a screenshot on a bug report. It is a problem the moment the file contains something the whole team should not see.
A worked example. A hiring process runs in a Jira project. The project is visible to the recruitment team, the hiring manager, and two interviewers. Someone attaches a candidate’s salary expectations and reference check to the item.
Every one of those people can now download both files. Not because anyone decided they should, but because file visibility was never a decision, it was a consequence of who could see the item.
You can restrict the item itself, but that hides the work tracking too, and the interviewers still need the work tracking. Native Jira gives you no way to separate the two.
Comment restrictions do not help either. Restricting a comment to a specific group hides the comment text. The attachment on the item stays visible to everyone who can see the item. These are two different mechanisms and only one of them exists for files.
What you can actually do
Separate the work by project
Move sensitive work into its own project or space with a tight permission scheme. This is the native answer and it genuinely works when the people who need the work tracking are the same people who should see the files.
It falls down when those groups differ, which is the case that sent most people looking for this article.
Keep the file outside Jira
Store it in a system with real document permissions and link to it. You get proper access control and version history. You also get two permission models to keep aligned, links that break, and readers who cannot open the document.
Add a second, access-controlled attachment area
Some apps add a separate attachment panel to the item with its own access list, so the item stays visible to the team while the files inside the panel do not.
Document Vault works this way. Access is configured for specific user groups, project roles, users named in single or multi-user custom fields, users in group custom fields, or the item’s Reporter, Assignee, or Creator, with full or read-only access. Users outside the list see nothing at all, not even file names.
The honest limitation: permissions apply to the Vault as a whole, not to individual files inside it. It separates “who sees the work” from “who sees the documents”. It does not give you a different access list per file. If you need genuine per-file permissions, no Jira app model gives you that today.
Quick reference
| What you want | Native Jira | Realistic approach |
|---|---|---|
| Control who can upload | Yes, Create Attachments | Permission scheme |
| Control who can delete | Yes, two permissions | Permission scheme |
| Control who can view a file | No | Separate project, external storage, or an access-controlled panel |
| Different access per file | No | Not available in any Jira model today |
| Version history on a file | No | External storage, or Project Documents in Document Vault |
| Hide file names from others | No | Access-controlled panel |
Frequently asked questions
Can you set permissions on a single Jira attachment? No. Jira has no per-attachment permission model. Every file on an issue or work item is visible and downloadable by everyone who can view that item. The only native controls are the project permission scheme, which governs who can attach and delete files, and the visibility of the item itself.
Why do I get “permission attach denied” in Jira? That message means your account lacks the Create Attachments permission in that project’s permission scheme, or attachments are switched off globally. A Jira administrator can check under Project settings, Permissions, Create Attachments, and confirm attachments are enabled in the global attachment settings.
Which Jira permissions control attachments? Three in the project permission scheme: Create Attachments, Delete Own Attachments, and Delete All Attachments. Note that none of them control who can view or download a file. Viewing is governed entirely by whether the user can see the issue or work item.
How do I hide an attachment from some users but not others? You cannot do this with native Jira. The workarounds are to move the sensitive work into a separate project with a tighter permission scheme, to store the file outside Jira, or to add an app that provides a second attachment area with its own access list.
Do comment restrictions also restrict attachments? No. Restricting a comment to a group hides the comment text only. A file attached to the issue or work item remains visible to everyone who can see the item, regardless of any comment restriction.
See also: Jira document management · How to restrict Jira attachments to specific users · Jira comment permissions · Permission scheme in the Jira glossary.