Not able to sync home folder

I am using ST between several computers. All syncing is done via a central server, that is, no computer talks directly to any other computer except the server.

Recently I decided to add my home folder on a Ubuntu 16.04 machine to be synced. As always, the initial scenario was to send-only to the server, where, once that was complete, it could be synced to other computers as extra redundant copies (never to replicate the home folder as a working home folder onto different machine).

What I’m finding is that nothing ever gets transferred to the server. The home folder gets scanned on the sending side, and the it will say “Syncing x%, xxGiB”, but transfer rates, both up and down, will remain stubbornly at 0bps.

This problem seems only to affect the home folder share. On this machine there are 3 other shares, and they all sync fine. The only time the bitrate will leave 0 is when something gets updated that affects one of the other shares.

Is there something I’m missing? Although I get the warning about possible problems with syncing the ST config, I ignore it since i know the location on the other side is not part of that machine’s ST config.

I’m hoping somebody here may say or ask something that will shed some light on this oddity.

Best Regards, RichardP

No out of sync files in the folder view? Anything interesting in the logs?

I haven’t yet set the server to enable debugging (the server is the receiving side). On the sender side there’s nothing untoward.

Actually, now that you asked about out of sync files, I just realized I haven’t shared a crucial piece of info - what is waiting to be synced is not the files (in the Home folder), but rather the file list, from the Remote Devices list. The upshot is that there are no out-of-sync files, because the receiving side hasn’t yet received a list of files that it can start to pull.

The sender device just sits displaying an almost-complete progress bar that says “Syncing (98%, 45.3 GiB)”

Curious!

That definitely sounds weird (I am honestly not a 100% that I understand your description correctly). Screenshots and/or logs would probably share some light on this.

You’re right. A pictures worth…

Does the other side also have the folder in question, and does it share it with this device? Does the other side have ignore patterns? Those are the typical reasons files would not be transferred (not being shared, or matching ignore patterns).

It does. It was added to the other side by responding to the prompt that comes up when the share is created on this side.

No ignore patterns on the other side - the other side has an empty folder (that ST created when the share was created), with just the .stfolder file in it. Permissions seem to be exactly what I would expect, and owned by the ST user. This applies to the parent folders as well.

This side does have ignore patterns (only put there to see if any files were causing this problem), and changing them doesn’t change anything. The intention, when everything is sorted out, is not to have anything excluded.

Could you provide a screenshot of both sides with the folder in question expanded.

Hopefully this is not too big. This one is my Server, which is the receiver in this case. Still empty, as the other side hasn’t sent anything yet.

Below is my desktop, which is (not) sending. The actual folder is my home directory, so wondering this has any bearing on it. There are exclusions here, but removing them or changing them has no effect on the issue.

the folder ID is different on the devices, they need to be the same (u2d… on the server and qzr… on the desktop). Delete the folder on the server and add it again with the ID that the desktop has for this folder.

3 Likes

That was it. I’m at a loss to understand how that happened, since I added it on the receiving side by sharing on the other side then responding to the offer to add in. After deleting the folder on the receiving side, then re-adding it with the same folder ID, the transfer started up pretty soon after.

Thanks for the sharp eyes, and the time, Alex and everyone who took the time to look over the issue.

Best Regards, Richard.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.