oc7 deleting user data!

[segdy]

I am not entirely sure where it belongs to but since data files gets deleted (!) this id definitely a (huge) bug!

I am testing oC 7.0.0beta1 on Debian wheezy. I have setup a mount to an SMB share which uses login credentials for login:

{ "group": { "shared": { "\/$user\/files\/shared": { "class": "\OC\Files\Storage\SMB_OC", "options": { "host": "localhost", "username_as_share": "false", "share": "data", "root": "shared" }, "priority": 90 } } } }

I installed the client (1.6.1) and sync to this machine. I added a file on the client and whenever I add it some time ago I get "shared/test/Einrichtung Scratch Pad.pdf has been revmoved". FRIGHTENING! Fortunately the file has been uploaded to the server before and is there. But it does not sync back to the client any more and whenever I add it again it comes again and the file gets deleted.

The .owncloudsync.log contains:

|0|shared/test/Einrichtung Scratch Pad.pdf|INST_REMOVE|Down|1404507226|53b71824dd10a|788083||4||0|0|0|||INST_NONE|

What's going on here?

[PVince81]

Does it only happen for that particular file ? Also, I assume this file itself is on the SMB mount, right ?

Can you check whether the file somehow landed in the trashbin ?

[PVince81]

Another question: do you have the "versions" app enabled ? Did you upgrade from an older ownCloud (maybe 6.0.4) ? Did that file already have many versions before ?

Please also post the owncloud.log from the time when it happens, you might be able to find the entries by searching for that file name.

[segdy]

So far it seems just for this file. But there is nothing special about it ... Yes, on server side it is also on the SMB mount.

Regarding trashbin: Don't know what you mean but it is still on the server side. But it is always deleted on the client as it seems. So for very weird reasons it's also not synced back.

Yes, "Versions" is enabled. Yes, I upgraded rom 6.0.4 but without data. Was just a quick test installation (all I need is the SMB gateway with user credentials and this is only supported in oC 7).

No, the file is completely new, I created it, copied it on the client and suddenly I saw the message "xz has been removed". I was very shocked. Then I found that it's at least on the server. But as I said, it does not get synced back and whenever I copy it again, it gets deleted again.

These are the messages in the log (I needed to anonymize it a little bit):

{"reqId":"53b728d6cb3e0","app":"user_ldap","message":"readAttribute: uid=user,ou=test found","level":0,"time":"2014-07-04T22:21:10+00:00","method":"PROPFIND","url":"\/owncloud\/remote.php\/webdav"} {"reqId":"53b728d9926b2","app":"OC\Files\Cache\Scanner","message":"!!! No reuse of etag for 'Shared\/Haushalt\/at' !!! \ncache: Array\n(\n [fileid] => 2157\n [storage] => smb::user@localhost\/\/daten\/\/Shared\/\n [path] => Shared\/Haushalt\/at\n [parent] => 2156\n [name] => at\n [mimetype] => httpd\/unix-directory\n [mimepart] => httpd\n [size] => 788083\n [mtime] => 1404508196\n [storage_mtime] => 1404508196\n [encrypted] => \n [unencrypted_size] => 0\n [etag] => 53b728b498209\n [permissions] => 15\n)\n \ndata: Array\n(\n [mimetype] => httpd\/unix-directory\n [mtime] => 1404512436\n [size] => -1\n [etag] => 53b728d992139\n [storage_mtime] => 1404512436\n [permissions] => 15\n [parent] => 2156\n)\n","level":0,"time":"2014-07-04T22:21:13+00:00","method":"PROPFIND","url":"\/owncloud\/remote.php\/webdav\/Shared\/Shared\/Haushalt\/at"} {"reqId":"53b728d9926b2","app":"OC\Files\Cache\Scanner","message":"!!! Path 'Shared\/Haushalt\/at\/Eckk Einrichtung Scratch Pad.pdf' is not readable !!!","level":0,"time":"2014-07-04T22:21:14+00:00","method":"PROPFIND","url":"\/owncloud\/remote.php\/webdav\/Shared\/Shared\/Haushalt\/at"}

So there is also a file with an Umlaut in the same directory ("Eckküche - Vertico - Primo.pdf"). This file is not deleted but this message worries me:

[...] 'Shared\/Haushalt\/at\/Eckk Einrichtung Scratch Pad.pdf' is not readable

because it's a combination of the two file names where the first file is cut after the Umlaut ...

Besides I have a general question anyways: How does owncloud decide with an SMB share which file to delete, copy or sync? So far I'm afraid this is a bit too fragile ...

[segdy]

So I want to add here that there are generally problems with Umlauts and special characters. I just saw that a bunch of files fail. All of them have in common that they include €, ü, ö, ä, etc. At least they are not deleted. So in any case it would be interesting how oC can delete a file just because an error (?) condition.

I just tested it: When I manually use smbclient it works perfectly. And if I login via web interface and go there: no files! Well, that's probably the reason: There is a bug preventing from oC to display all sorts of files with special characters...

[PVince81]

Can you check that the UTF8 locale is setup properly on your server ? See http://forum.owncloud.org/viewtopic.php?f=17&t=8012

Normally there shouldn't be any encoding issues as everything runs with UTF-8.

[segdy]

Thanks. Ineed that fixed it. Sorry for bothering.

But I wonder why? I work with de_AT.utf8 (which is system locale) and previously I had:

# locale -a
C
C.UTF-8
de_AT@euro
de_AT.iso885915@euro
de_AT.utf8
ja_JP.utf8
POSIX

[segdy]

Unfortunately there's still something fishy: There are two files (with €-symbol and one with Ü) which fail to sync and which are not listed in the web interface

Currently I do not even see entried in owncloud.log unfortunately but an entry from yesterday (for the € file):

{"reqId":"53b53b09508ff","app":"PHP","message":"url_stat(): path 'shared\\Office\\banking\\\u20ac 20.000.pdf' not found at \/var\/www\/owncloud\/apps\/files_external\/3rdparty\/smb4php\/smb.php#260","level":3,"time":"2014-07-03T11:14:17+00:00","method":"PUT","url":"\/owncloud\/remote.php\/webdav\/shared\/Office\/banking\/%E2%82%AC%2020.000.pdf"}

[PVince81]

@segdy can you maybe try deleting and reuploading these files now that you have the correct locale setting ? If the files were uploaded before they might still have a broken file name.

Also: I have no idea why it wouldn't work with de_AT.utf8...

[karlitschek]

I assume this is fixed with the right locale