[Regression] [Windows] Sync folder on UNC-symlinked network storage is not working anymore #5633
Comments
bOOT-CoDe
changed the title
|
Hey @bOOT-CoDe! thanks for reporting! I've just done a few tests with a similar setup (syncing my
Do you have any client logs or more info (e.g. which kind of filesystem runs, if the disk is encryped, etc.) to provide that could help us reproduce the issue you are running into? Thanks! |
|
Hi @SamuAlfageme, |
SamuAlfageme
changed the title
|
@bOOT-CoDe I see, that's a bit more complex scenario, I will try to reproduce.
Can you provide some client logs and the error string the client is displaying? Thanks a lot! |
|
I have excactly the same issue: https://central.owncloud.org/t/network-folder-wont-work-in-v2-3-0-v2-3-2-but-in-v2-2-4-win-desktop-client/7627/2 |
|
@bOOT-CoDe @NM78 I've tested different network shares (not SMB, though) using both Windows' shortcuts and
Also, I was able to use the UNC path directly in the setup wizard. Did you experience otherwise? Do you guys have any additional steps that could be leading to this issue?. Also, client logs will be really helpful to track what's happening under the client's hood. |
|
Thx 4 your fast answer! Here is my log: The win 2.3.2 client shows a red message "Synchronisationsbericht konnte nicht initialisiert werden." I know, we had a similar issue some years (maybe 2?) ago. But i could not find a link to this anywhere. EDIT: Sorry, 4 the horrorbly formated Log Code, i used the "insert code" tag for this and dont know how to do this better. |
|
@NM78 thanks a lot for the logs! Is your network folder an SMB share as @bOOT-CoDe? maybe we can isolate the issue in those. However, even with that share I'm not being able to reproduce:
What are the logs saying:
|
| Read & Write Permissions | Read-Only Permissions |
|---|---|
 |
 |
