OwnCloud Other Stuff
Information provided here may sometimes lean towards a user with "Intermediate" and some "Advanced" computer skills. But don't let that scare you off!
The ownCloud "Files" storage can be mounted to a local folder on a client workstation via WebDav. This can be done in one of two ways; manually via a file manager like Nautilus on some Linux distributions, or by auto-mounting when a user logs in to their workstation. The following access methods are explained with respect to a Fedora workstation.
Access via Nautilus
- Run the Nautilus file manager.
- From the Nautilus menu navigate to "File => Connect to Server...".
- Enter the details for the Amahi ownCloud URL in to the "Server" field.
- In the "Type" drop-down field, select "WebDAV (HTTP)".
- In the "Folder" enter "/files/webdav.php".
- Enter the ownCloud user ID, password, and check off "Remember this password" (only if you went to).
- Click on the "Connect" button. Nautilus will open to the ownCloud storage for the user and show a mounted folder on the desktop.
- Now you can work with files stored on ownCloud like they are on the workstation.
- Want to know something real cool? Bookmark the ownCloud connection in Nautilus! If you do this you can manually mount ownCloud when the need arises.
Auto-mount on Login
- Open a "terminal" window on the host server and "su" to the "root" ID (administrator).
- Install the WebDav client for the workstation distribution.
yum install davfs2
- Add the ownCloud user(s) you want to be able to mount the share to "davfs2".
usermod -aG davfs2 test
- Edit /etc/fstab. Add the following line for each user that wants to mount the folder (with your details where appropriate).
For version 1.x: ADDRESS/webdav/owncloud.php /home/<username>/owncloud davfs user,rw,noauto 0 0 For version 2.x: ADDRESS/files/webdav.php /home/<username>/owncloud davfs user,rw,noauto 0 0
Example fstab entry:owncloud.server_name/files/webdav.php /home/test/owncloud davfs user,rw,noauto 0 0
- Close the terminal window.
Setup for Each ownCloud User ID:
- Open a "terminal" window. You do not need to "su" to the root ID.
- For each user create the directories "owncloud" and ".davfs2" (remember this is a hidden directory) in each user /home directory.
- "cd" in to the ".davfs2" directory.
- Create the file "secrets" file.
- Depending on the version of the WebDav client enter one of the following text will be entered in to "secrets".
For version 1.x: ADDRESS/webdav/owncloud.php <user ID> <user password> For version 2.x: ADDRESS/files/webdav.php <user ID> <user password>
- Note: <user ID> and <user password> are to be replaced with each user's ID and password.
Example "secrets" file:owncloud.server_name/files/webdav.php test testy001
- Setup permissions on the "secrets" file so that a owner user ID can write to their file.
chmod 600 ~/.davfs2/secrets
- Now test the setup for a user ID.
mount /home/<user ID>/owncloud
- Enter the following text in to each user's "/home/<user ID>/home/.bashrc" file:
mount /home/<user ID>/owncloud
- There should be an "owncloud" folder now on the workstation desktop after each successful logon.
- ownCloud will auto-mount from this point and you can work with files stored on ownCloud like they are on the workstation.
As of ownCloud release version 6 a new security feature was added, "Trusted Domains". This feature is allows only trusted URLs and/or IP addresses to access ownCloud. During the initial installation process for a new ownCloud instance the first trusted domain is captured (URL/IP address) and added to the ownCloud "config.php" file.
Any "untrusted" access will show an error message at the login session:
You are accessing the server from an untrusted domain. Please contact your administrator. If you are an administrator of this instance, configure the "trusted_domain" setting in config/config.php. An example configuration is provided in config/config.sample.php.
To resolve this the new domain can be added to the owncloud config.php, in the config directory. OR By commenting out the trusted_domains setting.
In this example IP addresses will be used to demonstrate the trusted domains feature. The server in this example has an address of "192.168.0.101" on a wired network connection. It has been decided to add a Wifi connection to the server, which forms a "subnet" with address of "192.168.99.1". The Wifi subnet is a new domain, and is considered as an untrusted domain by ownCloud.
Configure Trusted Domains:
- Locate the "config.php" file in the owncloud "config" directory.
- Using an editor open the file as the "root" user, initially it will have the following entry:
'trusted_domains' => array ( 0 => '192.168.0.101', ),
- Put a second entry in to the "trusted_domains array" for the Wifi address as follows:
'trusted_domains' => array ( 0 => '192.168.0.101', 1 => '192.168.99.1', ),
- Comment out the "trusted_domains array" as follows:
/* 'trusted_domains' => array ( 0 => '192.168.0.101', 1 => '192.168.99.1', ), */
Is this a security issue? That depends on the system owner or administrator...
- Save the changes and exit the editor.
- Any subsequent web browser access via the Wifi address to ownCloud will not be blocked.
ownCloud Logfile Size
This tid bit was picked up from an ownCloud Blog item. The "owncloud.log" file, lives in the ownCloud "data directory", can reach a rather large file size. In the case of the blog a file size of 5.9 gigabytes big. Yeah, 6318901632 bytes.
- ownCloud can keep that file in check, but you have to enable that by adding the following to "config.php":
'log_rotate_size' => '100 MiB',
- Using a text editor the config.php file will look like this afer the change:
$CONFIG = array ( 'instanceid' => '515c94d976c01', 'passwordsalt' => '6144794036e3aabc7d239238266b8e', 'datadirectory' => '/var/hda/files/owncloud7/data', 'dbtype' => 'mysql', 'version' => '220.127.116.11', 'dbname' => 'owncloud7', 'dbhost' => 'localhost', 'dbtableprefix' => 'oc_', 'dbuser' => 'owncloud7', 'dbpassword' => 'owncloud7', 'installed' => true, 'theme' => , 'maintenance' => false, 'log_rotate_size' => '100 MiB', );
- Reboot the server.
- On a regular basis before backups are done make sure to delete any old log files no longer required.