This documentation relates to the latest version of Confluence.
If you are using an earlier version, please go to the documentation home page and select the relevant version.

Attachment Storage Configuration

Added by Jeremy Higgs, last edited by Edwin Dawson [Atlassian] on May 14, 2008  (view change) show comment
All Versions
Click for all versions
Confluence 2.9 Documentation

Index

Confluence allows you to store attachments in one of three places:

  • Filesystem - locally in the Confluence home directory
  • Database - in Confluence's configured database
  • WebDAV - remotely on a WebDAV server (*deprecated*)

A System Administrator can configure Confluence's attachment storage via the 'Attachment Storage' option on the 'Administration Console'.

You need to have System Administrator permissions in order to perform this function.

Attachment Storage Options

Local File System

By default, Confluence stores attachments in the attachments directory within the configured Confluence home folder.

Database

Confluence gives administrators the option to store attachments in the database that Confluence is configured to use.

Here are some reasons why, as an administrator, you may want to choose this storage system:

  • Ease of backup.
  • Avoiding issues with certain characters in attachment file names.
    While storing attachments in the database can offer some advantages, please be aware that the amount of space used by the database will increase because of the greater storage requirements.

WebDAV

Confluence also allows administrators to set an external WebDAV repository as the location for attachment storage.

WebDAV attachment manager deprecated

The option to store Confluence attachments on a WebDAV server has never worked in a useful fashion, and has not been maintained for many versions.

  • The WebDAV attachment manager will be deprecated from Confluence 2.7, and will be removed from a later version of Confluence.
  • If you store attachments on external WebDAV servers, we recommend that you migrate to file-system or database-backed attachment storage as soon as possible. Refer to CONF-9313 and CONF-2887.
  • This DOES NOT affect the operation of the WebDAV plugin.

Migration between Attachment Storage Systems

You can 'migrate' your attachments from one storage system to another. All existing attachments will be moved over to the new attachment storage system.

When the migration occurs, all other users will be locked out of the Confluence instance. This is to prevent modification of attachments while the migration occurs. Access will be restored as soon as the migration is complete.

To perform a migration, follow the steps below:

  1. Go to the Confluence 'Administration Console'. To do this:

    • Open the 'Browse' menu and select 'Confluence Admin'. The 'Administration Console' view will open.


  2. Click 'Attachment Storage' in the left-hand panel. The current configuration will be displayed.

    Attachment storage configuration

  3. Click the 'Edit' button to modify the configuration.
  4. Select the storage system you desire.

    Edit attachment storage

  5. Click the 'Save' button to save the changes.
  6. A screen will appear, asking you to confirm your changes. Clicking 'Migrate' will take you to a screen that displays the progress of the migration.

    Migration warning

Troubleshooting

To enable debug logging for WebDAV attachment storage, add the following to the bottom of WEB-INF/classes/log4j.properties and restart Confluence:

log4j.logger.com.atlassian.confluence.pages.persistence.dao=DEBUG,confluencelog
log4j.additivity.com.atlassian.confluence.pages.persistence.dao=false

log4j.logger.org.apache.webdav=DEBUG,confluencelog
log4j.additivity.org.apache.webdav=false
RELATED TOPICS
Important Directories and Files

Labels:

confluence confluence Delete
confluence22 confluence22 Delete
webdav webdav Delete
attachment attachment Delete
optional-settings optional-settings Delete
Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.