OCC::SyncEngine::startSync: ===== new sync (no sync journal exists)
Even though, this says otherwise, I have to ask if there was an already existing and working (with client 2.2.4) sync folder on the shared drive? and the update started causing this problems?. This could be a permissions issue on the .db file (the migration strategy: https://github.com/owncloud/client/blob/master/src/libsync/syncjournaldb.cpp#L64 might overlook windows-specific permissions)
Problems creating the sync journal:
In the logs these 2 functions appear as failing:
... maybe we can include more debugging messages on the logs in a testing client to see what's going on there. cc/ @guruz @ckamm what do you guys think?
Some changes introduced in 2.3.0 that might relate:
- Updated the version of Sqlite3: 76fde49
- Introduced a new naming convention for the sync journal (
._XXXXXX) to support Allow multiple accounts to sync the same local folder #3764. Maybe the new "invisible" filename used can cause problems in some types of shared storages. Will look into it.
guruz
changed the title
|
@bOOT-CoDe Did you also use 2.2.x before and it worked? I think @dragotin or me or @ckamm might have also changed something about canonical file system paths of sync folders? @bOOT-CoDe @NM78 I'm wondering if you set the |
|
@bOOT-CoDe @NM78 Any news? |
|
Unfortunately, I can confirm this bug. Upgraded Windows Client to Version 2.3.1 (build 8) (supplied by Nextcloud), from some 2.2.x Version (not completely sure). Previously, I had a "local" folder at a UNC-symlinked network storage like I tried and none of these worked...
What I found, however, was that the Client Log: client-log-v2.3.1.txt (after click on "continue sync" for the non-working folder sync) Syncing with local folders on my PC works as expected. Additional Info: Local: Windows 8.1 |
|
I've tried reproducing again, but without success.
Looking at the logs again, it seems it's sqlite3 that returns SQLITE_CANTOPEN. We did indeed update sqlite between 2.2.4 and 2.3.1. It seems we could use @ElpyDE @bOOT-CoDe: Would you be up for testing with a 2.4 snapshot build that has additional logging in the sync journal creation code? |
My folder isnt mapped as network drive. Its a directly path like "\ \ QNAP-01\MyFiles\OwnCloud" This is what works in earlyer versions and in 2.2.4. |
|
@NM78 Could you provide or link a quick step-by-step guide how to configure the "directly path" thingy? |
|
@NM78 @ElpyDE @bOOT-CoDe What kind of filesystem is the network drive running? Maybe that helps for reproducing the problem. |
|
Indeed, it worked on a network share on my local computer (Win 8.1, NTFS). The non-working share is based on my institute's fileserver. My admin just told me it's some sort of Linux based OS. Filesystem there is ext4. Network share is via Samba (SMB). Edit: The local share on my Windows PC works already with permission "change" and "read" and without "full access". Not sure if that helps anyhow. |
|
@ElpyDE Thanks for checking with them. I've now tested a simple samba share of an ext4 directory, but it still works for me. I hope that the extra logging added to master will allow us to pinpoint what exactly goes wrong with database creation in sqlite3. I'll ping here once a nightly with the code becomes available. |
|
@bOOT-CoDe @NM78 I'm wondering if you set the OWNCLOUD_SQLITE_JOURNAL_MODE environment variable to DELETE for the ownCloud client process, does it behave differently? |
|
@guruz Setting the environment variable should have no effect since it already fails at |
|
More logs... downloaded, installed and tested with two nightly builds from https://download.owncloud.com/desktop/daily/ Version 2.3.3-nightly20170612 (build 34) Log: ownCloud--Version 2.3.3-nightly20170612 (build 34).log.txt Version 2.4.0-nightly20170613 (build 20) Log: ownCloud--Version 2.4.0-nightly20170613 (build 20).log.txt For both versions, I configured 3 folder syncs:
The first and second syncs worked perfectly. The third did not. log files have been anonymized, hopefully in a meaningful way |
|
@ElpyDE Thank you! Most relevant: The 14 is just |
|
@dschmidt Could you create a Windows build from the sqlite3_revert_3161 branch and paste the .exe link here? :) |
|
@ElpyDE @NM78 @bOOT-CoDe https://download.owncloud.com/desktop/daily/ownCloud-2.4.0.44git-setup.exe Should have the older sqlite3 version. Does it work better with that? |
|
I need to revert one more commit, @ckamm is right. Will make a build.. |
|
@ElpyDE @NM78 @bOOT-CoDe https://download.owncloud.com/desktop/daily/ownCloud-2.4.0.45git-setup.exe should be available in some minutes |
|
Tested both builds linked by @guruz - with equal settings as above in #5633 (comment) Unfortunately, the results are also equal: Local directory and share on Win-PC work. Share on Linux-Server (ownCloud-test3) fails. ownCloud-2.4.0.44git-setup.exe Log: ownCloud--Version 2.4.0git (build 44).log.txt ownCloud-2.4.0.45git-setup.exe Log: ownCloud--Version 2.4.0git (build 45).log.txt Warnings like before in both builds alike, here from build 45: |
|
@ElpyDE Thanks again for the tests. In that case my last suggestion would be that maybe the paths we pass to Besides that, the only other option I can imagine is that this particular path is somehow invalid for the network drive? @ElpyDE can you manually create a |
|
@guruz I've now run 2.2.4 and a newer version on windows, and these paths get fed to sqlite3: So there's no structural difference besides the different database file name. @ElpyDE Is there anything else hidden in your "Some Path/Myname" component? Would you be up for also providing us with a log from a 2.2.4 client where it works? (you can get the 2.2.4 windows binaries from https://owncloud.org/changelog/desktop/) I assume mounting the path to a network drive leads to the same issue? |
|
Version 2.2.4 works as expected: Log: ownCloud--Version 2.2.4 (build 6408).log.txt @ckamm was right estimating a problem with invalid path: I cannot create a file called Some further research showed, that it is about the "._" prefix: $ mv something.ext ._something.ext
mv: cannot move 'something.ext' to '._something.ext': No such file or directoryFile names that work
File names that don't work
|
|
TODO: |
|
PS: The "don't work" file names do work on my local Windows PC. |
https://www.lavalite.de/2008/10/12/disable-creation-of-_files-dot-underscore-files/ |
|
@NM78 @bOOT-CoDe Can you please also try the above filenames on your setup and also ask your sysadmin if he/she knows about this? ^^ |
|
@ElpyDE Great, we found it! The reason the journal file has the "._" prefix is to ensure that the new journal file won't be uploaded to the server if someone switches back from client version 2.3 to 2.2. For this reason we pick a filename that will be excluded by an ignore pattern that was already present in 2.2. It looks like this particular prefix is often forbidden by samba configurations though. There are a couple of other ignore patterns, but is seems possible that if we called the journal So maybe the most reasonable path open to us is to give up on the nice compatibility guarantee and use |
|
@ckamm @ElpyDE Indeed, just tried with the veto ( |
When synchronizing a folder on a samba share, creating files that begin with ._ is often forbidden. This prevented the client from creating its ._sync_abcdef.db file. Now, it'll check whether the preferred filename is creatable, and if it isn't it'll use .sync_abcdef.db instead. The disadvantage is that this alternative path won't be ignored by older clients - that was the reason for the ._ prefix.
|
PR #5844, but still untested |
|
@ElpyDE As a workaround, you could try opening your owncloud.cfg and changing the |
|
@ckamm Thanks for the workaround. Works like a charm ✔️ Thank you all for your wonderful work! |
|
Closing in favour of PR. :) |
When synchronizing a folder on a samba share, creating files that begin with ._ is often forbidden. This prevented the client from creating its ._sync_abcdef.db file. Now, it'll check whether the preferred filename is creatable, and if it isn't it'll use .sync_abcdef.db instead. The disadvantage is that this alternative path won't be ignored by older clients - that was the reason for the ._ prefix.
Expected behaviour
Synchromize sync folder.
Actual behaviour
An error about not accessible folder is repeated.
Steps to reproduce
Client configuration
Client version:
2.3.0.6780
Operating system:
Windows Vista Home 32-bit
Windos 7 Enterprise 64-bit
The text was updated successfully, but these errors were encountered: