All files should be synchronised.
The synchronisation fails on the same three files over and over. It is the same three files every time and the service disconnects and after a while the service restarts from the beginning.
NOTICE that the client fails on an ANTIVIRUS test file "eicar.com.txt" this is only a testfile for antivirus programmes. There is no virus in the file, but the antivirus program handles the file as a virus infected file. Ex. block reading, putting in to quarantine or something else. I dont know if this is related to the error. But it could be???
Operating system: Debian 7.9
Web server: Nginx 1.8.1
Database: MySQL 5.6.29-1
PHP version: 5.4.45-1
ownCloud version: 8.2.2
Storage backend:
Client version: 2.1.1
Operating system: Linux Mint 17.3
OS language: ?
Installation path of client:
Please use Gist (https://gist.github.com/) or a similar code paster for longer
logs.
Template for output < 10 lines
owncloud --logwindow or owncloud --logfile log.txtcmd.exe, you might need to first cd into the ownCloud directory)The client log can be foud here: http://pastebin.com/1Vrfz6rj
2016/03/17 10:31:27 [error] 25599#25599: *839275 access forbidden by rule, client: ::ffff:127.0.0.1, server: owncloud, request: "GET /data/htaccesstest.txt HTTP/1.1", host: "fractal.lindegaard.one:8443"Form the ordinary log.
::ffff:192.168.2.40 - christian [17/Mar/2016:10:32:23 +0100] "GET /remote.php/webdav/ownCloud/Development/WorkspaceMinecraft/MobHunting/.git/objects/78/e555eb744230ea90a0$
::ffff:192.168.2.40 - christian [17/Mar/2016:10:32:23 +0100] "GET /remote.php/webdav/ownCloud/Development/WorkspaceMinecraft/MobHunting/.git/objects/79/0380dc4ff76b47b7a6$
::ffff:83.89.10.90 - christian [17/Mar/2016:10:32:24 +0100] "GET /ocs/v1.php/cloud/activity?page=0&pagesize=100&format=json HTTP/1.1" 200 3854 "-" "Mozilla/5.0 (Linux) mi$
::ffff:192.168.2.40 - christian [17/Mar/2016:10:32:24 +0100] "GET /remote.php/webdav/ownCloud/Development/WorkspaceMinecraft/MobHunting/.git/objects/79/9e410ecca688437488$
::ffff:83.89.10.90 - christian [17/Mar/2016:10:32:24 +0100] "GET /remote.php/webdav/ownCloud/Documents/eicar.com.txt HTTP/1.1" 503 232 "-" "Mozilla/5.0 (Linux) mirall/2.1$
::ffff:83.89.10.90 - christian [17/Mar/2016:10:32:24 +0100] "GET /remote.php/webdav/ownCloud/LiteLoader%20for%20Minecraft/mods/mod_voxelMap_1.5.17_for_1.8.litemod HTTP/1.$
::ffff:83.89.10.90 - christian [17/Mar/2016:10:32:24 +0100] "GET /remote.php/webdav/ownCloud/LiteLoader%20for%20Minecraft/mods/mod_worldeditcui_1.7.10_00_mc1.7.10.litemod$
::ffff:83.89.10.90 - christian [17/Mar/2016:10:32:24 +0100] "PROPFIND /remote.php/webdav/ HTTP/1.1" 207 372 "-" "Mozilla/5.0 (Linux) mirall/2.1.1"
::ffff:83.89.10.90 - christian [17/Mar/2016:10:32:25 +0100] "GET /ocs/v1.php/cloud/activity?page=0&pagesize=100&format=json HTTP/1.1" 200 3860 "-" "Mozilla/5.0 (Linux) mi$
::ffff:192.168.2.40 - christian [17/Mar/2016:10:32:25 +0100] "GET /remote.php/webdav/ownCloud/Development/WorkspaceMinecraft/MobHunting/.git/objects/79/9f003a087c7472c84e$
::ffff:83.89.10.90 - christian [17/Mar/2016:10:32:25 +0100] "PROPFIND /remote.php/webdav/ HTTP/1.1" 207 422 "-" "Mozilla/5.0 (Linux) mirall/2.1.1"
Fatal webdav Exception: {"Message":"HTTP\/1.1 503 Could not open file","Exception":"Sabre\\DAV\\Exception\\ServiceUnavailable","Code":0,"Trace":"#0 \/var\/www\/owncloud\/3rdparty\/sabre\/dav\/lib\/DAV\/CorePlugin.php(82): OC\\Connector\\Sabre\\File->get()\n#1 [internal function]: Sabre\\DAV\\CorePlugin->httpGet(Object(Sabre\\HTTP\\Request), Object(Sabre\\HTTP\\Response))\n#2 \/var\/www\/owncloud\/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\n#3 \/var\/www\/owncloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(469): Sabre\\Event\\EventEmitter->emit('method:GET', Array)\n#4 \/var\/www\/owncloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(254): Sabre\\DAV\\Server->invokeMethod(Object(Sabre\\HTTP\\Request), Object(Sabre\\HTTP\\Response))\n#5 \/var\/www\/owncloud\/apps\/files\/appinfo\/remote.php(56): Sabre\\DAV\\Server->exec()\n#6 \/var\/www\/owncloud\/remote.php(137): require_once('\/var\/www\/ownclo...')\n#7 {main}","File":"\/var\/www\/owncloud\/lib\/private\/connector\/sabre\/file.php","Line":268} 2016-03-17T10:32:23+01:00
Error PHP fopen(/media/ea21f108-b011-4381-9bfb-486f4cb70476/owncloud//christian/files/ownCloud/Documents/eicar.com.txt): failed to open stream: No such file or directory at /var/www/owncloud/lib/private/files/storage/local.php#247 2016-03-17T10:32:23+01:00
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
I don't know your server configuration. Do you have https://doc.owncloud.org/server/8.2/admin_manual/configuration_server/antivirus_configuration.html installed?
I guess then the better bugtracker to ask this is https://github.com/owncloud/core
No. My server started as an "OpenMediaVault" (OMV) NAS Server, but I
have installed ownCloud manually using ownClouds documentation. I use
the Anti virus setup from OMV, which is clamav. I have investigated this
issue a bit more and has discovered that I can only see the
"eicar.com.txt" file when I use the web interface. When I look directly
into the file system it seems like it has disappeared. I will now try to rescan all the files by running sudo -u www-data ./occ files:scan --all --quiet &
Maybe the Anti Virus program has removed the file. On the other had this
should not stop the ownCloud syncronisation, it should only skip the
file. Right?
Update: after scanning all users. I can still see the files in the
web-interface, but I can't find the file in the file-system???
@Rocologo does the OMV-AntiVirus-Solution do on-access-scans? If so, try to disable it. Sounds like the OMV-AV detects the EICAR-file and removes it right away.
I have found a workaround on my problem that the synchronisation stopped. I think it is ClamAV which has move the "EICAR test file" into the quarantine folder, without ownCloud knowing this. So I decided to rescan all my files with "sudo -u www-data ./occ files:scan --all --quiet &" waited 6 hours until occ has finished scanning my files (I have +180.000 files so it takes some time). After this my ownCloud client didn't stop with "service unavailable" any more.
I think I will do a weekly background scan going forward.
But I still think it is a bug that ownCloud stops with "service uavailable" because it could not find a file. It should have skipped the file with a warning / error and then continue with the rest of the files, instead of restarting over and over again.
@dragotin @ogoffart @ckamm We treat 503 during discovery as something we can skip. Maybe this should also be done during propagate?
(Not sure for which operations though... all?)
But I'm not sure about the implications.. if we'll still endlessly resync?
This would also help in other cases like https://github.com/owncloud/client/issues/4573
I see the problem with possible endless resync. I my case the problem was that the file was removed on the server. An idea could be that the ownCloud client asked the server to verify if the file actually existed in the file system, and the skipped the file in the database (and maybe removed it from the database too)?
Or if you could somehow make the user aware of the inconstistence and let the user to decide what to do? Ex. let the user do a single folder rescan... or something. (I'm just brainstorming).
Did anyone get an answer this one? I have installed ownCloud and it worked for a day then the service unavailable problem started.
@Scuttman Do you habe Eicar Virus? Can you still access the webinterface? Which request errors out? Do other DAV clients work?
@guruz Thank you for your reply. I solved it with a re-install. Something went wrong during the enable encryption process. I might try encryption again but at the moment it is now syncing again successfully.
Also this was probably much improved in 2.3 as we hide the "operation cancelled" error.
I'm now closing this old issue. A "Service Unavailable" probably mean some configuration problem on the server side.
This is not a server side problem but a sync client one. I experienced the same symptom: files created, marked for sync but deleted before sync completion. Then the sync agent (version 2.3.2 in this case) starts reporting an error with "service unavailable".
On the server side, for the removed files, OC reports "... Exception: {\"Message\":\"HTTP\\/1.1 503 Could not open "file\",\"Exception\":\"Sabre\\DAV\\Exception\\ServiceUnavailable\",\"Code\":0 ..."
Running php occ files:scan
@raphlep I solved the problem! Thanks!
@ogoffart I think you should reopen this issue...I'm with OC10.0.2 and client 2.3.2 and I'm having problems with this.
@raphlep Which server version do you use?
Is that in a shared folder?
@GTT8 Is that in a shared folder? Or anything else special on the server side?
@guruz No, It's not a shared folder. In fact it is a clean install that I did yesterday and it happens only with large files while uploading from the client app (it does upload correctly from the web interface with large files).
Server config:
MySQL: 5.7.15
PHP: 7.0.19
APCu: 5.1.8 (cach茅)
Redis: 3.1.8 (file locking)
Apache: 2.4.25
@GTT8 Could you create a new issue in the 'core' bugtracker as I think this is unrelated to the issue described in here originally.
So you said the issue is fixed when running the files scan?
Then it would be important to know details about the server (external storage etc?) that could give us a hint on how this is caused..
thanks
Most helpful comment
This is not a server side problem but a sync client one. I experienced the same symptom: files created, marked for sync but deleted before sync completion. Then the sync agent (version 2.3.2 in this case) starts reporting an error with "service unavailable".
On the server side, for the removed files, OC reports "... Exception: {\"Message\":\"HTTP\\/1.1 503 Could not open "file\",\"Exception\":\"Sabre\\DAV\\Exception\\ServiceUnavailable\",\"Code\":0 ..."
Running php occ files:scan solved the issue.