Comments (10)

 

  1. Mar 21, 2006

    Guy Fraser says:

    Is there any way for hosting companies to stop administrators from storing the f...

    Is there any way for hosting companies to stop administrators from storing the files in the database? We're moving our database on to a seperate server and having attachments stored in there would be a major nightmare.

    1. Mar 21, 2006

      Tom Davies says:

      You can change the .vm file to remove that option. Tom

      You can change the .vm file to remove that option.

      Tom

  2. Feb 28, 2007

    David Nessl says:

    Has this setup been tried with the mod_dav_svn module in Apache 2.2?  This ...

    Has this setup been tried with the mod_dav_svn module in Apache 2.2?  This module provides WebDAV service, where files are stored in a Subversion (version control) repository.  I can configure Confluence (2.3.3) to use this type of WebDAV server for attachment storage, then the migration takes several minutes to run (as expected), but no files show up in the Subversion repository (almost as if the files were transfered but no "commits" never happened). 

    1. Apr 01, 2007

      Matt Ryall says:

      Although I haven't tested it, I don't think the WebDAV attachment storage works ...

      Although I haven't tested it, I don't think the WebDAV attachment storage works as you would expect with Subversion as a back-end. I'm basing this on the fact that there's a third-party plugin to provide exactly this functionality, although it's still in the alpha development phase.

      Try adding the extra logging as described in Troubleshooting above. If you think there's a bug in our WebDAV support, please raise a support case, and attach your logs. We'll investigate further from there.

      1. Apr 01, 2007

        David Peterson [CustomWare] says:

        I believe you are correct about SVN+WebDAV - I tried using it that way myself a ...

        I believe you are correct about SVN+WebDAV - I tried using it that way myself a couple of days ago (in a different context) and it wasn't cooperative.

  3. Dec 19, 2007

    Scott Conroy says:

    Really unhappy to see the WebDAV support for attachments being deprecated. My c...

    Really unhappy to see the WebDAV support for attachments being deprecated. My company is currently using the file storage option but we were planning to migrate to WebDAV in the near future.

  4. Jun 25

    Phil Beck says:

    My confluence installation is on a linux server.  I've created a link for t...

    My confluence installation is on a linux server.  I've created a link for the attachments directory off to an NFS mount point.  It seems to be working just fine.  Has anyone encountered any issues using NFS as an attachments location?

    1. Jun 26

      Tony Cheah Tong Nyee says:

      Hi Phil, We have not test on such configuration in depth and NFS storage is not...

      Hi Phil,

      We have not test on such configuration in depth and NFS storage is not a configuration we support. Although, we do have customers using such configuration successfully, a networked filesystem is something we like to eliminate as a potential cause of problems in support cases.
      However, the following could be the potential risks that you might want to consider:

      • Network failure
      • Two separate threads writing to an attachment could cause file corruption. This would mean two separate users writing the same attachment which is probably unlikely, but the risk still exists.

      Hope it helps.

      Cheers,
      Tony

  5. Aug 31

    semir h says:

    Hi, Any recommendations on whether one should use the database for attachment s...

    Hi,

    Any recommendations on whether one should use the database for attachment storage (in our case MySQL 5) or the File System (Linux ext3)?

    We currently use the DB and it almost seems that Atlassian recommend this but I've heard people say that storing a lot of data in the DB as BLOBs is not a very good idea.

    Any thoughts?

    Our attachment data is about a GIG in size now.

    My understanding is that MySQL does not have a size limit (other than the limit of the disk it is on) so we'd be happy to keep using it unless it is better to use the FS in the long run.

    I'm not an MySQL expert so I'd appreciate some thoughts from people here.

    Many Thanks

    Semir

    1. Sep 01

      Ivo Verlaek says:

      It usually has something to do with the backup facilities of your IT Department....

      It usually has something to do with the backup facilities of your IT Department.

      Not storing the data within your database creates two locations for your backup strategy (Database and File System).
      The backup's of each of these smaller parts are a little bit faster on it's own.

      The attachments could be stored on a NAS Drive which could be easier to implement as extending your DB.

      however,
      Storing everything on the database makes backing it up a little easier for your IT Department, as regular backups should always be performed on all your database content. The procedures are well known and they do not have to be linked to another backup with files from your file system (could be an administrative problem).

      Another reason for storing everything in the database could be a possible future migration to a confluence clustered environment.

      I usually say:
      Do whatever your IT Department thinks is best.
      and
      Use the tools they are most familiar with as there is no big difference.

Add Comment