Photo sync to Nextcloud set to one-way

Bug Reports
1

REPRODUCIBILITY: 100%
OS VERSION: 5.2.0.16
HARDWARE: Jolla Phone (2026), jp2601
UI LANGUAGE: Finnish (not language-dependent)
REGRESSION: N/A, new device, no earlier release to compare against

DESCRIPTION:

Photos taken with the camera are never uploaded to the Nextcloud account’s Images service. Sync runs and succeeds, but only ever reads the remote /Photos folder. Nothing is sent from the device.

The sync profile on the device declares the service as two-way:

$ grep -i direction ~/.local/share/system/privileged/msyncd/sync/nextcloud.Images-2.xml
<key name="Sync Direction" value="two-way"/>

but the shipped template it was created from declares one-way:

$ grep -i direction /etc/buteo/profiles/sync/nextcloud.Images.xml
<key value="one-way" name="Sync Direction"/>

Observed behaviour matches the template, not the profile. So either the profile is wrong, or the plugin ignores the field. Either way the two disagree.

Separately, and regardless of direction, nothing in Settings > Accounts indicates that Images is download-only. The service is presented as a simple on/off toggle, which reasonably reads as “keep my photos in sync”.

PRECONDITIONS:

A Nextcloud account configured with the Images service enabled.

STEPS TO REPRODUCE:

  1. Settings > Accounts > Nextcloud, enable Images.
  2. Take a photo with the camera.
  3. Trigger a sync, or wait for the scheduled one.
  4. Check the Photos folder on the Nextcloud server.

EXPECTED RESULT:

Either the photo appears on the server, matching the two-way direction the profile declares, or, if the service is intentionally download-only, the UI says so and the profile declares one-way.

ACTUAL RESULT:

The photo is not uploaded. Sync completes successfully having only listed the remote folder. The UI gives no indication that upload is not part of the service.

MODIFICATIONS:

Developer mode enabled. Storeman and Chum installed with community packages (File Browser, Patchmanager, Situations, harbour-owncloud). Android App Support in use. None of these affect the finding, the profile and template files quoted above are stock.

ADDITIONAL INFORMATION:

Sync log confirms the service runs and reaches the server. A manual sync produced a successful PROPFIND on /Photos returning HTTP 200, against Nextcloud 33.0.8. No upload request follows.

Also worth noting, though possibly a separate issue: the scheduled hourly syncs failed repeatedly before that manual run.

$ cat ~/.local/share/system/privileged/msyncd/sync/logs/nextcloud.Images-2.log.xml
<syncresults scheduled="true" time="2026-08-26T14:54:13Z" majorcode="0" minorcode="0"/>
<syncresults scheduled="true" time="2026-08-26T18:59:09" majorcode="1" minorcode="602"/>
<syncresults scheduled="true" time="2026-08-26T19:49:09" majorcode="1" minorcode="602"/>
<syncresults scheduled="true" time="2026-08-26T20:49:08" majorcode="1" minorcode="602"/>
<syncresults scheduled="true" time="2026-08-26T21:49:10" majorcode="1" minorcode="601"/>

The reason isn’t recoverable, the journal is volatile and those entries were lost at reboot.

The profile also carries sync_since_days_past = 30, so only the last 30 days are ever considered, which is worth documenting somewhere user-visible too.

1 Like
2

Photos taken with the camera are never uploaded to the Nextcloud account’s Images service. Sync runs and succeeds, but only ever reads the remote /Photos folder. Nothing is sent from the device.

Either the photo appears on the server, matching the two-way direction the profile declares, or, if the service is intentionally download-only, the UI says so and the profile declares one-way.

The nextcloud integration simply does not have the feature of up-sync, or uploading any files, apart from the “Share with” integration.

Therefore this is not a bug, except maybe the thing with the disagreeing profiles.

The Nextcloud integration is Open Source, and its code is available here:

so someone from the community can implement this feature if there’s a need.

1 Like
3

Nextcloud account integration in SFOS has always been limited to contacts and calendar synchronization. There is no generic file sync built into the OS.

The images option in the account settings is rather useless since it shows some thumbnails of Nextcloud imges in SFOS gallery, nothing more.

If you want true bi-directional file sync, use one of the native apps or, as a much more flexible solution, install and configure rclone.

4

I think its interesting that it’s implemented to sync from Nextclould to phone only. To me it would make more sense the other way, as a way of backing up photos in case the phone is lost etc. So I agree that Images-option in account settings is rather useless when built this way.

5

I on other hand find this more important! I appreciate that I can easily natively see all my tens of thousands of pictures and videos :slight_smile: Would love if that sync would be 2-way, but Ferry sync fulfils that currently

2 Likes
6

For viewing Nextcloud images on mobile devices, my solution is to populate my Nextcloud photo folder as a remote library in Immich (running in a docker container alongside with Nextcloud).

The native SFOS Immich app is very fast, comparable to the stock gallery app browsing local images. In addition, it is able to utilize the powerful face recognition and context search Immich offers. No need to store image files on a mobile device.

1 Like
7

Immich sounds great, unfortunately I’m not self-hosting and my cloud provider doesn’t offer it so it’s out of the question for me. But I set up rclone and it seems to do the trick for now.

8

Worth noting for the thread: nextcloud-images doesn’t transfer files at all — it PROPFINDs the remote tree and stores metadata (fileName, etag, thumbnailUrl) in Images/nextcloud.db, and the gallery-extension-nextcloud fetches the actual image through ImageCache when a photo is opened.

The upload primitives already exist in buteo-common (upload(), dirListing(), dirCreation()), used by the backup plugin. Some questions arose:

  1. Separate plugin as with backups sharing nextcloud-images.service, or extend the existing images plugin?

  2. Was the images plugin being index-only — nothing uploaded — a deliberate scoping decision, or just where the work stopped?

  3. Would a stateless diff — PROPFIND the remote folder, compare against the camera roll, upload what’s missing — be acceptable for a first version, or should it record uploads in ImageDatabase from the start?

1 Like
9

Maybe you should ask these questions in this issue?

10

Thanks, that might be best, although I don’t have a github account now handy. But I intended those questions as a bridge to make it easier to pick up work and in that sense the repo itself would be the right place to ask them.