Page Contents


Feature List

Previous topic

OMERO.server installation

Next topic

OMERO.server and PostgreSQL

This Page


This documentation is for OMERO 5.2. This version is now in maintenance mode and will only be updated in the event of critical bugs or security concerns. OMERO 5.3 is expected in the first quarter of 2017.

OMERO.server binary repository


OMERO 5.2 is the last major version which will feature Windows support for OMERO.server and OMERO.web deployment. See this blog post for details. If you are installing a new server, we highly recommend you use a different OS (see Version requirements).


The OMERO.server binary data repository is a fundamental piece of server-side functionality. It provides optimized and indexed storage of original file, pixel and thumbnail data, attachments and full-text indexes. The repository’s directories contain various files that, together with your SQL database, constitute the information about your users and their data that OMERO.server relies upon for normal operation.


The repository is internally laid out as follows:

C:\OMERO\Pixels             <--- Pixel data and pyramids
C:\OMERO\Files              <--- Original file data
C:\OMERO\Thumbnails         <--- Thumbnail data
C:\OMERO\FullText           <--- Lucene full text search index
C:\OMERO\ManagedRepository  <--- OMERO.fs filesets, with import logs
C:\OMERO\BioFormatsCache    <--- Cached Bio-Formats state for rendering

Your repository is not:

  • the “database”
  • the directory where your OMERO.server binaries are
  • the directory where your OMERO.client (OMERO.insight or OMERO.importer) binaries are
  • your PostgreSQL data directory

Locking and remote shares

The OMERO server requires proper locking semantics on all files in the binary repository. In practice, this means that remotely mounted shares such as AFS, CIFS, and NFS can cause issues. If you have experience and/or the time to manage and monitor the locking implementations of your remote filesystem, then using them as for your binary repository should be fine.

If, however, you are seeing errors such as NullPointerExceptions, “Bad file descriptors” and similar in your server log, then you will need to use directly connected disks.


If your binary repository is a remote share and mounting the share fails or is dismounted, OMERO will continue operating using the mount point instead! To prevent this, make the mount point read-only for the OMERO user so that no data can be written to the mount point.

Repository location


It is strongly recommended that you make all changes to your OMERO binary repository with the server shut down. Changing the configuration does not move the repository for you, you must do this yourself. Remember that C:\ style paths must have backslashes escaped. We strongly discourage the use of network mapped drives as locations for either the binary repository or the OMERO.server installation.

Your repository location can be changed from its C:\OMERO default by modifying your OMERO.server configuration as follows:

C:\> cd C:\OMERO.server
C:\OMERO.server\> bin\omero config set D:\\OMERO

The suggested procedure is to shut down your OMERO.server instance, move your repository, change your and then start the instance back up. For example:

C:\> cd C:\OMERO.server
C:\OMERO.server\> bin\omero admin stop
C:\OMERO.server\> move C:\OMERO D:\
C:\OMERO.server\> bin\omero config set D:\\OMERO
C:\OMERO.server\> bin\omero admin start

The omero.managed.dir property for the OMERO.fs managed repository may be adjusted similarly, even to a directory outside


The managed repository should be located and configured to allow the OMERO server processes fast access to the uploaded filesets that it contains.

Access permissions

Your repository should be owned or accessible by the same user that is starting your OMERO.server instance which may be different from the user you use to start OMERO. See OMERO.server Windows Service for more information.

To modify the access permissions to the binary repository, the OMERO folder properties can be accessed and the permissions settings changed (see Repository Folder Permissions). Another option (useful for batch permission changes) is the icacls (Windows 7) / cacls (Windows XP) command line utility. Please note that the new permissions will appear as Special Permissions in the Security tab when viewing folder properties. An example invocation allowing the user omeservice to read (R) and write (W) from and to the OMERO directory:

C:\>icacls OMERO /grant omeservice:RW
processed file: OMERO
Successfully processed 1 files; Failed processing 0 files

Repository Folder Permissions

Repository size

At minimum, the binary repository should be comfortably larger than the images and other files that users may be uploading to it. It is fine to set or omero.managed.dir to very large volumes, or to use logical volume management to conveniently increase space as necessary.