Directories not sync'ed

I’ve just setup Nextcloud on hostiso and I’ve started sync’ing my home directory (/home/vladimir). But Nextclould will only sync 6 non-hidden top-level directories out of about 70, and a similarly small subset of hidden top-level directories. Only a subset of files and directories in the last sync’ed non-hidden top-level directory have been sync’ed.

There are no not-sync’ed files or directories shown in the nextcloud-client (v2.3.0-1 which I got from the archlinuxfr repository), and I haven’t specified any additional files to ignore other than the apparently default ones.

When Nextcloud started sync’ing, the client showed that 177GB were to be sync’ed (which is a little less than the 181GB that the du utility shows is in my home directory) but only 16GB seems to have made it.

Does anyone have an idea where I should start looking to fix this problem?


Just a guess, but can you verify in the client under General, that you unchecked "Ask for confirmation before synchronizing files larger than [500] MB?"
Sometimes it’s easy to miss the popup asking to confirm the download.

“Ask for confirmation before synchronizing files larger than [500] MB?” is unchecked as is “Ask for confirmation before synchronizing external storages.” I unchecked both early on.

When you expand the Folder Sync Connection, do you see all folders checked or are some unchecked? And does it show that all files have been synced? How long has it been running? Maybe try to pause and resume it to see if it looks for “new changes.”

I see all folders checked, but only a subset of all existing folders are listed.

Looking at the content of a few of the directories which have been sync’ed, some files have been sync’ed, but only a subset of the files in a folder.

I am now getting

"nextcloud” terminated by signal SIGSEGV (Address boundary error)

I am running nextcloud under gdb.

Thread 1 "nextcloud" received signal SIGSEGV, Segmentation fault.
0x00000000000000c0 in ?? ()
(gdb) where
#0  0x00000000000000c0 in  ()
#1  0x00007ffff4de869e in OCC::OwncloudPropagator::scheduleNextJob() () at /usr/lib/
#2  0x00007ffff3620ba9 in QObject::event(QEvent*) () at /usr/lib/
#3  0x00007ffff466134c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/
#4  0x00007ffff4668b61 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/
#5  0x00007ffff35f4440 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/
#6  0x00007ffff35f6bcd in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
    at /usr/lib/
#7  0x00007ffff3648c43 in  () at /usr/lib/
#8  0x00007fffefe9d5a7 in g_main_context_dispatch () at /usr/lib/
#9  0x00007fffefe9d810 in  () at /usr/lib/
#10 0x00007fffefe9d8bc in g_main_context_iteration () at /usr/lib/
#11 0x00007ffff364904f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /usr/lib/
#12 0x00007ffff35f289a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/
#13 0x00007ffff35fade4 in QCoreApplication::exec() () at /usr/lib/
#14 0x00000000004750aa in main ()

That looks like something that should be reported to the bugtracker. Normally it should be the original ownCloud-client bugtracker if you can reproduce this with the original sources as well.