Syncthing + Windows ACL = Wrong user group? On new files?

[m3ki]

I feel really dumb and cant figure this issue out.

I have installed syncthing plugin.
When I login to my jail I can see the following:

• Syncthing is running as syncthing user.
• Default/primary group for syncthing user is syncthing.
• I map a datastore(all datastores are windows ACL) so syncthing can access it.

Above is all good but the problem is ANY file created by the syncthing user is owned by syncthing:wheel.

I assumed that all files should be created as syncthing:syncthing not syncthing:wheel.

Is there something I am missing?

Please help this has been driving me nuts past 6 hours.

 

[Joshua Parker Ruehlig]

looking at the upstream init file it should be have the group syncthing.

can you compare your /usr/local/etc/rc.d/syncthing to this one?
https://github.com/freebsd/freebsd-ports/blob/master/net/syncthing/files/syncthing.in

 

[m3ki]

Here are the contents of the file, seems like the group is syncthing:

Code:

root@syncthing_1:/ # cat /usr/local/etc/rc.d/syncthing
#!/bin/sh

# $FreeBSD: head/net/syncthing/files/syncthing.in 383386 2015-04-05 22:20:52Z swills $
#
# PROVIDE: syncthing
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf.local or /etc/rc.conf
# to enable this service:
#
# syncthing_enable (bool):      Set to NO by default.
#                               Set it to YES to enable syncthing.
# syncthing_user (user):        Set user to run syncthing.
#                               Default is "syncthing".
# syncthing_group (group):      Set group to run syncthing.
#                               Default is "syncthing".
# syncthing_dir (dir):          Set dir to run syncthing in.
#                               Default is "/var/db/syncthing".

. /etc/rc.subr

name=syncthing
rcvar=syncthing_enable

load_rc_config $name

: ${syncthing_enable:="NO"}
: ${syncthing_user:="syncthing"}
: ${syncthing_group:="syncthing"}
: ${syncthing_dir:="/var/db/syncthing"}

pidfile=/var/run/syncthing.pid
procname="/usr/pbi/syncthing-amd64/bin/ST/syncthing"
command="/usr/sbin/daemon"
command_args="-f -p ${pidfile} ${procname} -home=${syncthing_dir} -no-browser ${syncthing_args}"

start_precmd=syncthing_startprecmd

syncthing_startprecmd()
{
        if [ ! -e ${pidfile} ]; then
                install -o ${syncthing_user} -g ${syncthing_group} /dev/null ${pidfile};
        fi

        if [ ! -d ${syncthing_dir} ]; then
                install -d -o ${syncthing_user} -g ${syncthing_group} ${syncthing_dir}
        fi

}

 

[m3ki]

I don't think it is a syncthing issue thought.

When I become syncthing user and touch a file it is created as syncthing:wheel in every folder except /var/db/syncthing

 

[Joshua Parker Ruehlig]

Maybe when files are written the inherit the group from their above directory.
Maybe you can do this so future files inherit the syncthing group

Code:

chown -R syncthing:synchting /path/to/folder

 

[m3ki]

In the docs freenas team says don't screw with permissions if using windows acl. I wonder if someone from freenas team can comment.

Sent from my Nexus 6P using Tapatalk

 

[m3ki]

Jeesus,

I was "touching" some files inside a dataset trying to see what I can do to to make syncthing to create files as a syncthing:syncthing and restarted a jail then got a crash!! a freaking kernel panic! You kidding me?

I don't think I wanna play around with jails anymore. If simply restarting a jail can do this?

I should probably wait till freenas 10 comes out with docker. So much for running syncthing on a freenas.

:(

 

[pirateghost]

I've never seen a jail restart cause a kernel panic. Sounds like you have deeper issues there.

 

[m3ki]

system has been running solid for the most of the year. And has been burned in. I'm doubt it's anything else but jail. I know I had this happen yesterday too. Whole thing froze when I changed jail ip to static. So I gave up on that and set up on the router. It's probably something to do with that. I can provide a dump file. The whole jail this is pain to be honest. I much prefer docker implementation.

Sent from my Nexus 6P using Tapatalk

 

[pirateghost]

I have 12 jails running at any given time and spin up new ones for testing things all the time...I've never had an issue like you describe.

 

[m3ki]

Are you by any chance using LACP?

to be honest I'm kind of giving up on running syncthing on freenas. Thank God Plex is working. :)

I will just run it in a docker on another server and let freenas be a NAS, till 10 comes out.

Sent from my Nexus 6P using Tapatalk

 

[pirateghost]

I have no use for LACP in a home environment. Even as complicated as my home environment is...

 

[m3ki]

It's been beneficial in my environment(surprisingly) I'm am saturating both down and up links to my nas. I have multiple clients dumping stuff to nas as well others downloading stuff off it. And off site backups.

Sent from my Nexus 6P using Tapatalk

 

[pirateghost]

Unless you have a lot of clients, LACP doesn't do anything for you. You can saturate both up and down links without LACP. Do you understand how LACP works?

 

[m3ki]

I do, and I do have multiple clients with managed switches setup with link aggregation (LACP) all gigabit.
But I think we are getting a bit off topic :)

I'll try to do more troubleshooting later, looking at the dump. Im not at home now.

 

[Joshua Parker Ruehlig]

i had a freenas system that exoeriemced crashes from different random things. found out it was bad RAM that failed memtest.

on my other freenas systems I never have experienced crashes and i create and destroy several jails daily while building/testing plugins. also I do use LAGG interfaces, though not LACP specifically.

 

[m3ki]

Does ram go bad? I did test it for 48 hours when the system was built. And I did run unraid on it for a year before I switched to freenas. It's also ECC.

Sent from my Nexus 6P using Tapatalk

 

[Joshua Parker Ruehlig]

I'm not sure, but I dont think so.

 

[pirateghost]

Yes. RAM can go bad

 

[m3ki]

Thank you for your inoit.
I guess I'll do another ram test :)
It would be a nice surprise since I had no outages and I'm on a good ups.

Sent from my Nexus 6P using Tapatalk