I used to run OwnCloud on Fedora, and have finally been able to get it working again now.
The environment is a Fedora29 server running apache.
The main issue is… you cannot get the owncloud server running using the packages in the official Fedora repositories, I think from memory those stopped working around F27 when some renaming went on and it became not owncloud and then back to owncloud between releases; but simply put you will never get it running using the official Fedora repositories.
I tried deleting all packages associated with OwnCloud and re-installing from scratch from the F29 repositories, but still a non-working solution. The error was PROPFIND errors from the server. Basically the Fedora29 repositories do not provide a working OwnCloud server.
It should however be noted that the owncloud-client packages from the Fedora29 repositories do provide a working desktop client, it is only the server files that need to be installed without the Fedora repositories.
Solution, use the official OwnCloud server repository
These are the steps needed to get a working server.
- use “rpm -qa | grep -i owncloud” and remove all packages installed from the Fedora repositories; they will cause conflicts with the owncloud repositories unless removed
- follow the documentation on the official OwnCloud site at https://download.owncloud.org/download/repositories/stable/owncloud/index.html to add the owncloud repository and install the owncloud-files package
The package owncloud-files from the owncloud repository installes the OwnCloud files into /var/www/html/owncloud, and will use sqllite for the database.
The installation location is where you would expect it to be for a vanilla Fedora website setup where DocumentRoot is set to /var/www/html, I of couse do not have my documentroot configured to point there, so to get it working for my site I simply added the following as a new file /etc/httpd/conf.d/owncloud.conf so the /owncloud URL could find the installed files.
Alias /owncloud /var/www/html/owncloud
<Directory /var/www/html/owncloud>
<IfModule mod_authz_core.c>
# Accessible to all machines in your network
# Replace with “Require local” if you want access to be restricted
# to this machine.
Require all granted
</IfModule>
</Directory>
I left the database as sqllite as from the documentation I couldn’t figure out how to get mariadb setup as the database, so had to use the default sqllite setup. I had previously used mariadb so I know it is possible, I will have to revisit that later (the documentation does contain a database conversion documentation section, I’ll see how it works later); in the meantime I have just dropped the existing mariadb owncloud database I had.
It all looked OK, using a web browser to the http://xxx.xxx.xxx.xxx/owncloud location I was able to add the new admin user, was able to add a new personal group and personal userid.
The good news for Fedora users is that the owncloud-client packages in the Fedora29 repositories do work, and I was able to to connect the Desktop client to the new OwnCloud server installation. Which is when this got frustrating.
Issues or feature changes found
- configuring to syncronise a directory, /home/mark/owncloud, does not syncronise the directory as expected
- in the current version it does not syncronise the entire directory, only Documents and Photos (theoretically, have not seen it working). I did manually add another subdirectory to the syncronisation list via the desktop interface which appeared on the server but no syncronisation occurred on the files in that Directory
- the previous version behaviour was that anything added on the configured client directory /home/mark/owncloud on the client automatically got syncronised to the server
- as noted above, files and directories added to the configured directory for syncronisation on the desktop were not getting get syncronised to the server, not even from the new subdirectory I had manually configured for replication
- This syncronisation issue was resolved on one desktop by rebooting the desktop to get a clean restart of the owncloud client even though it was a completely new connection/account that was just connected.
By resolved I should point out the populated directory on the desktop took it’s syncronisation direction from the server, and the desktop ended up with an empty directory; but when copying files back into that directory on the desktop side (always backup before playing) the files added on the desktop side into my manually configured additional directory were finally replicated onto the server - On a second desktop, it was also rebooted and only then started syncronising correctly with the configured directories; does this mean that if the server is taken down for any reason all desktops have to be rebooted ? Anyway an important point here is that the manually added directory was populated on this second desktop and it kept the contents, only checking for changes from the server; so I guess on any new install/upgrade populate the server side directories before attaching a client
- And one other minor point, using the desktop interface on both desktops while clicking down to subdirectories shows the same contents total filesizes as the same, the top level directory list shows different sizes (ie: on desktop one a subdirectory shows 29MB used but the top level shows only 22MB used, desktop two shows correct sizes. Doesn’t seem to affect usablility
- It has a list of files to exclude from syncronisation, while this includes pretty much anything starting with a . which is a good default that unfortunately includes things like .gitignore, and while the wildcard patterns could be updated to allow everything bit .g for example, or just remove all exclusions, that would have to be done on every desktop client. However for syncronising normal documents this is not an issue
Does it work as expected
Deleting a test file from Documents on one desktop did result in it being deleted from the second desktop, creating a new file does result in it being replicated to the other desktop, changing the contents of the file does result in the newer file being replicated to the second desktop; so yes it works as expected.
It should be noted that With a small testfile the replication bouncing through the server takes less than 30 seconds so the owncloud desktop clients must be polling the server fairly often so a dedicated web server should probably be used; and frequent updates to large files may cause an issue if many desktops are configured. It is also not recomended to use sqllite for large environments so you will need to read the manuals on how to use mariadb a bit more carefully than I have so far.
For myself I have started using it again for files I want to ensure I have more than one safe copy of but do not want to replicate via the public internet using dropbox.
Update 18 June 2019
A F30 server package for owncloud-files is now available at https://download.owncloud.org/download/repositories/stable/owncloud/index.html, however it seems to be identical to the F29 version and is incompatible with the php version shipped by default with F30. I am still using the Fedora client packages, there are ISV packages for F29 clients at https://software.opensuse.org/download/package?project=isv:ownCloud:desktop&package=owncloud-client but no F30 client packages there yet. The error returned when the client connects to the server is
This version of ownCloud is not compatible with PHP 7.3 You are currently running PHP 7.3.6.
So if you need ownCloud do not upgrade beyond F29; for a while anyway. Also note that WordPress recommends php version 7.3 or higher which as you see I use WordPress means I will not be even investigating downgrading php to get ownCloud working on F30.
Update 20 Nov 2019
There is now a working F30 version available at https://download.owncloud.org/download/repositories/production/owncloud/ should you still be on F30 (version 10.3.1-2). However the F30 OS is out of support next month and there is no F31 package. You cannot upgrade from a previous version so must re-install for F30 which I have done anyway, and it works.
There is a package available for CentOS8 and due to the rapis releases of Fedora (where 3rd party repos just cannot keep up) I will be converting my webserver from Fedora to CentOS so there are unlikely to be further updates here.
