Manual installation

Debian packages

Install the following Debian packages:

  • dcraw
  • ffmpeg
  • imagemagick
  • jhead

New installation

The following command line transcript is for a new installation. See the next section for details about how to upgrade.

mkdir /var/archive/gallery
cd /var/archive/gallery
cd /var/www
tar xfvz /var/archive/gallery/gallery-2.3.1-full.tar.gz
mv gallery2 gallery2-2.3.1
ln -s gallery2-2.3.1 gallery2
cd /etc/gallery2
mkdir /etc/gallery2
cd gallery2
touch config.php
chown www-data:root config.php
chmod 640 config.php
ln -s /etc/gallery2/config.php /var/www/gallery2
touch htaccess
ln -s /etc/gallery2/htaccess /var/www/gallery2/.htaccess

See the configuration section further down for the remaining details.

Upgrade installation


Debian installation

Historical note

I have stopped using the Debian package when I upgraded to Debian 6 (squeeze) because the package was frozen in Debian Unstable (sid), with a large number of bugs filed against it. Apparently the package had not received any attention from the maintainer since early 2010, and I didn't see any upcoming changes to that status, so I decided to roll my own manual installation.

The following sections therefore contain historical information only. I keep the information around just in case a usable Debian package will appear sometime in the future.

Debian packages

The following Debian package needs to be installed



File system

Create the directory


This directory will be used to store the gallery's picture data. Change the directory permissions like this:

chown www-data:www-data /var/www/g2data

Note: I like to keep the picture data folder separated from any other Gallery files (e.g. the PHP program files) because this allows me to mount a dedicated filesystem in that filesystem location, or to make the folder a symlink that points to somewhere else.

Web server setup

If Gallery is installed via Debian package, dpkg automatically generates a symlink


that points to


If Gallery is installed manually, the file and symlink must also be created manually. The content of the file looks like this:

<Directory /var/www/gallery2>
  Options FollowSymLinks
  AllowOverride Limit Options FileInfo

In addition, I have assigned an Apache vhost to Gallery that is accessible under These are the configuration details. Note that if the Debian installation is used, the document root must be changed to /usr/share/gallery2.

# --------------------------------------------------------------------------------
# --------------------------------------------------------------------------------
<VirtualHost *:80>
  ErrorLog /var/log/apache2/
  CustomLog /var/log/apache2/ combined

  DocumentRoot /var/www/gallery2
  Alias /robots.txt /var/www/

  <Directory /var/www/gallery2/>
    Require all granted
    <IfModule mod_php5.c>
      php_admin_flag engine on
      php_value memory_limit 32M
      # The next two options are required to use the "Gallery Remote" program.
      php_value post_max_size 20971520
      php_value upload_max_filesize 20971520

  <Directory /var/www/>
    Require all granted

# --------------------------------------------------------------------------------
# SSL Host
# --------------------------------------------------------------------------------
<IfModule mod_ssl.c>
  <VirtualHost *:443>
    ErrorLog /var/log/apache2/
    CustomLog /var/log/apache2/ combined

    DocumentRoot /var/www/gallery2
    Alias /robots.txt /var/www/

    <Directory /var/www/gallery2/>
      Require all granted
      <IfModule mod_php5.c>
        php_admin_flag engine on
        php_value memory_limit 32M
        # The next two options are required to use the "Gallery Remote" program.
        php_value post_max_size 20971520
        php_value upload_max_filesize 20971520

    <Directory /var/www/>
      Require all granted

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/
    SSLCertificateKeyFile /etc/ssl/private/
    SSLCertificateChainFile /etc/ssl/certs/
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

MySQL setup

Manually (e.g. through phpmyadmin) generate a database (e.g. gallery2) and a user (e.g. gallery2) that has all rights to the database. The database is going to be populated with tables during the Web browser setup step.

Web browser setup

