Hide last authors
Adrian Fita 8.1 1 {{box cssClass="floatinginfobox" title="**Contents**"}}
2 {{toc/}}
3 {{/box}}
Caleb James DeLisle 5.1 4
Vincent Massol 13.4 5 Attachments can be uploaded either through the regular [[upload action>>platform:Features.Attachments]], [[platform:Features.WebDAV]], [[XML-RPC>>extensions:Extension.XML-RPC Integration]] or [[Rest>>platform:Features.XWikiRESTfulAPI]].
Caleb James DeLisle 1.1 6 As an administrator you can set limits on the maximum size of an attachment and where the attachments will be stored.
7
8 = Size Limit =
Adrian Fita 8.1 9
Vincent Massol 34.1 10 The maximum size of an attachment is limited by a configuration parameter in the //XWikiPreferences// document. It is set to 100GB by default (32MB for XWiki < 10.9RC1).
Manuel Smeria 10.2 11 To change it follow these steps:
Adrian Fita 8.1 12
Manuel Smeria 10.2 13 1. Go to //{{{http://<yourwiki>/xwiki/bin/edit/XWiki/XWikiPreferences?editor=object}}}//
14 1. Click on the line that says ##XWikiPreferences 0## (right below the line that says ##Objects of type XWiki.XWikiPreferences (1)##)
15 1. Scroll down to the field that says ##Maximum Upload Size## and change the number to whatever size you want (it is expressed in bytes)
16 1. Scroll to the bottom and click "Save"
Caleb James DeLisle 1.1 17
Anca Luca 22.1 18 {{warning}}
Manuel Smeria 24.1 19 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.
Anca Luca 23.1 20 {{/warning}}
Anca Luca 22.1 21
Caleb James DeLisle 3.1 22 = Versions =
Adrian Fita 8.1 23
Simon Urli 43.3 24 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.
Ecaterina Moraru (Valica) 27.3 25 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>>Documentation.AdminGuide.Configuration#HSamplexwiki.cfg]] and adding:
Caleb James DeLisle 3.1 26
Adrian Fita 8.1 27 {{code language="none"}}
28 xwiki.store.attachment.versioning=0
29 {{/code}}
Caleb James DeLisle 3.1 30
31 = Deletion =
Adrian Fita 8.1 32
Ecaterina Moraru (Valica) 27.3 33 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>>Documentation.AdminGuide.Configuration#HSamplexwiki.cfg]] and add:
Caleb James DeLisle 3.1 34
Adrian Fita 8.1 35 {{code language="none"}}
36 storage.attachment.recyclebin=0
37 {{/code}}
Caleb James DeLisle 3.1 38
Caleb James DeLisle 4.1 39 You can view the list of deleted attachments in your wiki and delete them permanently by going to ##XWiki.DeletedAttachments## in your wiki.
Caleb James DeLisle 3.1 40
Caleb James DeLisle 1.1 41 = Attachment Storage =
Adrian Fita 8.1 42
Caleb James DeLisle 1.1 43 XWiki offers plugin attachment storage mechanisms so you can store your attachments in the database or directly in the filesystem.
44
Thomas Mortagne 40.1 45 Generally metadata for attachment and deleted attachments stay in the database whatever store is used for the content. The metadata contains the type of store used for the content allowing each attachment to choose a different store. The consequence is that what you configure is the **default** store for a new attachment and not the store used for all attachments.
Caleb James DeLisle 1.1 46
Thomas Mortagne 32.1 47 == Filesystem Attachment Store ==
Adrian Fita 8.1 48
Manuel Smeria 10.2 49 {{info}}
Thomas Mortagne 33.1 50 The default since 10.5
Manuel Smeria 10.2 51 {{/info}}
52
53 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.
Giovanni Júnior 10.1 54
Adrian Fita 8.1 55 === Filesystem attachment store location ===
56
Thomas Mortagne 41.1 57 By default the filsystem storage is located in a sub-folder (##store/file## since XWiki 11.0 and ##storage## before) of the permanent directory (defined with the parameter ##environment.permanentDirectory## in the ##xwiki.properties## 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.
Adrian Fita 8.1 58
Vincent Massol 9.2 59 For example:
Adrian Fita 8.1 60
61 {{code}}
Sergiu Dumitriu 9.6 62 environment.permanentDirectory=/opt/tomcat6/data
Adrian Fita 8.1 63 {{/code}}
64
Thomas Mortagne 41.1 65 Since 11.4 it's possible to set the location of the filesystem store without modifying the general permanent directory using property ##store.file.directory## of the file ##xwiki.properties##.
66
67 {{code}}
68 store.file.directory=/my/custom/location
69 {{/code}}
70
Caleb James DeLisle 1.1 71 === Other considerations ===
Adrian Fita 8.1 72
Vincent Massol 28.1 73 If you are running a [[cluster>>Documentation.AdminGuide.Clustering.WebHome]] 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.
Caleb James DeLisle 13.2 74
75 ==== Directory cleanup ====
76
Ecaterina Moraru (Valica) 27.1 77 Since [[XWiki 6.0M2>>xwiki:ReleaseNotes.ReleaseNotesXWiki61M2]], 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 ##xwiki.properties## and set **store.fsattach.cleanOnStartup** to false. If you do this, you will be responsible for cleanup of empty directories yourself.
Thomas Mortagne 32.1 78
79 == Database Attachment Store ==
80
81 {{info}}
Thomas Mortagne 39.1 82 The default before 10.5.
Thomas Mortagne 32.1 83 {{/info}}
84
85 This attachment storage mechanism stores your attachments in database entries in the [[xwikiattachment_content>>platform:DevGuide.DsXWikiAttachmentContent]], [[xwikiattachment_archive>>platform:DevGuide.XWikiAttachmentArchive]] and [[xwikiattrecyclebin>>platform:DevGuide.DsXwikiRecycleBin]] 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.
86
Thomas Mortagne 39.1 87 === Switch to database attachment store ===
88
89 These settings should read as follows:
90
91 {{code language="none"}}
92 xwiki.store.attachment.hint = hibernate
93 xwiki.store.attachment.versioning.hint = hibernate
94 xwiki.store.attachment.recyclebin.content.hint=hibernate
95
96 # If you need to use database store for the attachment it's probably true for deleted attachments
97 xwiki.store.recyclebin.content.hint = hibernate
98 {{/code}}
99
100 Also make sure they are not commented out.
101
Thomas Mortagne 32.1 102 {{info}}
103 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>>Documentation.AdminGuide.InstallationMySQL]] for more information.
104 {{/info}}
Simon Urli 43.1 105
106 = Attachment display or download =
107
Simon Urli 43.3 108 When possible (see [[Security section>>#HSecurity]] below) attachments are displayed directly in the browser when accessed.
Simon Urli 43.1 109 It is possible for developers to force-downloading an attachment by adding the parameter ##?force-download=1## in the attachment URL.
110
Simon Urli 43.3 111 {{version since="12.10"}}
112 it's possible to use a dedicated property in ##xwiki.properties## to always force some attachment mime-types to be downloaded:
Simon Urli 43.1 113
114 {{code language="none"}}
Vincent Massol 43.2 115 #-# [Since 12.10]
Simon Urli 43.1 116 #-# Define the kind of attachment that you always want to be downloaded and never displayed inline.
117 #-# By default this list is empty, but you can specify a list of mime-types (coma separated list of values) which
118 #-# should be always downloaded no matter who attached them or what is the whitelist/blacklist configuration.
119 #-#
120 #-# The distinction with the blacklist configuration above is that the blacklist won't affect file attached by a user
121 #-# with programming rights, while this configuration affect any attachment.
122 # attachment.download.forceDownload=
123 {{/code}}
124 {{/version}}
125
126 = Security =
127
128 In order to prevent attacks by using attachments, it's possible to control which attachments' can be directly opened on the browser based on their mimetypes.
129 Two properties in ##xwiki.properties## allow to control that independently:
130
131 {{code language="none"}}
132 #-# [Since 5.2M2]
133 #-# Define the kind of attachment that can be displayed inline. You can either choose to do it through a whitelist
134 #-# (only the mimetypes defined in this list would be displayed inline) or a blacklist (every mimetype that is not in
135 #-# this list would be displayed inline if possible).
136 #-# Note that only one configuration is used between the whitelist and the blacklist, and the whitelist always have
137 #-# the priority over the blacklist. Also note that these configurations exist for security reason so they are only
138 #-# impacting attachments added by users who do not have programming rights.
139 #-# If you want to force downloading some attachments types please check the configuration below.
140 #-#
141 #-# By default we use the following whitelist (coma separated list of values).
Simon Urli 43.3 142 # attachment.download.whitelist=audio/basic,audio/L24,audio/mp4,audio/mpeg,audio/ogg,audio/vorbis,audio/vnd.rn-realaudio,audio/vnd.wave,audio/webm,image/gif,image/jpeg,image/pjpeg,image/png,image/tiff,text/csv,text/plain,text/xml,text/rtf,video/mpeg,video/ogg,video/quicktime,video/webm,video/x-matroska,video/x-ms-wmv,video/x-flv
Simon Urli 43.1 143 #-#
144 #-# If you prefer to use a blacklist instead, you can define the forbidden types here, as a coma separated list of
145 #-# values. We advise you to forbid at least the following mimetypes : text/html, text/javascript
146 # attachment.download.blacklist=text/html,text/javascript
147 {{/code}}

Get Connected