The Installation Wizard
Introduction
If you are planning to use the installation wizard, we strongly encourage you to protect it, through some form of password authentication, or access control. If the installer is left unprotected when exposed to the public internet, there is the possibility that a malicious actor could finish the installation and block you out — or worse. So please ensure that only you — or someone from your organization — can access the web installer. |
Quick Start
When the ownCloud prerequisites are fulfilled and all ownCloud files are installed, the last step to completing the installation is running the Installation Wizard. This involves just three steps:
-
Point your web browser to
http://localhost/owncloud
-
Enter your desired administrator’s username and password
-
Click Finish Setup
You’re now finished and can start using your new ownCloud server. Of course, there is much more that you can do to set up your ownCloud server for best performance and security. In the following sections we will cover important installation and post-installation steps. Note that you must follow the instructions in Setting Strong Permissions in order to use the occ command.
In-Depth Guide
This section provides a more detailed guide to the installation wizard. Specifically, it is broken down into three steps:
Data Directory Location
Click "Storage and Database" to expose additional installation configuration options for your ownCloud data directory and database.
You should locate your ownCloud data directory outside of your Web root if you are using an HTTP server other than Apache, or you may wish to store your ownCloud data in a different location for other reasons (e.g., on a storage server).
ownCloud’s data directory must be exclusive to ownCloud and not be modified manually by any other process or user. |
It is best to configure your data directory location at installation, as
it is difficult to move after installation. You may put it anywhere; in this example is it located in /var/oc_data
.
This directory must already exist, and must be owned by your HTTP user.
Database Choices
When installing ownCloud Server & ownCloud Enterprise editions the administrator may choose one of 4 supported database products. These are:
-
SQLite
-
MYSQL/MariaDB
-
PostgreSQL
-
Oracle 11g (Enterprise-edition only)
SQLite
SQLite is the default database for ownCloud Server — but is not supported by the ownCloud Enterprise edition. |
SQLite is only good for testing and lightweight single user setups. It has no client synchronization support, so other devices will not be able to synchronize with the data stored in an ownCloud SQLite database.
SQLite will be installed by the ownCloud package and all the necessary dependencies will be satisfied. If you used the package manager to install ownCloud, you may "Finish Setup" with no additional steps to configure ownCloud using the SQLite database for limited use.
MYSQL/MariaDB
MariaDB is the ownCloud recommended database. It may be used with either ownCloud Server or ownCloud Enterprise editions. To install the recommended MySQL/MariaDB database, use the following command:
sudo apt-get install mariadb-server
If you have an administrator login that has permissions to create and modify databases, you may choose "Storage & Database". Then, enter your database administrator username and password, and the name you want for your ownCloud database. Alternatively, you can use these steps to create a temporary database administrator account.
sudo mysql --user=root mysql CREATE USER 'dbadmin'@'localhost' IDENTIFIED BY 'Apassword'; GRANT ALL PRIVILEGES ON *.* TO 'dbadmin'@'localhost' WITH GRANT OPTION; FLUSH PRIVILEGES; exit
For more detailed information, see MySQL/MariaDB <system_requirements>.
PostgreSQL
PostgreSQL is also supported by ownCloud. To install it, use the following command (or that of your preferred package manager):
sudo apt-get install postgresql
In order to allow ownCloud access to the database, create a known
password for the default user, postgres
, which was added when the
database was installed.
sudo -i -u postgres psql postgres=# \password Enter new password: Enter it again: postgres=# \q exit
Database Setup By ownCloud
Your database and PHP connectors must be installed before you run the Installation Wizard by clicking the Finish setup button. After you enter your temporary or root administrator login for your database, the installer creates a special database user with privileges limited to the ownCloud database.
Following this, ownCloud needs only this special ownCloud database user
and drops the temporary or root database login. This new user is named
from your ownCloud admin user, with an oc_
prefix, and given a random
password. The ownCloud database user and password are written into
config.php
:
For MySQL/MariaDB:
'dbuser' => 'oc_dbadmin', 'dbpassword' => 'pX65Ty5DrHQkYPE5HRsDvyFHlZZHcm',
For PostgreSQL:
'dbuser' => 'oc_postgres', 'dbpassword' => 'pX65Ty5DrHQkYPE5HRsDvyFHlZZHcm',
Click Finish Setup, and you’re ready to start using your new ownCloud server.
Post-Installation Steps
Now we will look at some important post-installation steps. For hardened security we recommend setting the permissions on your ownCloud directories as strictly as possible, and for proper server operations. This should be done immediately after the initial installation and before running the setup.
Your HTTP user must own the config/
, data/
, apps/
respectively the
apps-external/
directories so that you can configure ownCloud, create,
modify and delete your data files, and install apps via the ownCloud Web
interface.
You can find your HTTP user in your HTTP server configuration files, or you can use label-phpinfo (Look for the User/Group line).
-
The HTTP user and group in Debian/Ubuntu is
www-data
. -
The HTTP user and group in Fedora/CentOS is
apache
. -
The HTTP user and group in Arch Linux is
http
. -
The HTTP user in openSUSE is
wwwrun
, and the HTTP group iswww
.
When using an NFS mount for the data directory, do not change its ownership from the default. The simple act of mounting the drive will set proper permissions for ownCloud to write to the directory. Changing ownership as above could result in some issues if the NFS mount is lost. |
The easy way to set the correct permissions is to copy and run the
script, below. The script sets proper permissions and ownership
including the handling of necessary directories. The script also
prepares for an apps-external
directory, for details see config.sample.php
:
-
Replace the
ocpath
variable with the path to your ownCloud directory. -
Replace the
ocdata
variable with the path to your ownCloud data directory. -
Replace the
apps_external
variable with the path to your ownCloud apps-external directory.
In case use want to use links for the data and apps-external directory:
-
Replace the
linkdata
variable with the path to your ownCloud linked data directory. -
Replace the
linkapps-external
variable with the path to your ownCloud linked apps-external directory.
Set the correct HTTP user and group according your needs:
-
Replace the
htuser
andhtgroup
variables with your HTTP user and group.
In case of upgrading using tar:
-
Replace the
oldocpath
variable with the path to your old ownCloud directory.
If you have customized your ownCloud installation and your file paths are different than the standard installation, modify this script accordingly.
This summary lists the recommended modes and ownership for your ownCloud directories and files:
-
All files should be read-write for the file owner, read-only for the group owner, and zero for the world
-
All directories should be executable (because directories always need the executable bit set), read-write for the directory owner, and read-only for the group owner
-
The apps/ directory should be owned by
[HTTP user]:[HTTP group]
-
The apps-external/ directory should be owned by
[HTTP user]:[HTTP group]
-
The config/ directory should be owned by
[HTTP user]:[HTTP group]
-
The data/ directory should be owned by
[HTTP user]:[HTTP group]
-
The updater/ directory should be owned by
[HTTP user]:[HTTP group]
-
The [ocpath]/.htaccess file should be owned by
root:[HTTP group]
-
The data/.htaccess file should be owned by
root:[HTTP group]
-
Both .htaccess files are read-write file owner, read-only group and world
These strong permissions prevent upgrading your ownCloud server; see Setting Permissions for Updating for a script to quickly change permissions to allow upgrading.
#!/bin/bash
# To setup this script for your environment, adopt the following variables to your needs:
#
# ocname the name of your directory containing the owncloud files
# ocroot the path to ocname, usually /var/www (no trailing slash)
# linkroot the path to your source directory for linking data and apps-external (no trailing slash)
# htuser the webserver user
# htgroup the webserver group
# rootuser the root user
# Short description for paramters used in find
#
# -L ... Follow symbolic links. Needed in case if links are used or present
# -path ... The path to process
# -prune ... If the file is a directory, do not descend into it (used to exclude directories)
# -o ... OR (to add more parameters)
# -type ... File is of type [d ... directory, f ... file]
# -print0 ... Print the full file name on the standard output, followed by a null character
# xargs -0 ... Reads items from the standard input, input items are terminated by a null character
ocname='owncloud'
ocroot='/var/www'
ocpath=$ocroot/$ocname
ocdata=$ocroot/$ocname/'data'
ocapps_external=$ocpath/'apps-external'
oldocpath=$ocroot/$ocname'_'$(date +%F-%H.%M.%S)
linkroot='/var/mylinks'
linkdata=$linkroot/'data'
linkapps_external=$linkroot/'apps-external'
htuser='www-data'
htgroup='www-data'
rootuser='root'
# Because the data directory can be huge or on external storage, an automatic chmod/chown can take a while.
# Therefore this directory can be treated differently.
# If you have already created an external "data" and "apps-external" directory which you want to link,
# set the paths above accordingly. This script can link and set the proper rights and permissions
# depending what you enter when running the script.
# When the instance is setup, either post a fresh install or, after an upgrade, run this script again - but
# only for securing ".htaccess files". This sets the appropriate ownership and permissions for them.
# In case you upgrade an existing installation, your original directory will be renamed, including a timestamp.
# Example input (without securing your .htaccess files)
# New install using mkdir: n/n/n/n (create possible missing directories, setup permissions and ownership)
# Upgrade using mkdir: y/n/n/n (you move/replace data, apps-external and config.php manually, set setup permissions and ownership)
# New install using links: n/y/y/n (link existing directories, setup permissions and ownership)
# Upgrade using links: y/y/n/y (link existing directories, copy config.php, permissions and ownership are already ok)
# Post installation/upgrade: either n/n/n/n or n/y/y/n
# Reset all perm & own: either n/n/n/n or n/y/y/n
echo
read -p "Do you want to secure your .htaccess files post installing/upgrade (y/N)? " -r -e answer
(echo "$answer" | grep -iq "^y") && do_secure="y" || do_secure="n"
if [ "$do_secure" = "y" ]; then
printf "\nSecuring .htaccess files with chmod/chown\n"
if [ -f ${ocpath}/.htaccess ]; then
chmod 0644 ${ocpath}/.htaccess
chown ${rootuser}:${htgroup} ${ocpath}/.htaccess
fi
if [ -f ${ocdata}/.htaccess ];then
chmod 0644 ${ocdata}/.htaccess
chown ${rootuser}:${htgroup} ${ocdata}/.htaccess
fi
echo
exit
fi
read -p "Do you want to upgrade an existing installation (y/N)? " -r -e answer
(echo "$answer" | grep -iq "^y") && do_upgrade="y" || do_upgrade="n"
read -p "Do you want to use ln instead of mkdir for creating directories (y/N)? " -r -e answer
(echo "$answer" | grep -iq "^y") && uselinks="y" || uselinks="n"
read -p "Do you also want to chmod/chown these links (y/N)? " -r -e answer
(echo "$answer" | grep -iq "^y") && chmdir="y" || chmdir="n"
if [ "$do_upgrade" = "y" ]; then
read -p "Do you want to copy an existing config.php file (y/N)? " -r -e answer
(echo "$answer" | grep -iq "^y") && upgrdcfg="y" || upgrdcfg="n"
fi
# check if upgrading an existing installation
if [ "$do_upgrade" = "y" ]; then
read -p "Is the instance in maintenance mode? (y/N)? " -r -e answer
(echo "$answer" | grep -iq "^y") && mmode="y" || mmode="n"
if [ "$mmode" = "n" ]; then
echo "Please enable maintenance mode first: sudo -uwww-data ./occ maintenance:mode --on"
echo
exit
fi
read -p "Please specify the tar file to extract with full path: " -r -e tarFile
if [ ! -f "$tarFile" ]; then
echo "tar file to extract not found. Exiting."
echo
exit
fi
if [ -d ${ocpath} ]; then
mv $ocpath $oldocpath
fi
mkdir -p $ocpath
tar xvf "$tarFile" -C $ocpath --strip-components=1
if [ $? != 0 ]; then
echo
echo "tar extract failed, please check !"
echo
exit
fi
fi
# create / link missing directories
printf "\nCreating or linking possible missing directories \n"
mkdir -p $ocpath/updater
# check if directory creation is possible and create if ok
if [ "$uselinks" = "n" ]; then
if [ -L ${ocdata} ]; then
echo "Symlink for $ocdata found but mkdir requested. Exiting."
echo
exit
else
echo "mkdir $ocdata"
echo
mkdir -p $ocdata
fi
if [ -L ${ocapps_external} ]; then
echo "Symlink for $ocapps_external found but mkdir requested. Exiting."
echo
exit
else
printf "mkdir $ocapps_external \n"
mkdir -p $ocapps_external
fi
else
if [ -d ${ocdata} ]; then
echo "Directory for $ocdata found but link requested. Exiting."
echo
exit
else
printf "ln $ocdata \n"
mkdir -p $linkdata
ln -sfn $linkdata $ocdata
fi
if [ -d ${ocapps_external} ]; then
echo "Directory for $ocapps_external found but link requested. Exiting."
echo
exit
else
printf "ln $ocapps_external \n"
mkdir -p $linkapps_external
ln -sfn $linkapps_external $ocapps_external
fi
fi
# copy if requested an existing config.php
if [ "$upgrdcfg" = "y" ]; then
if [ -f ${oldocpath}/config/config.php ]; then
printf "\nCopy existing config.php file \n"
cp ${oldocpath}/config/config.php ${ocpath}/config/config.php
else
printf "Skip to copy old config.php, file not found: ${oldocpath}/config/config.php \n"
fi
fi
printf "\nchmod files and directories excluding data and apps-external directory \n"
# check if there are files to chmod/chown available. If not exiting.
# chmod
if [ ! "$(find $ocpath -maxdepth 1 -type f)" ]; then
echo "Something is wrong. There are no files to chmod. Exiting."
exit
fi
find -L ${ocpath} -path ${ocdata} -prune -o -path ${ocapps_external} -prune -o -type f -print0 | xargs -0 chmod 0640
find -L ${ocpath} -path ${ocdata} -prune -o -path ${ocapps_external} -prune -o -type d -print0 | xargs -0 chmod 0750
# no error messages on empty directories
if [ "$chmdir" = "n" ] && [ "$uselinks" = "n" ]; then
printf "chmod data and apps-external directory (mkdir) \n"
if [ -n "$(ls -A $ocdata)" ]; then
find ${ocdata}/ -type f -print0 | xargs -0 chmod 0640
fi
find ${ocdata}/ -type d -print0 | xargs -0 chmod 0750
if [ -n "$(ls -A $ocapps_external)" ]; then
find ${ocapps_external}/ -type f -print0 | xargs -0 chmod 0640
fi
find ${ocapps_external}/ -type d -print0 | xargs -0 chmod 0750
fi
if [ "$chmdir" = "y" ] && [ "$uselinks" = "y" ]; then
printf "chmod data and apps-external directory (linked) \n"
if [ -n "$(ls -A $ocdata)" ]; then
find -L ${ocdata}/ -type f -print0 | xargs -0 chmod 0640
fi
find -L ${ocdata}/ -type d -print0 | xargs -0 chmod 0750
if [ -n "$(ls -A $ocapps_external)" ]; then
find -L ${ocapps_external}/ -type f -print0 | xargs -0 chmod 0640
fi
find -L ${ocapps_external}/ -type d -print0 | xargs -0 chmod 0750
fi
#chown
printf "\nchown files and directories excluding data and apps-external directory \n"
find -L $ocpath -path ${ocdata} -prune -o -path ${ocapps_external} -prune -o -type d -print0 | xargs -0 chown ${rootuser}:${htgroup}
find -L $ocpath -path ${ocdata} -prune -o -path ${ocapps_external} -prune -o -type f -print0 | xargs -0 chown ${rootuser}:${htgroup}
# do only if directories are present
if [ -d ${ocpath}/apps/ ]; then
printf "chown apps directory \n"
chown -R ${htuser}:${htgroup} ${ocpath}/apps/
fi
if [ -d ${ocpath}/config/ ]; then
printf "chown config directory \n"
chown -R ${htuser}:${htgroup} ${ocpath}/config/
fi
if [ -d ${ocpath}/updater/ ]; then
printf "chown updater directory \n"
chown -R ${htuser}:${htgroup} ${ocpath}/updater
fi
if [ "$chmdir" = "n" ] && [ "$uselinks" = "n" ]; then
printf "chown data and apps-external directories (mkdir) \n"
chown -R ${htuser}:${htgroup} ${ocapps_external}/
chown -R ${htuser}:${htgroup} ${ocdata}/
fi
if [ "$chmdir" = "y" ] && [ "$uselinks" = "y" ]; then
printf "chown data and apps-external directories (linked) \n"
chown -R ${htuser}:${htgroup} ${ocapps_external}/
chown -R ${htuser}:${htgroup} ${ocdata}/
fi
printf "\nchmod occ command to make it executable \n"
if [ -f ${ocpath}/occ ]; then
chmod +x ${ocpath}/occ
fi
# Tell the user to remove the old instance, do an upgrade, and to end maintenance mode etc., if all is fine.
if [ "$do_upgrade" = "y" ]; then
echo "Please manually remove the directory of the old instance: $oldocpath"
echo "Please manually run: sudo -uwww-data ./occ upgrade"
echo "Please manually run: sudo -uwww-data ./occ maintenance:mode --off"
echo "When all is done successfully, re-run this script and secure your .htaccess files"
echo
fi