No marker folders (Linux/TrueNAS)

[cal3k]

I’m testing syncthing as an alternative for syncback and so far is not looking that great. Every time I reboot the VM hosting syncthing (TrueNAS Scale running on Proxmox) all the shared folders show Stopped, with the error message: “folder marker missing (this indicates potential data loss, search docs/forum to get information about how to proceed)”

Synching is installed in a jail in TrueNAS the app is installed under a user that has root access pretty much anywhere so it’s not an issue of permissions. If I manually create the folder (and chown it to the user) it does not help at all. I’ve also noticed when I first create a folder that .stfolder is not always created, not to mention that I saw it create something like 6C409300 for at least one folder. Even when it does make the .stfolder and is still there after reboot I still get the same error.

All shares point to various /mnt/NASX/NX/xxx, where xxx=various data shares. The same user that owns the app is the one I use to access the SMBs from other machines so I know for sure it has proper permissions.

What am I missing? Re-adding many folders, including one with several TB every time it reboots is not an option.

There seem to be plenty of posts like this but none with a proper solution that worked for me.

LE: The permissions were set to 770 on both the syncthing folder as well as the shared folders. Changed them to 775, same result

[gadget]

I have to ask so that I know what point of reference we’re working from, so that I know what can be skimmed over and what needs a lot of explanation – how comfortable are you with Promox Virtual Environment (PVE), TrueNAS, SMB plus everything else currently being used in your setup?

A few missing details:

• Where/what is hosting the /mnt/NASX/NX/xxx mount points?
• Syncthing is inside a FreeBSD Jail, which doesn’t allow direct mounting of external filesystems, so how is Syncthing accessing /mnt/NASX/NX/xxx?
• What’s serving those SMB shares?
• If it’s Samba serving the SMB shares to other machines on the network, how is Samba accessing /mnt/NASX/NX/xxx?

Setting the permission bits to 770 will only help if Syncthing belongs to the same group as the user who owns /mnt/NASX/NX/xxx.

Setting it to 775 doesn’t really improve much because ‘5’ is granting read/execute to other users. If Syncthing is the other user, it won’t be able to create its .stfolder marker.

I’m curious as to why replace SyncBack with Syncthing?

My first thought was that there’s a whole lot going on with a combination of Syncthing + SMB file shares + container(s) inside virtual machine(s) on top of hypervisor(s) + probably 3 different operating systems in play – perhaps it’s a bit too much to tackle all at the same time.

There aren’t many (if any) folks on this forum who have a setup similar to yours, so it’s likely why no earlier solutions worked. For sure, there are plenty who are using Syncthing on TrueNAS along with others running PVE, Docker, Samba and so on, but I don’t recall anyone combining it all.

[cal3k]

Hi there thanks for the reply.

/mnt/NAS1/N1 & /mnt/NAS2/N2 are 2 ZFS pools created within Truenas (proxmox passthrough drives), with N1 & N2 being the main datasets, each with multiple child datasets (some of them acting as SMB shares).

I am using Truenas Scale which is built on Debian (Ubuntu?), not FreeBSD (that’s Truenas Core). It seems to be running as part of a kubernetes pod. Honestly, I’m not familiar with kubernetes, had to learn how to access the pod directly to change the Syncthing certificate, but that worked nicely. From what I’ve seen Truenas asks for a user/group when installing the Synthing. The user I used to create it is the owner of the mount points, so even a 700 permission set should have worked. It’s the exact user that I use on other machines to access (full access) the SMB shares created by Truenas.

I did install Synchthing on another server directly on proxmox and there it does work nicely. That one manages directly the ZFS pools. On the one that’s causing me issues, however, proxmox just passes a bunch of drives to Truenas, which manages ZFS, hence the reason I’m trying to install it on Truenas and not as another VM or part of proxmox itself.

To be honest, running Truenas on Proxmox as a home NAS is not that uncommon I’m just looking for a solution that would allow Linux to Linux file sync without having to keep my daily laptop (windows ) on, as I’m doing with Syncback, basically sync/backup 2 Linux servers via windows >.<

[calmh (Jakob Borg)]

I didn’t read all details, but TrueNAS runs Syncthing as a container so you need to map volumes into the container for it to be able to access outside files. I didn’t see this obviously mentioned somewhere.

[cal3k]

This is the setup used, where both the user and the group used have full permissions to the entire paths, not exactly sure how I’d even mount or do a passthrough of the path inside the pod.

[calmh (Jakob Borg)]

I think you want the “extra host path volumes” at the bottom of the first screenshot.

[cal3k]

I’ll give that a shot. I used this as a reference and paid attention to that part. But things have changed since the video was out. How To Setup TrueNAS Scale Apps With Shares For Host Path Volumes - YouTube

[cal3k]

Love you man This seems to have done the trick

After you do that it shows inside the pod’s mount point

If anyone stumbles upon this you can do the following to check (in truenas scale cli) (list the pods) #k3s kubectl get -n ix-syncthing pods
(access synthings pod cli) k3s kubectl exec -n ix-sy)ncthing --stdin --tty syncthing-xxxxx – /bin/sh

and now the new folder should be mounted within the pod’s /mnt

now to figure why I’m getting this, it’s like it’s mounted without -R permissions, fun lol

Out of sync as it is but at least it keeps the status past truenas reset

[cal3k]

sorted, had to mark that one to ignore permissions