Point your web browser to (or, in case this is not a new installation). The setup is straightforward; if changes to the web server configuration are necessary, you simply make these changes and say apache2ctl graceful, then reload the setup page in the browser to see the updated settings.


  • The "URL Rewrite" module cannot be automatically configured during this setup phase (as other modules are). It therefore needs to be manually configured later on (see below).
  • I choose to ignore the warning about Output buffering being enabled in my PHP configuration. The predicted problems either do not apply to me (unable to serve large video files: I don't have any video files), or they do not sound grave enough to warrant a global PHP configuration change (progress bar possibly not working)


To enable other languages than just plain English, the system must have a matching locale installed. For instance, to support German the following locale must be present on the system:


Note: Possibly other "de_DE" locales would work also (e.g. "de_DE.ISO-8859-1"), but what definitely does not work is any of the "de_CH" locales.

To find out which locales are installed at the moment:

locale -a

To change the system locales:

dpkg-reconfigure locales



To configure a module

  • login as administrator
  • goto Site Admin->Modules
  • click the link "configure" next to the module's entry in the module list

URL Rewrite

  • click the module's "Configure" link
  • you are being told that the mod_rewrite rules need to be written to /usr/share/gallery2/.htaccess
  • on the file system, create the file
touch /usr/share/gallery2/.htaccess
  • temporarily change permissions
chmod 666 /usr/share/gallery2/.htaccess
  • in the browser, click the "Done" link
  • in the browser, click the "Activate" link -> the module rules are now written to file
  • change back permissions
chmod 644 /usr/share/gallery2/.htaccess


This module is useful if gallery pictures contain EXIF/IPTC information and that information should be extracted when pictures are uploaded.

The following information is extracted:

  • EXIF
    • Gallery Item Summary = Iptc.Application2.Caption
    • Gallery Item Description = Iptc.Application2.Caption
  • IPTC
    • Gallery Item Keywords = Iptc.Application2.Keywords

Note: The gallery field "Title" unfortunately cannot be set from EXIF/IPTC.


Note: WebDAV on Mac OS X will be fixed in Gallery 2.2

  • install the "WebDAV" module (no configuration necessary)
  • install the "HTTP Auth" module (no configuration necessary)
  • if the "URL Rewrite" module is active, go to its configuration screen and activate the WebDAV rules (first make .htaccess file writeable)
  • go to "Remote Interfaces" -> WebDAV; you will be presented with the URL to connect to Gallery with WebDAV

Resources for the future:

Gallery Remote

To use this program, the web server configuration must be update with the following settings:

  • post_max-size
  • upload_max_filesize

Gallery Remote requires the imagemagick tool suite (esp. the convert utility) for handling of image files. On the Mac, the simplest way to install imagemagick is to say

fink install imagemagick

Unfortunately, this installs convert in /sw/bin, but Gallery Remote by default expects the utility to reside in /usr/local/bin. An option to specify where the convert utility is located is to edit the file

within the Gallery Remote application bundle. Change the property im.convertPath to something like this (the example is for my fink installation):


In older versions of Gallery Remote 1.5 the file hides itself inside this .jar:


Since I do not know (and at the moment don't care to find out) how to edit a file within a .jar, I simply create a symlink to the convert utility that Gallery Remote is able to find.

cd /usr/local/bin
ln -s /sw/bin/convert convert

Share pictures between albums ("symlink")

Gallery allows to share pictures between albums (I always compare this to making a symbolic link on the file system level). This can be very useful to create best-of or theme albums (e.g. "Pictures of Switzerland").

  • select a picture
  • in the sidebar on the left an option "create link" appears
  • when you click this, a list with all pictures of the current album appears; the previously selected picture is already checked, but you can modify the selection as you see fit
  • now select a destiniation album and click "link"

Running the same gallery under two different vhosts

Why it doesn't work

I would like the same gallery to appear under two different Apache vhosts: and Yes, the same gallery. Unfortunately it appears that this can't be done, at least not with Gallery 2. Maybe it will be different with Gallery 3, but this has to be researched again properly.

I tried to make this work by simply setting up the two vhosts to use the same Gallery code base and configuration files. It didn't work, possibly because of the URL Rewrite plugin, which is essential to me. Whenever I pointed my browser at the secondary site,, Gallery would stubbornly redirect to the original site, Of course, it would also "lose" the information that I had logged in on the secondary site (probably because the cookie was set for the domain of the secondary site).

In a second attempt I investigated whether Gallery's multisite feature would solve my problem. The information on indicates that it does not! In fact, according to the docs, once you switch to multisite, the different sites must use different image storage areas (g2data directories) and different databases. If two sites in a multisite setup are configured to use the same storage area and database, they will destroy each other's installation and neither of the two will work afterwards.

I discovered this information when I had already proceeded far into converting my standalone installation into a multisite instalation. I gave up immediately because I had no wish to risk my installation. Maybe a multisite that shares not only the same codebase, but also the same data, could be made to work, but I have neither the time nor the inclination for this hack. For historical reasons, I leave the notes of my abortive multisite experiment in the next chapter. Maybe they come in handy one day...

Converting from standalone to multisite installation

The base for the following instructions is this wiki page:


  • Log in as administrator and uninstall the URL Rewrite plugin
  • rm /usr/share/gallery2/.htaccess
  • Create directories where the configuration files for the future sites are going to live: mkdir -p /etc/gallery2/sites/ /etc/gallery2/sites/
  • Copy an appropriate robots.txt to each one of the sites
  • Temporarily make the directories writeable to the web server process: chmod o+w /etc/gallery2/sites/*
  • Point web browser at install script of the existing and working standalone installation:
  • In step 2, the authentication process will probably fail because the Gallery codebase directory still contains the authentication token from the original installation process. Gallery will give you a new token (looks something like an MD5 hash) which you can use to overwrite the authentication token file. This will looke something like this: echo 6555549f90e10b98af53411102b6b980 >/usr/share/gallery2/login.txt
  • Reload the page in the browser (or click the link "Authenticate me"). You should now be able to proceed with the installation
  • Installation type" step
    • Choose "Multisite installation" and enter the information to make the original standalone installation ( work in the new multisite setup
    • The next step allows you to redo the the "installation type" step. Do this and enter the information for the new gallery site (
  • "Storage setup" step
    • Enter the path to the directory that will hold the images for your original gallery site ( The default is /var/lib/gallery2/g2data which is correct for my setup
    • Again you can redo this step for the new gallery site ( I entered the same path here as for my original gallery site because I want the two sites to share the same data.
  • "Database setup" step
    • The pattern continues: Enter the information that refers to the database of your original gallery site ( After you click the "save" button, Gallery detects that the database is already populated and offers to reuse the existing tables. Select this to continue
    • Redo the step for the new gallery site (
  • "Admin user setup" step
    • As this is not a clean new installation, the admin user is not created here, but Gallery's "setup password" for the original gallery site ( can be redefined. I entered the previous setup password as this is still good enough
    • Redo the step for the new gallery site (

At this point I aborted my conversion experiment because, as I have stated in the previous section, I discovered the explicit warnings on the Gallery wiki page that sharing the same data (image storage area and database) among two different sites causes the two sites to destroy each other. Luckily at this point no damage had been done yet to the database or the g2data directory, and I was able to revert back to my standalone installation setup.


The site does not work properly after moving to Apache vhost

After moving Gallery from to its own virtual host, nothing seems to work properly. Symptoms are:

The solution is this:

  1. Deactivate and uninstall the URL Rewrite plugin. Notes:
  • Removing /usr/share/gallery2/.htaccess and reconfiguring the plugin does not work, there must be some settings stored somewhere else (possibly the database)
  • The uninstall step is possibly not necessary, I didn't try out, though, whether deactivation alone is sufficient
  1. Make /usr/share/gallery2/.htaccess writable
  2. Reinstall and reactivate the plugin
  3. Write-protect /usr/share/gallery2/.htaccess