Last modified by Vincent Massol on 2017/10/02

Attachments can be uploaded either through the regular upload action, WebDAV, XML-RPC or Rest.
As an administrator you can set limits on the maximum size of an attachment and where the attachments will be stored.

Size Limit

The maximum size of an attachment is limited by a configuration parameter in the XWikiPreferences document. It is set to about 32MB by default.
To change it follow these steps:

  1. Go to http://<yourwiki>/xwiki/bin/edit/XWiki/XWikiPreferences?editor=object
  2. Click on the line that says XWikiPreferences 0 (right below the line that says Objects of type XWiki.XWikiPreferences (1))
  3. Scroll down to the field that says Maximum Upload Size and change the number to whatever size you want (it is expressed in bytes)
  4. Scroll to the bottom and click "Save"
Note that if you've already tried to attach a file and it failed, in order for the new size setting to be taken into account you might need to clear your browser's cache.


When a user uploads an attachment and then uploads another attachment with the exact same name, you can decide whether or not to keep a version history of the attachments like you do with documents.
XWiki stores all document attachment versions by default which costs more storage space. If you need only latest versions of attachments, you can disable attachment version control by editing your xwiki.cfg and adding:


Deleted attachments are stored in a recycle bin so that they can be restored along with the document when rolling back or previewing an earlier version where the attachment should be visible. To disable this feature, edit xwiki.cfg and add:


You can view the list of deleted attachments in your wiki and delete them permanently by going to XWiki.DeletedAttachments in your wiki.

Attachment Storage

XWiki offers plugin attachment storage mechanisms so you can store your attachments in the database or directly in the filesystem.

No matter what type of attachment store you use, the meta-data for the attachment will be saved in the xwikiattachment table for faster loads.

Database Attachment Store (Default)

This attachment storage mechanism stores your attachments in database entries in the xwikiattachment_content, xwikiattachment_archive and xwikiattrecyclebin tables. This system allows for easy backup of your attachments by dumping the database and keeping all of your data together, but attachment size is memory constrained since the attachment content and archive must all be held in memory. As a general rule, attachments larger than 30MB are not possible.

When using this attachment store with a MySQL database, you must set the max_allowed_packet to about 3 times the size of your largest attachment since the attachment and its version history must be saved. See the MySQL Installation guide for more information.

Filesystem Attachment Store

The Filesystem attachment store saves your attachments in files in a directory tree. This means you will have one more thing to do when you back up your data but it also means you can save larger (over one gigabyte) files. Filesystem attachment store implements a two stage commit mechanism to maintain integrity even if the database fails to commit the attachment meta-data.

The following limitations currently exist when using the filesystem for storing attachments:

  • There is a bug in XWiki, that prevents restoring attachments from the recycle bin via UI: you will find empty LiveTable. Attachment delete action brings new version to the document, so, the correct way to restore the attachment is to rollback to the necessary version. If you delete the document with the attachment and then click delete again to permanently expunge the document from history, the attachment will be removed from your system together. One of the options to avoid mess with attachments in the filesystem until this bug would be fixed, just turn off recycle bin for attachments at all. 
  • You must be on a case-sensitive Filesystem. For example if you're on Windows then you might have issue if you create pages with the same name but different case (e.g. abc vs Abc). XWiki is case-sensitive and will end up overwriting attachments if you have several pages with the same name (but different case).

Enabling Filesystem attachment store

New users

If you are a new XWiki user, all you need to do for enabling Filesystem Attachment Store is to change some settings in the xwiki.cfg file.

These settings should read as follows: = file = file = file

# Attachments being also stored in the deleted documents it's safer to also enable filesystem storage for it too = file

Also make sure they are not commented out.

If you're using the standalone packaging (the ZIP or EXE packagings) then you already have wiki pages and attachments in the database (since database is the default at the moment). Thus you'll need to apply the instructions for the next section and run the Filesystem Attachment Porter.

Also note that if have already started XWiki and executed the Distribution Wizard that will have populated your wiki with wiki pages and attachments stored in the database too. So similarly you'll need to apply what's in the next section.

Users who already have a running wiki

If you already have a wiki and want to take advantage of the Filesystem Attachment Store, you should use the Filesystem Attachment Porter to move your existing attachments onto the filesystem.

Filesystem attachment store location

The directory in which the attachments are stored in the filesystem is defined with the parameter environment.permanentDirectory in the file. By default it's defined to be data, which is a directory relative to where the Java Servlet Container was started. It's recommend to modify this value to be absolute sure that you can start the Servlet Container from any directory and still have XWiki find the attachments located in this work directory.

For example:


Directory Structure


The Filesystem Attachment Store puts your attachments into a directory tree on the hard disk, the directory structure is designed to be intuitive to navigate but you should never add or remove anything. Each attachment is accompanied by a piece of meta-data in the database and modifying the content in the filesystem store manually will lead to meta-data with no content or content with no meta-data.

Other considerations

If you are running a cluster you will need  to have a synchronized storage directory for each node. You can use NFS or other means to mount the disk on each node in the cluster.

Directory cleanup

Since XWiki 6.0M2, it is possible to save time on startup by preventing XWiki from cleaning up empty directories in the Filesystem Attachment Store. To do this, edit and set store.fsattach.cleanOnStartup to false. If you do this, you will be responsible for cleanup of empty directories yourself.

Created by Vincent Massol on 2017/09/06

Get Connected