SOLVED Trying to make a Samba share to the Syncthing folder

[NumberSix]

Hi
I have successfully set up the Syncthing plugin and verified that everything works as it should. Then I set up a Samba share to windows 10, which when I try to open it, says Windows cannot access it. I have a couple of other Samba shares to other datasets that work fine, I just can't access this one.

The user and group is called Sync. As no one but me uses this system I set up an ACL which uses Basic permissions, Full Control, Inhereted to owner@, group@ and everyone@ And the whole thing is recursive. Yet nothing works. I have a funny feeling that this Samba share DID work at one point, but no longer, for reasons unknown.

I am quite desperate for help to fix this. I came new to TrueNAS a few months ago and have invested many hundreds of hours trying to learn how to use it. It's so fiendishly complicated that it often feels like one step forward, four or five back. Sometimes I think about packing it in and buying a Synology. Life is too short to spend days (and days and days and days) trying to do something that should be as simple as accessing my Syncthing folder.

Can anyone tell me how to fix this please? No pithy comments please, just a 'how to' to gain acess to the Samba share from anyone kind enough to share their insight; I'd be so grateful at this point.

Thank you..

 

[anodos]

What is output of testparm -s?

 

[anodos]

Once you get the path for the share, also post getfacl output for each path component. For example, getfacl /mnt/tank/syncthing.

 

[NumberSix]

What is output of testparm -s?

Hi Anodos!
Thank you for your interest in my problem. Here is the result of the first command you asked for:

Code:

root@truenas[~]# testparm -s
Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
Server role: ROLE_STANDALONE

# Global parameters
[global]
        aio max threads = 2
        bind interfaces only = Yes
        disable spoolss = Yes
        dns proxy = No
        enable web service discovery = Yes
        kernel change notify = No
        load printers = No
        logging = file
        max log size = 5120
        nsupdate command = /usr/local/bin/samba-nsupdate -g
        registry shares = Yes
        restrict anonymous = 2
        server role = standalone server
        server string = TrueNAS Server
        unix extensions = No
        idmap config *: range = 90000001-100000000
        idmap config * : backend = tdb
        directory name cache size = 0
        dos filemode = Yes


[NAS]
        comment = Share on mirrored HDDs.
        ea support = No
        kernel share modes = No
        path = /mnt/NAS
        posix locking = No
        read only = No
        vfs objects = streams_xattr shadow_copy_zfs ixnas aio_fbsd
        nfs4:chown = true


[Media]
        comment = Share for Film, Music, TV & Photos.
        ea support = No
        kernel share modes = No
        path = /mnt/NAS/Media
        posix locking = No
        read only = No
        vfs objects = streams_xattr shadow_copy_zfs ixnas aio_fbsd
        nfs4:chown = true

Honestly I confess I don't understand the commands you asked for, nor their results. However I have managed to get the results of the 2nd command you suggested too!

Code:

root@Syncthing:/mnt/Syncthing # getfacl /mnt/Syncthing
# file: /mnt/Syncthing
# owner: syncthing
# group: 1002
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:rwxpDdaARWcCos:fd-----:allow
         everyone@:--------------:fd-----:allow

Thank you again for your assistence on this!!!!

 

[anodos]

Hi Anodos!
Thank you for your interest in my problem. Here is the result of the first command you asked for:

Code:

root@truenas[~]# testparm -s
Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
Server role: ROLE_STANDALONE

# Global parameters
[global]
        aio max threads = 2
        bind interfaces only = Yes
        disable spoolss = Yes
        dns proxy = No
        enable web service discovery = Yes
        kernel change notify = No
        load printers = No
        logging = file
        max log size = 5120
        nsupdate command = /usr/local/bin/samba-nsupdate -g
        registry shares = Yes
        restrict anonymous = 2
        server role = standalone server
        server string = TrueNAS Server
        unix extensions = No
        idmap config *: range = 90000001-100000000
        idmap config * : backend = tdb
        directory name cache size = 0
        dos filemode = Yes


[NAS]
        comment = Share on mirrored HDDs.
        ea support = No
        kernel share modes = No
        path = /mnt/NAS
        posix locking = No
        read only = No
        vfs objects = streams_xattr shadow_copy_zfs ixnas aio_fbsd
        nfs4:chown = true


[Media]
        comment = Share for Film, Music, TV & Photos.
        ea support = No
        kernel share modes = No
        path = /mnt/NAS/Media
        posix locking = No
        read only = No
        vfs objects = streams_xattr shadow_copy_zfs ixnas aio_fbsd
        nfs4:chown = true

Honestly I confess I don't understand the commands you asked for, nor their results. However I have managed to get the results of the 2nd command you suggested too!

Code:

root@Syncthing:/mnt/Syncthing # getfacl /mnt/Syncthing
# file: /mnt/Syncthing
# owner: syncthing
# group: 1002
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:rwxpDdaARWcCos:fd-----:allow
         everyone@:--------------:fd-----:allow

Thank you again for your assistence on this!!!!

To clarify, syncthing is using this entire pool?

 

[NumberSix]

To clarify, syncthing is using this entire pool?

Hi
No. Syncthing has it's own dataset in the NAS pool. Here's a picture of the setup:

I hope this helps.

 

[anodos]

Ah okay. If problem is only with SMB access, open the ACL editor, and edit the ACL on the Syncthing dataset to add an _additional_ group entry for the local group "builtin_users" granting FULL_CONTROL, and apply recursively. Then make sure your SMB user is a member of that group.

This is probably the fastest way to grant SMB access. Do note that it will change on-disk permissions for everything underneath.

 

