Difference between revisions of "OwnCloud Other Stuff"
Line 103: | Line 103: | ||
</blockquote> | </blockquote> | ||
− | To resolve this the new domain can be added to the owncloud config.php, in the config directory. OR | + | To resolve this the new domain can be added to the owncloud config.php, in the config directory. '''OR''' By commenting out |
the trusted domain setting. | the trusted domain setting. | ||
+ | |||
+ | '''Example Scenario:''' | ||
<br /> | <br /> |
Revision as of 18:59, 2 September 2014
Work in Progress tag:
Work In Progress | |
---|---|
This article is currently undergoing major expansion or restructuring. You are welcome to assist by editing it as well. If this article has not been edited in several days, please remove this template. |
Information provided here may sometimes lean towards a user with "Intermediate" and some "Advanced" computer skills. But don't let that scare you off!
Contents
Removing an ownCloud Application
Even though an ownCloud application is "Disabled" (administration user only) the program code remains in a directory. Sometimes it may be necessary to completely remove the application's program code from the ownCloud instance. Additionally there are some database entries that have to be removed also. In this example the "Who Share" application code will be removed.
- Ensure that the application is disabled in Settings => Apps.
- Open a "terminal" window on the host server and "su" to the "root" ID (administrator).
- "cd" in to the "/var/hda/web-apps/owncloud/html/apps" directory. This is where the ownCloud applications are stored.
- Using the "ls" command a directory "files_whoshare" will be displayed. This is the directory that will be removed.
- Using the "rm -fr files_whoshare" command the "Who Share" application code is removed.
- Using the "ls" command again should show that the "files_whoshare" is gone.
- Close the terminal window.
- All entries in the ownCloud MySQL database have to be removed this can done by using Amahi "phpMyAdmin".
- In the database table "oc_appconfig", find all entries having the name of the "files_whoshare" application as "appid".
- Remove those entries.
- Now the "files_whoshare" application is completely removed from ownCloud.
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
Workstation Setup:
- 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.
Trusted Domain
As of ownCloud release version 6 a new security feature was added, "Trusted Domain". This feature is allows only trusted URL 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 domain setting.
Example Scenario: