Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestion] - Suggestion to Disable S3 Storage for Avatars & Attachments #900

Open
1 task done
nagarajuvemula789 opened this issue Oct 29, 2024 · 2 comments
Open
1 task done

Comments

@nagarajuvemula789
Copy link

Suggestion

I would like to suggest disabling S3 storage for avatars and attachments. Despite enabling and commenting out the lines to disable S3 storage, it is still being used due to associations in the filestore-config.xml file.

Steps to Reproduce:

Enable and comment out the lines to disable S3 storage for avatars and attachments.
Observe that S3 storage is still being used.

Expected Behavior: S3 storage should be disabled for avatars and attachments when the corresponding lines are commented out.

Thanks in advance.

Product

Jira

Code of Conduct

  • I agree to follow this project's Code of Conduct
@nagarajuvemula789
Copy link
Author

Atlassian suggested below.
Switching back to local attachment storage
As the source file system data is not changed or removed by DataSync, Jira can be reverted back to reading and writing attachment data from the file system. To do this, remove the filestore-config.xml files from your directories and restart Jira. You can also delete the element targeting attachments.

Ref: https://confluence.atlassian.com/adminjiraserver/storing-attachments-in-amazon-s3-1282250191.html

@bianchi2
Copy link
Collaborator

@nagarajuvemula789 thanks for raising this. Indeed, if the file exists but s3 env vars aren't set, there's no process that would delete it. This will be fixed in the image entrypoint rather than in the Helm chart.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants