Replacing a drive and keeping the same path

[hamradio]

Hi, I’m replacing a failed hard drive which contained all of my Syncthing shared folders. Being on Linux, in my system the drive was referred to as /mnt/nas, which was a symlink to /mnt/olddrive while now /mnt/nas will be a symlink to /mnt/newdrive. Actually my config.xml file contains entries like path=“/mnt/nas/sync/doc” and so on. While replacing the drive I’ve stopped Syncthing, which is started in the user’s crontab, so I’m wondering if when the new disk will be in place and symlinked to /mnt/nas, will I need to do something in Syncthing configuration (e.g. deleting and readding shares as I’ve read in other posts regarding the replacement of a failed drive)? Thank you in advance for your answer…

[mopani]

If you recreate the paths, the .stfolder marker will not be present so Syncthing will stop those folders. If you manually add the .stfolder marker Syncthing will conclude that all the files have been deleted and proceed accordingly – deleting all the files on the other side is presumably not what you desire!

The best and safest method is to, first, make sure the files on the other side are backed up (!), then, remove those folders from Syncthing on this device. The other device(s) will then try to share them, you can accept the folders, and it should discover them empty and proceed to transfer all the files.

[gadget]

Hi hamradio,

Yes, if after the drive replacement and updated symlink (/mnt/nas → /mnt/newdrive), the old directory paths (e.g., /mnt/nas/sync/doc) are still valid, then your existing Syncthing configuration is fine and doesn’t require any changes.

If I may offer a quick tip…

Instead of a symlink, consider using a “bind mount”.

Bind mounts allow remounting a subdirectory of an existing mounted drive to its own mount point.

For example, the following command would temporarily bind mount /mnt/newdrive to /mnt/nas:

mount --bind /mnt/newdrive /mnt/nas

At first glance, there won’t appear to be any functional difference between /mnt/nas being a bind mount instead of a symlink.

As far as Syncthing is concerned, /mnt/nas/sync/doc is the same directory either way. However, other tools might give different results. For example, if you wanted to copy /mnt/nas to another drive using rsync:

rsync -a /mnt/nas /mnt/usbdrive/

• If /mnt/nas is a symlink, it will be copied as-is to /mnt/usbdrive – i.e., there will just be a symlink named “nas” under /mnt/usbdrive.
• If /mnt/nas is a bind mount, “nas” plus all of its contents will be copied to /mnt/usbdrive.

In order to get the same result with a symlink, the rsync command would need to be told to first follow the symlink, then start copying (note the addition of a forward slash in the pathname /mnt/nas/):

rsync -a /mnt/nas/ /mnt/usbdrive/

Bind mounts are treated the same as any other mounted drive so there are no different behaviors between programs.

/etc/fstab entry to bind mount at boot time:

/mnt/newdrive    /mnt/nas    none    bind 0 0

[tomasz86]

@mopani

If you recreate the paths, the .stfolder marker will not be present so Syncthing will stop those folders. If you manually add the .stfolder marker Syncthing will conclude that all the files have been deleted and proceed accordingly – deleting all the files on the other side is presumably not what you desire!

The best and safest method is to, first, make sure the files on the other side are backed up (!), then, remove those folders from Syncthing on this device. The other device(s) will then try to share them, you can accept the folders, and it should discover them empty and proceed to transfer all the files.

That’s true, although if there are a lot of folders and you don’t feel like re-configuring everything from scratch, you may also change all of them to “Receive Only”, then recreate .stfolder manually, then use the “Revert Local Additions” button to re-download all their content. Once all is done, you can change their folder type back to what it used to be.