Syncthing With Samba Share

Good afternoon,

Hoping someone can shed some light on an issue I am having. I originally installed OpenWrt on an Asus RT-N56U wireless router, setup extroot on a 500GB SSD, and installed syncthing in order to sync files to a folder on the 500GB SSD. This worked fine, other than syncthing would grind to a halt after syncing several files, which would bring down the whole router and require a reboot.

Unfortunately I needed to get this up and running quickly and all the stores nearby are either selling Wifi-6 routers that OpenWrt is not compatible with, or super low spec'd devices that would have had the same issue as the RT-N56U.

As a work around, I purchased an Ubiquiti ER-X SFP to run OpenWrt and syncthing on, it doesn't have a USB port, so I figured I would setup a share on the RT-N56U, mount that to a folder on the ER-X and point syncthing at that folder. But I am having permission issues.

Here is the setup I have:
RT-N56U:

  • IP address: 192.168.1.3
  • Samba server configured for guest access
  • Samba share is /mnt/sda1/

ER-X SFP:

  • IP address: 192.168.1.1
  • Using rc.local to mount the samba share to /root/Share
  • Syncthing syncing from remote computer to /root/Share/Syncthing

On a windows computer I can access the share at 192.168.1.3 and read/write without issues.
If I SSH into 192.168.1.1 and create a new file at /root/Share I can create the file without issue. I can also delete / modify existing files that were created from the Windows computer.

Syncthing however gives me a permission denied error when trying to add the share to /root/Share/Syncthing saying it doesn't have permission to create the folder.

The Syncthing process is running as root.

I'm not worried about security as this is an air-gapped system with the wireless capabilities of the RT-N56U turned off, so running everything as root / with 770 permissions is not a concern. That being said, I know it is not best practice, I was just trying to get this up and running quickly. If someone has a decent writeup on how to get this working correctly while running syncthing as its own user while syncing to a samba mount I would be interested.

Thanks!

Samba 4 alone is already tight on 128MB ram.
But syncthing: no way with 128MB RAM according to what their forum says. Your hanging system seems to confirm it.

  • have you tried ksmbd as samba alternative? Less RAM usage, less flash usage. Though less features either. But often sufficient in home usage.
  • I would suggest rsync and ssh for filesyncing, depending on the number of files, you might be able to do this with 128MB.

Thanks for the response!

Maybe I wasn't clear in the initial post, but Syncthing is no longer running on the device with 128mb of ram, I have switched it to the Ubiquiti edgerouter with 256mb of ram. From a test directory (not writing to the samba share) it seems to work okay performance wise.

The Samba server/share is on the device with 128mb of ram, so far performance seems okay if I copy a bunch of files from a windows machine to it. But if it becomes an issue I can see if ksmbd resolves that.

The biggest issue is Syncthing (running as root) cannot write to the samba share, yet if I SSH as root into the device that Syncthing is running on, I can write to the samba share without issue.

I know it's a pretty cobbled together solution to use multiple devices like this, but as mentioned there is nothing OpenWrt compatible around locally that has a USB port and 256mb or more of ram, otherwise I would just run syncthing and not rely on a separate device with Samba at all.

Maybe there is a way to oursource the ram usage of Syncthing to the SSD.
I would not know exactly how, but I have read some related posts in the Syncthing forum. You might want to share your post there and ask for advice from Syncthing maintainers.

With regard to the permission issue, when I tried to find out what you mean with rc.local, i stumpled upon this stack exchange topic: https://unix.stackexchange.com/questions/471824/what-is-the-correct-substitute-for-rc-local-in-systemd-instead-of-re-creating-rc

" There are some considerations that I think also applied to pre-systemd rc.local:

  1. You need to make sure your commands are not conflicting with another program that tries to control the same thing.
  2. It is best not to start long-running programs aka daemons from rc.local."

rc.local seems to be obsolete since 1983 and replaced by systemd or something else.

I don't believe rc.local is causing the permission issue, i'm merely using it to mount the samba share. Which once mounted I can modify the share without permission issues from a terminal session. It's just syncthing which is having the permission issues.

Also, i'm using rc.local because I wasn't able to get the samba share to mount using fstab, which seems to be a common problem with OpenWrt, one work around I saw suggested was to use rc.local which seems to work fine.

try „map to guest=never“:
maybe syncthing has userid or password wrong and then gets automapped to guest with readonly permissions.

can you also create a folder in the root node without issues?

Got it fixed, thanks for the help.
Turns out it was a syncthing configuration issue...
in /etc/init.d/syncthing I had the user set as root, however in /etc/config/syncthing I had it overriding to run as user syncthing.

I distinctly remember seeing syncthing running as root in the processes tab of the web-ui, but I must have changed it to a separate user at one point and forgot to update everything else accordingly. Doh!

Edit: As far as performance goes, when it is scanning for file changes the edge router uses about 90% of its 256mb of ram, during actual file syncing this drops down to around 70%.
On the Asus router with 128mb of ram i'm seeing about 90% memory usage when scanning the files and during syncing. Speed is...not great, about 1.5Mib/s, however the initial sync is ~7GB and then after that it will drop to a handful of MB per day, typically I would say around 5MB. So this is acceptable.

1 Like

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