device id change after OS upgrade Ubuntu server to 16:04 and other problems

I’ve pushed our server from 12.04 through to 16:04 and found Syncthing did not restart. Documentation of our setup didn’t specify the user, but I’ve started it under what appears to be logical and added the syscontrol .service enable so that it starts and is running. Problem is as our remote NAS tries to connect, it came in with a different device ID than the one we have recorded, and all but one of the shared folders do not show up. Is it expected behaviour to loose the list of folders? Should the remote ID change? Its on a VPN and the IP address is the same, so I assume its the same server. [Update] I initially had a huge number of sync error files, these seem to have gone. [2nd Update]Syncthing became owner of a folder that was more up-to-date than its remote counterpart. When the web-gui is running, there is a huge load on the cpu, 115%-180% on a dual core i3, being its mainly a file server and has no desktop, are there efficiency issues with the gui?

Your upgrade probably nuked syncthings config directory, so it got a new ID, you had to re-add the folders and is now rehashing (scanning) content which is using the CPU.

I have a shared folder and specific user folders (/home/user1 /home/user2… /home/userN ], can I sync them all with one syncthing process? It seems I’m back to setting this one up from scratch now anyway, theres too many errors in the log about permissions and things

Syncthing syncs everything as the user it’s running under, so it can’t sync files of multiple users and allow to users to own the files at the same time.

I do appreciate the reply, but may I respectfully point out a couple of things, and ask another question:

  1. Running updates should not “nuke” anything, specifically settings. Presumably, the version supplied to Ubuntu is being maintained, I hope so. It would be good to parse a users settings, and if the format has changed, bring over and merge the settings to the new upgraded config directory.
  2. As to the user, I admit it was a staff member I don’t have working currently who set up syncthing, I didn’t get good documentation of the setup. But we did get multiple users data syncing from the server to the outlying NAS box. Group permissions in linux should have been enough, but numerous times I’ve had to do an ownership fix. IF syncthing is a member of the group, and all files have group write capability, surely the owner could be left alone during a sync?
  3. If syncthing had root permissions (I’m not saying mine has) would it not sync happily, without needing any permission or file ownership changes?
  1. We don’t nuke anything, we have config migrations that we perform. If you got syncthing from some unofficial source, you can’t blame us for the packager mistakes.
  2. We don’t modify existing files in place. We create new files with a .tmp extension, and then rename on top of the old file, in which case any ownership or whatnot of the previous file becomes a moot point.
  3. It should, unless there is other magic involved, such as ACLs, networked filesystems that do not support something and similar caveats, yet using a crowbar for simple things is never a good idea.

Contents of my sources.list.d include

deb syncthing release

Not sure how you place this, but it looks official to me. No ACL or magic, just a filesystem. As to networking, its a samba share, with no weird authentication, linux usernames. So is there no way, after renaming the tmp file, for it to re-assume ownership?

The issue I was trying to avoid, was having 10 instances of syncthing - it seems like one instance consumes a huge resource, most of it with the GUI. Unless you can point me at a better way to configure ?


Samba shares have ACLs and sometimes cannot store unix permissions, depending on the smb implementation

Do you really care that files stored in smb are owned by each individual user? If no, just run one instance, if yes, then there isn’t an easier way. It’s probably a sign you are using the wrong tool.

This is the official package, but this would not delete anything as part of install.

It sounds like you might have changed the user or home directory Syncthing runs with. That would make it use a new config directory, this new keys and config. Your old keys and config are most likely somewhere - like Audrius says, our upgrades do not delete any of these things.

I had to get syncthing going, and could not contact the person who did the initial setup. I did end up changing the user, as I couldn’t figure out which user, thinking he had made a syncthing user specially, I chose that but clearly missed. I should have asked here first for help with recovering the config. It was just a pain, I did do-release-upgrade and after the upgrade finished, syncthing was NOp. As to the ACL’s, I did the initial Samba setup and know for a fact no ACL’s were used.

Did you delete some users with their home on upgrade ? If yes, the keys & conf are gone… or in a backup (also, maybe the install guy specified a config dir outside any home that may have be wiped on upgrade :frowning: … so maybe a restore from backup will help if the dir was in. If not the guy made a bad joke to you). If no, sorry it is a stupid suggestion, did you search the whole disk from root account for a config.xml file containing the ID string ?

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