I’m having an issue with the offline synchronization workflow using QFieldSync (cable sync).
The Workflow:
Exported a project with GeoPackage layers (Action: Offline editing).
Collected new data in the field using QField.
Copied the project folder back to the PC.
Used “Synchronize from folder” in QGIS.
The Issue:
The synchronization process seems to finish successfully without any error messages. The media/photos are correctly synchronized to the project folder. However, the newly recorded features do not appear in the master GeoPackage layer in QGIS. The attribute table remains unchanged.
System info:
QGIS version: [3.44.10-Solothurn]
QFieldsync version: [4.21.1]
OS: Ubuntu 24.04.4 LTS
Has anyone experienced this “silent failure” where the sync process looks okay but no data is actually written back to the original file?
Any advice on where to look for the logs or what might be blocking the data update?
Hello! Can you check that the GeoPackage that you copied from the field device contains the added features? For example, by using a program like “DB Browser for SQLite” to see inside the contents of the file directly without relying on QGIS and QField.
If the file does contain the changes, can you double check that, after importing the copied files from the <user home directory>/Qfield/Import with QFieldSync, that you are opening the project from <user home directory>/Qfield/Exportfolder without getting changes?
Hi!
Could it be that I am not using the specified export/import directory?
I created a project directory. I also use a private directory to export the package. After the survey, I overwrite the contents of this directory with the data copied back from the mobile device. Then I synchronized from this directory. Is this not the correct workflow? What would be the official workflow in case of cable data transfer?
By the way, among the files from the mobile device there is a data.gpkg file. This contains my survey data. But the original Geopackage file, in which the data should be stored, does not contain them.
I don’t think it might be related with the specific directory necessarily. At least in the sense that it shouldn’t be needed to used specifically the QField/export and QField/import folders; but I would recommend to use them (at least while we figure out what the problem might be) since they are the default options. I wouldn’t recommend using, for example, a sub-folder inside of your project’s folder.
On this link there is the most official guide I’ve found on how to use the cable transfers. It pretty much describes the same that you do, but there might be missing some details that at least to me where vital in avoiding as much problems as possible (I’m not sure how much they are needed now). Maybe you can try some of these to see if it works for you:
Prefer using .qgs files (not the default .qgz).
Use an Export folder external to you project’s folder on where to store the packaged project to be copied TO QField. I prefer to use the default <user home>/QField/export.
Copy files by connecting the mobile device by wire, preferably an Android device. The destination folder is usually only accessible when navigating from the PC (you can check the typical location on the link above). This packaged project typically contains the data.gpkg file you mentioned; I believe this is just how QField “packages” the information on your project to be used on the mobile device, so don’t delete or modify anything from this project, copy it as is.
On QField, open the project from the Imported Projects folder. If for any reason you opened the project from any other folder, such as the phone’s Download folder, QField would first copy the project to its internal Imported Projects folder.
After the field work, connect the mobile device to the PC via USB and copy the whole project folder inside of QField’s Imported Projects folder. This project with the new field data should be copied onto an Import folder on your PC located outside of your main project’s folder and outside of your Export folder. I prefer to use the default <user home>/QField/import.
What’s probably more “out there”… I then open on QGIS the project in the Export folder, not the original project. With that “packaged” project open, I then use the synchronisation function of QFieldSync to bring the changes from the version located on the Import folder. The result should be that the project in the Export folder now contains the changes of the version on the Import folder. From that point, I then choose how to keep working with the data on the PC, essentially using this version from the Export folder as a staging version to see how to work with the data. Sometimes I might want to integrate the data to the original project, or maybe the original project is just a sort of template for creating “surveying snippets” to upload to a server (think of it as just sending a geopackage with the new information an letting a remote server deal with integrating that data with all the other data that it already has).
The general logic is to think as the projects in the Export and Import folders as “How QField prefers to work with my project”, and storing the “mobile version” on the Import folder and the “PC version” on the Export folder. The original version of the project, more often than not, is just a template from which to start a “surveying project” that typically is a subset of a whole “proper” project on QGIS.
But every time that you have to make a new field work, you have to export/package a new version of the project, which would be located on the previously mentioned Export folder. For this reason, a typical export folder name would be, for example, beehives-checking_Location-A_2026-05-13, followed by beehives-checking_Location-A_2026-05-14, etc. etc.
Although Cuprico has given a very nice and detailed workflow, I do like to add that I am not convinced the last step is the best solution.
In the link Cuprico provided, the last step in which to update the QGIS project with the changes from the Import folder, I find the documentation ambiguous.
However, it is not made explicitly clear which project is meant here: the original QGIS project? Or the QField project which was created in your Export folder?
Cuprico explains to use the QField project created in the Export folder and provides a strong logic why to do so. This logic does apply to the QFieldCloud synchronisation, but I am not sure it applies equally to the Cable export synchronisation.
And my uncertainty is based on the Attention block at the end of the online documentation:
This attention block suggests, in my opinion, that the synchronization from the Import folder is done to the original QGIS folder, not the Export folder. If synchronization is done to the Export folder, there would be no need to “create a new QField package” before the next field collection run and this Attention block would be useless.
great points @Jeroen-GroeneBij , and I tend to agree. The more I read the docs, the more it seams that the “official” workflow is to just keep working with the original project on the PC, not with the one generated on the export folder. I almost exclusively use the cable transfer method and not QFieldCloud, other than for tests and demonstrations.
It’s being a couple or years since I’ve started using QField, so I’m not sure how much has changed since. One thing I remember is that sometimes I had problems with the photo attachments, where even the DCIM folder would be created on the original project, but the files wouldn’t be transferred. They would be copied only to the export folder. That problem might have been related with either using a .qgz file, or the path of the actual project having spaces or some nasty characters, but in any case the general experience was that things were more reliable when working with the export folder.
I usually am not the actual person that goes to make the survey, so I have to set things up and need to then explain the procedures to other teammates that are less prone to experiment and problem solve, so I tend towards what feels like the most straight forward solution (no “if this, then that…” kind of explanations). The .qgs vs .qgz thing is something I swear to have seen in the docs, but I cannot find it now, so it might as well just be my imagination.
To me the ambiguity of the attention blocks might be more prominent only if you assume that working with the export project is expected behaviour for the devs. But reading carefully the current version, it gives me the impression that it is not the case (no longer, maybe?). To me, the whole read makes more sense if you only assume to work with your original project. Except of course for which folders you copy onto and from your mobile device; that is, (if I understand correctly) you should always copy to the mobile device the latest project in the export folder, and you should never just directly overwrite by copy & paste your original project with the one coming from the phone (you should copy it to an import folder and use QFieldSync to bring the changes).
Thank you for the detailed discussion. I have now tested both of your suggested workflows to pinpoint the issue. Unfortunately, the result is the same in both cases: the synchronization finishes without any error messages, but the new features are not transferred.
Here is exactly what I did:
Scenario A (Jeroen’s workflow):
Exported the project from my Master project to a dedicated /Export folder.
Copied the package to the tablet, collected new points.
Copied the data back from the tablet to a dedicated /Import folder.
Opened the Master project in QGIS and ran “Synchronize from folder” pointing to the /Import folder.
Result: Sync finished successfully (no errors), but the new points were NOT added to the Master GeoPackage.
Scenario B (Cuprico’s workflow):
Used the same /Import data from the tablet.
Opened the Project file located in the /Export folder (the packaged version).
Ran “Synchronize from folder” pointing to the /Import folder.
Result: Again, it finished without errors, but the new features did not appear in the Export project’s layers either.
Crucial Observation: I manually checked the data.gpkg inside the /Import folder using a browser, and the new test points are definitely there. The data exists in the offline file, but QFieldSync simply refuses to “see” or “pull” them during the synchronization process, regardless of which project file I use as the target.
As I mentioned before, I noticed that in the tablet’s data.gpkg, my original fid field was renamed to fid_1, and a new fid field was created with NULL values. Could this “silent failure” be caused by the sync engine’s inability to map these fields back to the Master/Export layer, even though it reports a successful sync?
What could be blocking the transfer if the plugin doesn’t report any errors?
Hi Attila. I sympathise with your plight. I too frequently have issues with QFieldSync.
A suggestion. Open the project in the /Import folder, and:
(1) check you can see the features.
(2) check the source of the feature layer is pointing to the correct gpkg in the /Import folder.
If the matter persists, I would just copy them manually across and hope it works next time. Tracking down the cause is very difficult, and unless its reproducible it won’t get investigated by QFieldCloud.
In my experience, it could be a seemingly unrelated error in your project, such as: invalid geometries, or an expression (symbology or default value) that returns an invalid value for its use (perhaps only in edge cases).
I also see the additional fid_1 field and the original fid, it is probably new behaviour in later QFieldSync versions?
However, for me it still works.
When I have copied the device folder to the Import folder, I can inspect the geopackage using the QGIS browser panel.
The fid_1 field is the newly added one (it is not the renamed old one) and should be completely filled, nicely numbered starting at 1
The fid field is your original fid field from the master gpkg and should have NULL for each new feature.
After synchronizing, the fid field in the master gpkg is filled correctly.
Have you tried completely removing the project from your device using the QField interface? And then adding it completely new?
