Hi everyone. I'm new to OwnCloud and facing some mind boggling issues with my setup. I'm not an IT person nor a sysadmin, but I do know what is a database, an Apache server, network encryption, etc and I'm very comfortable with the theory of an OwnCloud system.
Setup: 3 x Win7 clients + 1 x Mac client, synching data with a hosted server at TMDhost.com. Server side installed via Softaculous with automated scripts. This part works fine and files can upload/download and synch between clients and server, quickly.
1) after the predictable mess of users changing their mind about root directory names (we have 5 root folders and 5 distinct synch connections), I find that some folders on the server, and some files underneath cannot be deleted by anyone, even the admin account from the web interface on the server. There is no useful error message, just "error deleting XYZ".
I understand this must a db file lock issue discussed elsewhere. My problem is this affects over 1GB of files across several hundred sub-folders, so I'm quite worried about applying a brute force SQL script. I don't have the SQL skills to backup everything, test the script and check the logs, roll back in case of pb, etc. Especially if this is going to trigger mass syncing to 4 clients immediately after.
The Owncloud log file is 1MB long and filled with useless messages status messages such as:
=#=#=#=# Propagation starts 2017-03-11T11:40:56 (last step: 1845 msec, total: 1845 msec)
||01 - MM OSB/00-The Story/ECIP -> 01 - ECIP OSB/00-The Story/ECIP|INST_RENAME|Up|1488076049|invalid|0|00001576ocmrmrephzwi|3|Error transferring https://cerulean.asia/owncloud/remote.php/webdav/CCCloud/01 - MM OSB/00-The Story/ECIP - server replied: Locked|423|0|0|||INST_NONE|
=#=#=# Syncrun finished 2017-03-11T11:40:56 (last step: 629 msec, total: 2474 msec)
I say useless because there are so many different types of errors that I can't see any pattern that would direct me to what is wrong.
2) Compounding this problem is the other predictable mess of incompatible Mac filenames with Wn7 file system. Some of the Mac filenames end with spaces or contain forbidden characters. This causes (expected) sync failures with Win clients. Difficulty is that Owncloud "activity" tabs briefly show the errors..and then clears! By the end of a sync cycle, I see only 3-4 errors in the display window, not even related to file naming, when I know there are hundreds of file naming problems.
Trying to extract from the log the list of faulty filenames, hidden among the error lines above, is above my IT skills. I understand something like GREP might help, but I'm not a sysadmin and can't write the right commands. I'm also working remotely on a hosted basic box, so I have no idea where to start to get a command line interface...
3) Now is the interesting part. Until now I'd advise RTFM...
But here is a 3rd problem, really unexpected: one user had the great idea to rename a directory at level 2, just below the sync root directory and above a 1.2 GB large tree. The directory rename did NOT sync to any client, but it did cause a duplicate tree on the server side. This duplicate tree (old tree + new tree) has partially synced to all clients..and stopped. I can see on my Win 7 system 2 x directories, one old, one new. I can see the same on the server. I can also see the same in the OC client window. It has somewhat started to sync to other clients as well.
BUT, the directory sizes and contents are WRONG. On my client Win 7 machine:
- TreeSize shows Dir A = 1.2 GB and Dir B = 667 MB
- OC on the same machine shows Dir A = 863 MB and Dir B = 1 GB
- OC server (web interface) shows the same as OC client (Dir A = 863M / Dir B - 1 GB)
- Win Explorer on the client matches TreeSize
=> This is not a pb of decimal points, counting KB versus MB. The counts are really far off
=> Directory trees which have synced correctly are all good and coherent everywhere. Only this huge tree is completely inconsistent.
=> checking things manually, OC is failing to sync 337M from Client Dir A up from client PC to the server, and failing to sync 333M from Server Dir B down to client Dir A.
Looking only at directory sizes, it seems the pointers between Dir A and Dir B are crossed somewhere, which would explain the odd symmetry and failure to sync properly (337 = almost 333, difference could come from Linux vs Win and KB/MB differences)
Looking at directory contents gives no clue. The contents are in synch from filesystem point of view, but the OC client and server counts are completely off (the OC client is in fact reporting what is on the server - not what is on the client filesystem. I've tried quitting OC and restarting it to make sure it reads a fresh copy from the disk, but no change)
=> The only explanation I can see is that 1) windows/treesize are definitely correct and 2) OC client and server are completely wrong about the size of the folders that are being synced. They must be counting from an internal file list (in OC db?), which is wrong, both in file count and in file size. I'm in a real mess!
The good news is that if OC doesn't even have a clear picture of what it is trying to sync, then I don't need to worry about my first two problems!
1) how is possible that OC is such an unstable app? We have not played with any config parameters or tweaked anything. It's just out of the box from Softaculous, and up to date everywhere. I was expecting a long time to stabilize a system-wide synch with possible duplicates, and a clean-up period afterwards. Instead it feels like I'm alpha-testing...
2) I'm not sure where to go from here. I can't tell if any user has full copy of everything (aprox. 8GB, 55k files, cannot check manually) that we could use as master copy, wiping everything and starting from scratch with that copy.
I'm also worried that trying to fix in a sequential approach will trigger further sync and complicate the mess beyond repair.
If anyone has any great ideas on where to start, I would be really grateful, otherwise I'm going to have to consider moving to Google Drive or similar, which is NOT what I wish to do.
PS: The server side admin account shows 2 setup errors which I thought were trivial, but in case it makes a difference:
Security & setup warnings:
- The "Strict-Transport-Security" HTTP header is not configured to at least "15552000" seconds. For enhanced security we recommend enabling HSTS as described in our security tips.
- No memory cache has been configured. To enhance your performance please configure a memcache if available. Further information can be found in our documentation.