Skip to main content

Jira Attachment Permissions FAQ: Download, Access & Troubleshoot

· 12 min read
NGPilot
NGPilot
NGPilot

Managing attachments in Jira sounds straightforward until users start reporting that they cannot download files, the bulk downloader is missing items, or attachments disappeared after a migration. Most of these problems trace back to permissions, storage configuration, or network infrastructure rather than a bug in Jira itself.

Jira's permission model is layered: global settings, project roles, issue-level security schemes, and workflow properties all feed into whether a user can view or download a given attachment. Understanding how these layers interact is the key to diagnosing problems quickly.

This FAQ covers the most common attachment-related issues we hear about, explains why they happen, and walks you through concrete resolution steps. Whether you are a Jira administrator investigating a support ticket or an end user trying to understand why a download failed, the sections below should point you in the right direction.

Why can't I download some Jira attachments?​

The most common cause is a missing View Attachments permission on the project or issue in question. Jira ties attachment visibility directly to issue visibility: if a user cannot see the issue, they cannot see its attachments. Even when a user can view the issue itself, a project administrator or scheme configuration may have removed the View Attachments permission from their role.

Issue-level security adds a second gate. Some projects use security schemes to restrict which users or groups can access certain issue types (for example, security vulnerabilities or HR tickets). If an issue is protected by a security level that excludes your account, every attachment on that issue will be invisible regardless of your project-level permissions.

If you are confident your permissions are correct and the problem persists, ask a Jira administrator to verify the issue. An admin can use the Permission Helper tool (available under Administration > System > Permission Helper) to check exactly which permissions your account holds on a specific issue. This tool reports whether you have View Attachments, whether any issue security level blocks you, and which permission scheme is in effect.

Why does the bulk downloader show fewer files than expected?​

Simple Bulk Attachment Downloader (and similar tools) respects Jira's permission model. It can only list and download attachments that the authenticated user is allowed to see. If another user uploaded files with restricted visibility or if the uploader limited file access to a specific group, those attachments will not appear in your bulk download session.

Another frequent cause is restricted uploads. Some projects allow only certain roles to attach files. If you are not in that role, you may still be able to view the issue but not the attachments added by users who do hold the upload role, depending on how the permission scheme is configured.

The fastest way to confirm is to ask a Jira project administrator or system administrator to run the same bulk download with an admin account. If the admin sees more files than you do, the gap is permission-related. If the admin also sees fewer files than expected, the attachments may have been deleted or the JQL filter used by the downloader may need adjustment.

Why are attachments missing after a Jira migration?​

Migrations between Jira instances (Server to Data Center, Server to Cloud, or even host-to-host moves) are a common source of attachment loss. The usual culprit is a mismatch between the attachment storage path configured in the source instance and the path in the target instance. Jira stores attachments on disk in a directory that is defined in jira-config.properties or through the Administration console under Attachments. If the target instance points to a different directory, or if the migration tool did not copy the attachment directory, the links in the database will point to files that do not exist on the new server.

To diagnose this, open the Jira administration console on the target instance and navigate to System > Attachments. Verify that the attachment path matches the location where files were restored. Then pick a known issue with attachments and check whether the file exists on disk at the expected path.

Link integrity is another factor. The database stores attachment metadata (filename, size, author, issue ID) separately from the files on disk. If the database was migrated but the file system was not, or vice versa, attachments will appear broken. Ensure that both the database and the attachment directory were included in the backup and restore process. Tools like Jira's built-in XML backup, Atlassian's JCMA (Jira Cloud Migration Assistant), or third-party solutions each handle attachment migration differently; consult the tool's documentation to confirm that attachments are covered.

Can antivirus or proxy software block Jira attachment downloads?​

Yes, and this is more common than many teams realize. Corporate network proxies, web application firewalls, and endpoint antivirus products can all interfere with attachment downloads. The interference usually takes one of two forms: file-type filtering or domain-level blocking.

File-type filtering blocks downloads of certain extensions such as .exe, .zip, .jar, or macro-enabled Office files (.xlsm, .docm). The proxy inspects the response headers or URL pattern and drops the connection. Users see a generic browser error rather than a Jira error, which makes the problem hard to trace back to Jira.

Domain whitelisting issues occur when the proxy does not recognize the Jira attachment download URL pattern. Jira serves attachments through paths like /secure/attachment/ followed by a numeric ID and filename. If your proxy rules only whitelist the base Jira domain but not these sub-paths, downloads may fail silently.

To resolve this, ask your network team to whitelist your Jira domain (including all sub-paths) and specifically allow the /secure/attachment/ URL pattern. If you are using Simple Bulk Attachment Downloader, the ZIP file downloads through your browser's built-in download manager, so ensure your browser download settings allow large file downloads and that no corporate proxy blocks ZIP file responses.

What are Jira's attachment size limits?​

Jira enforces two configurable size limits for attachments:

  • Per-file limit (default: 10 MB). Any single file larger than this value is rejected at upload time. The user sees an error message in the attachment dialog.
  • Per-issue limit (default: unlimited on Server/Data Center; Cloud enforces a total that varies by plan, with a practical maximum of 104 MB per issue on some tiers). This controls the combined size of all attachments on a single issue.

Administrators can adjust both limits. On Jira Server and Data Center, navigate to Administration > System > Advanced > Attachments. On Jira Cloud, the limits are managed under Project settings > Attachments or through the global administration area.