[NumberSix]

This is probably the fastest way to grant SMB access. Do note that it will change on-disk permissions for everything underneath.

Hi
Thank you for your suggestion. I was initially thrilled - even I undersdtood the logic of what you were saying. I added the ACL entry you suggested, complete with recursive applicability. Then I added my 'personal name' account to the group builtin_users:
Still - no access to the Syncthing samba share. I puzzled it a moment, then tried adding root to the builtin_users group too. Still no access allowed. Aside from me and root, the only other user on the system is Sync - the name i gave to the Syncthing user, and that was already a member of the builtin_user group. So - still the samba share to the syncthing folder was locked out.

In a fit of what can only be described as superstition, I deleted the Syncthing share from my Windows desktop, and went to Truenas to re-create it. Guess what happened then? I immediately had access! And the weirdness doesn't stop there either. I rolled back all the changes I'd made, removing the "builtin_user" group from the ACL and making various entities members - and tried again. It continued to work!

So my conclusion is that there was some glitch - what we may never know - with the execution of the samba share, since simply re-doing it fixed it. This also confirms my earliest comment in this thread that "I have a funny feeling that this Samba share DID work at one point" - clearly it must have, since no other changes were necessary other than re-creating it.

I'm delighted to tell you this hasn't been a complete wild goose chase however. I have learnt a valuable lesson about how to use the builtin_user group, which I'm sure will be a get out of trouble free card going forward, and will allow me access to intractable share problems in the future.

I am actually immensely grateful to you Anodos. I was pretty much in despair at the start of this misadventure, so I want to thank you for taking this on, and your clear and steady navigation through the problem until it was fixed. A very serious "thank you" is due to you sir.

Cheers!

 

[anodos]

Hi
Thank you for your suggestion. I was initially thrilled - even I undersdtood the logic of what you were saying. I added the ACL entry you suggested, complete with recursive applicability. Then I added my 'personal name' account to the group builtin_users:
Still - no access to the Syncthing samba share. I puzzled it a moment, then tried adding root to the builtin_users group too. Still no access allowed. Aside from me and root, the only other user on the system is Sync - the name i gave to the Syncthing user, and that was already a member of the builtin_user group. So - still the samba share to the syncthing folder was locked out.

In a fit of what can only be described as superstition, I deleted the Syncthing share from my Windows desktop, and went to Truenas to re-create it. Guess what happened then? I immediately had access! And the weirdness doesn't stop there either. I rolled back all the changes I'd made, removing the "builtin_user" group from the ACL and making various entities members - and tried again. It continued to work!

So my conclusion is that there was some glitch - what we may never know - with the execution of the samba share, since simply re-doing it fixed it. This also confirms my earliest comment in this thread that "I have a funny feeling that this Samba share DID work at one point" - clearly it must have, since no other changes were necessary other than re-creating it.

I'm delighted to tell you this hasn't been a complete wild goose chase however. I have learnt a valuable lesson about how to use the builtin_user group, which I'm sure will be a get out of trouble free card going forward, and will allow me access to intractable share problems in the future.

I am actually immensely grateful to you Anodos. I was pretty much in despair at the start of this misadventure, so I want to thank you for taking this on, and your clear and steady navigation through the problem until it was fixed. A very serious "thank you" is due to you sir.

Cheers!

The builtin_users group was a suggestion because it will prevent syncthing from removing permissions for your SMB users.

 

[anodos]

To clarify a bit, sometimes unix applications will try to manage their own permissions. So you start up with something that looks good:

Code:

root@freenas[/mnt/dozer/SMB]# mkdir new_dir
root@freenas[/mnt/dozer/SMB]# getfacl . 
# file: .
# owner: root
# group: wheel
group:builtin_users:rwxpDdaARWcCos:fd-----:allow
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:rwxpDdaARWcCos:fd-----:allow
root@freenas[/mnt/dozer/SMB]# getfacl new_dir 
# file: new_dir
# owner: root
# group: wheel
group:builtin_users:rwxpDdaARWcCos:fd----I:allow
            owner@:rwxpDdaARWcCos:fd----I:allow
            group@:rwxpDdaARWcCos:fd----I:allow
         everyone@:rwxpDdaARWcCos:fd----I:allow

Everyone has full control things are peachy. Then rogue application decides it knows best with permissions:

Code:

root@freenas[/mnt/dozer/SMB]# chmod 755 new_dir
root@freenas[/mnt/dozer/SMB]# getfacl new_dir 
# file: new_dir
# owner: root
# group: wheel
group:builtin_users:rwxpDdaARWcCos:fd----I:allow
            owner@:rwxpDdaARWcCos:fdi---I:allow
            group@:rwxpDdaARWcCos:fdi---I:allow
         everyone@:rwxpDdaARWcCos:fdi---I:allow
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow

At this point, if we didn't have the group:builtin_users:full_set entry, we would lose write access.

I know there are some quite adamant users out there who insist that ACLs don't work or are broken and as first recourse tell other users to strip ACLs. Yes, this works as a _temporary_ remedy at times, because it resets permissions to a certain state, but eventually "rogue application" will do its magic again.

The proper solution if you're going to have jailed applications interact with an SMB share is to assume that they will play around with the owner@, group@, everyone@ entries. Don't count on them for access, and instead use a named ACL entry. chmod() will not alter named entries.

 

[NumberSix]

A cautionary tale indeed.
Thank you for that priceless snippet. I'd be losing my mind trying to learn about a system that meanwhile had elements doing 'rogue magic' as a sideshow. So invaluable to have a cast iron method of sidestepping all the nonsense. Thanks again for that!