If users are consistently hitting the per-file limit, consider whether large binaries (virtual machine images, database dumps, video files) belong in Jira at all. A better workflow is to store large artifacts in a dedicated file-sharing or artifact management system and link to them from the Jira issue. This keeps Jira's attachment storage lean and avoids the need to raise limits for everyone.

To check your current limits, open an issue and attempt to attach a test file of known size. Jira will display a clear error message if the file exceeds the configured maximum. You can also inspect the settings directly as an admin under the Attachments configuration page.

How do I troubleshoot Jira attachment permission errors?​

Start with a systematic approach rather than guessing. The following diagnostic steps will resolve the majority of attachment permission problems:

  1. Reproduce the issue as an administrator. Log in with a Jira admin account and attempt the same action the user reported (view the issue, download the attachment, run the bulk downloader). If the admin can perform the action but the user cannot, the problem is permission-related. If the admin also fails, the problem is likely in storage, configuration, or the attachment itself.

  2. Verify issue-level permissions. Use the Permission Helper (Administration > System > Permission Helper) to check which permissions the affected user holds on the specific issue. Enter the user's name, the issue key, and select View Attachments. The helper will show you the exact permission scheme, project role, and any issue security level that applies.

  3. Check that the attachment still exists in storage. Navigate to the attachment directory on the Jira server (or check the Cloud storage status) and confirm the file is present. Attachments can be deleted directly from disk by automated cleanup scripts or storage migration errors, leaving orphaned metadata in the database.

  4. Review the audit log. Jira's audit log records attachment creation and deletion events. Search for the issue key or the attachment filename to see if the file was deleted by a user or an automated process. On Server and Data Center, find the audit log under Administration > System > Audit Log. On Cloud, it is under Project settings > Audit Log.

  5. Confirm the user's role includes both Create Attachments and View Attachments. Some permission schemes grant one but not the other, leading to situations where a user can upload but cannot later download their own uploads, or vice versa.

Jira attachment permission hierarchy​

Understanding the order in which Jira evaluates permissions helps you trace why a particular user can or cannot access an attachment. Jira checks permissions in the following layers, and the most restrictive result wins:

Global permissions. These are site-wide settings managed under Administration > System > Global Permissions. The Use Jira permission determines whether a user can log in at all. The Jira Administrators and Jira System Administrators global permissions bypass most project-level restrictions.

Project permissions via permission schemes. Every project is associated with a permission scheme. The scheme maps each permission (including View Attachments and Create Attachments) to a combination of project roles, groups, assignees, reporters, and other criteria. If the scheme does not grant View Attachments to the user's role on the project, the user cannot see attachments on any issue in that project.

Issue security schemes. Applied at the issue level, these schemes restrict visibility of specific issues to certain users or groups. An issue security level is more restrictive than project permissions; it can hide an issue (and all its attachments) from users who would otherwise have full project access. Issue security is typically used for sensitive issue types such as security vulnerabilities or executive escalations.

Workflow properties. Jira workflows can include conditions or properties that restrict actions based on the issue's current status. For example, a workflow property might prevent attachment uploads when an issue is in the Closed status. This does not affect viewing existing attachments, but it can prevent new uploads.

When diagnosing attachment problems, work from the bottom of this hierarchy upward. Start with workflow properties and issue security (the most specific), then check the permission scheme, and finally confirm global permissions.

Troubleshooting flowchart​

Follow this numbered diagnostic process when a user reports an attachment access problem. Each step either resolves the issue or narrows down the next area to investigate.

  1. Ask the user to open the specific issue. If they cannot open the issue at all, the problem is issue-level security or project visibility. Move to step 5.

  2. Check whether the attachment icon or section is visible on the issue. If the section is hidden entirely, the user lacks the View Attachments permission. Move to step 4.

  3. If attachments are visible but a specific file cannot be downloaded, attempt to download it as an administrator. If the admin can download it, the user's session or network may be the problem (proxy, antivirus). If the admin also fails, the file may be missing from storage. Move to step 6.

  4. Verify the permission scheme. Open Administration > Issues > Permission Schemes, find the scheme used by the project, and confirm that View Attachments is granted to the user's project role or group.

  5. Check issue security. Open the issue and look at the security level displayed near the issue summary. Navigate to the issue security scheme and verify that the user's group or role is included in that security level.

  6. Verify storage. On Server or Data Center, check the attachment directory path in jira-config.properties and confirm the file exists on disk. On Cloud, verify the attachment is not flagged as corrupted in the issue view.

  7. Review the audit log for deletion events or migration activities that may have affected the attachment.

  8. Check network infrastructure if the file exists and permissions are correct but downloads still fail. Ask the user to try from a different network or have IT review proxy and antivirus logs for blocked requests.

Quick admin checklist​

Before escalating an attachment problem, run through these five items. Most issues are resolved by one of these checks.

  1. Confirm the user has View Attachments permission on the project via the Permission Helper tool. This single step resolves more than half of all reported attachment problems.

  2. Verify issue security levels are not blocking the user. Open the issue and check the security level; ensure the user's group is listed in the corresponding issue security scheme.

  3. Check the attachment storage path in Administration > System > Attachments. Confirm the path is correct, writable, and that disk space is available. A full disk will cause silent upload failures.

  4. Review the Jira audit log for the affected issue key. Look for attachment deletion events, migration entries, or permission scheme changes that coincide with the reported problem.

  5. Test from a different network if permissions and storage look correct. Have the user attempt the download over a mobile hotspot or VPN to rule out proxy or antivirus interference.