Resetting ACL & SMB/CIFS sharing permissions

[ubuntumuntu]

hi folks,

Been running this FN/TN box over numerous major & minor releases for my home-office NAS.
Been working incredibly well & can't see myself ever moving off.

Running it purely in-house & home-lab, so my security needs are very modest and quite permissive.

I've set up several Datasets, such as media, downloads, ISO's, backups, homes, etc, that are in turn exposed to my LAN as NFS & SMB shares.
I have another skinny box running my Docker containers (images on local SSD), that link back to this box for data/media that do not require super-fast I/O (think PXE, Plex, etc).

This NAS of mine been going for a while, but I must've screwed up something around the time I upgrading to TrueNAS-12.0-RELEASE.

One of my shares - media - has become 'inaccessible' (particularly over SMB), or rather, it requires me to provide auth credentials - username & password - to access the share, rather than permitting anonymous/guest access as before.
This has not been the case before.

I've tried creating another SMB share to the same location, but the result is the same, leading me to believe it was an OS issue.
For "some reason" it got windows-style ACL controls attached to it, but I'm not sure why or where this would've come from (think it might've been some time during a previous release), as I run a predominantly POSIX environment.
I've tried some CLI-fu to strip the entire Dataset of ACL, but did not seem to have the desired effect.

How can I reset the Dataset to 'default' - no ACL, with files having basic universal +rw-x, dirs writable by unprivileged network apps, and the SMB/CIFS share(s) accessible as guest/no-auth?

(apologies if these are very n00b questions, but meds having me not fire on all pistons at the moment & I'd rather get a sanity-check before I trash my box)

 

[Alecmascot]

From the 12.0 Release notes :

TrueNAS "root" user account cannot be an SMB user.

This is an intentional change to improve software security and suitability for deployment in a variety of environments. Update the SMB configuration to use a different user account.

Sounds like your issue

 

[ubuntumuntu]

From the 12.0 Release notes :

TrueNAS "root" user account cannot be an SMB user.

This is an intentional change to improve software security and suitability for deployment in a variety of environments. Update the SMB configuration to use a different user account.

Sounds like your issue

Might be; I'll have to check it out.

TTBOMR, I set the chown to www:wheel (I think?) & think I may be mapping SMB similarly.
Regardless, I'll do that.

What is odd is that some of the SMB shares work just fine; it's only the media that gives me grief. (should've mentioned that - did not think of it at the time for the reasons stated, sorry)

 

[anodos]

Might be; I'll have to check it out.

TTBOMR, I set the chown to www:wheel (I think?) & think I may be mapping SMB similarly.
Regardless, I'll do that.

What is odd is that some of the SMB shares work just fine; it's only the media that gives me grief. (should've mentioned that - did not think of it at the time for the reasons stated, sorry)

Can you perhaps show "getfacl <path to media>" and same for each parent directory of it?

 

[ubuntumuntu]

for reference

Code:

@freenas /mnt/data/storage]$ ls -al
total 121
drwxrwxr-x+ 8 www wheel 8 May 6 2020 .
drwxr-xr-x 6 root wheel 6 Dec 6 2019 ..
drwxrwxr-x+ 8 www wheel 9 Dec 6 2019 backups
drwxr-xr-x+ 16 www wheel 22 Dec 6 00:02 config
drwxrwxr-x+ 7 www wheel 8 Oct 19 11:10 downloads
drwxrwxr-x+ 11 www wheel 15 Dec 16 2019 images
drwxr-xr-x 24 www wheel 26 Nov 23 13:10 media
drwxr-xr-x 9 www wheel 29 May 13 2020 scratch

media share that's FUBAR

Code:

$ getfacl media
# file: media
# owner: www
# group: wheel
owner@:rwxp--aARWcCos:-------:allow
group@:r-x---a-R-c--s:-------:allow
everyone@:r-x---a-R-c--s:-------:allow

downloads seem fine

Code:

getfacl downloads/
# file: downloads/
# owner: www
# group: wheel
owner@:rwxpDdaARWcCos:fd----I:allow
group@:rwxpDdaARWcCos:fd----I:allow
everyone@:r-x---a-R-c---:fd----I:allow

for NFS

Code:

$ cat /etc/exports 
V4: / -sec=sys
/mnt/data/storage/media -alldirs -mapall="www":"wheel" -network $OBFUSCATED/24
/mnt/data/storage/backups -alldirs -maproot="www":"wheel" -network $OBFUSCATED/24
/mnt/data/storage/images -alldirs -maproot="www":"wheel" -network $OBFUSCATED/24
/mnt/data/storage/config -alldirs -mapall="www":"www" -network $OBFUSCATED/24
/mnt/data/storage/config -alldirs -mapall="www":"www" -network $OBFUSCATED/16

Looking for the SMB conf file. Expected to find it in (/usr/local)/etc/smb*conf, but that's not the droid I'm looking for.
will come back to that later...

SMB config via `testparm -s`

Code:

# Global parameters
[global]
        aio max threads = 2
        bind interfaces only = Yes
        disable spoolss = Yes
        dns proxy = No
        enable web service discovery = Yes
        guest account = www
        interfaces = 127.0.0.1 10.0.0.50
        kernel change notify = No
        load printers = No
        logging = file
        map to guest = Bad User
        max log size = 51200
        netbios aliases = freenas nas
        netbios name = NAS
        nsupdate command = /usr/local/bin/samba-nsupdate -g
        obey pam restrictions = Yes
        registry shares = Yes
        server role = standalone server
        server string = FreeNAS Server
        unix extensions = No
        username map = /usr/local/etc/smbusername.map
        username map cache time = 60
        workgroup = MESHED.NZ
        idmap config *: range = 90000001-100000000
        idmap config * : backend = tdb
        directory name cache size = 0
        dos filemode = Yes


[downloads]
        ea support = No
        guest ok = Yes
        path = /mnt/data/storage/downloads
        read only = No
        vfs objects = zfs_space zfsacl streams_xattr
        nfs4:chown = true

[images]
        ea support = No
        guest ok = Yes
        level2 oplocks = No
        oplocks = No
        path = /mnt/data/storage/images
        read only = No
        strict locking = Yes
        vfs objects = zfs_space zfsacl streams_xattr
        nfs4:chown = true


[backups]
        ea support = No
        guest ok = Yes
        level2 oplocks = No
        oplocks = No
        path = /mnt/data/storage/backups
        read only = No
        strict locking = Yes
        vfs objects = zfs_space zfsacl streams_xattr
        nfs4:chown = true


[scratch]
        ea support = No
        guest ok = Yes
        path = /mnt/data/storage/scratch
        read only = No
        vfs objects = zfs_space zfsacl streams_xattr
        nfs4:chown = true

[homes]
        ea support = No
        hide dot files = No
        path = /mnt/data/home/%U
        read only = No
        vfs objects = zfs_space zfsacl streams_xattr
        nfs4:chown = true


[software]
        ea support = No
        guest ok = Yes
        path = /mnt/data/storage/downloads/SOFTWARE
        read only = No
        vfs objects = zfs_space zfsacl streams_xattr
        nfs4:chown = true


[config]
        comment = containers & apps configs
        ea support = No
        guest ok = Yes
        level2 oplocks = No
        oplocks = No
        path = /mnt/data/storage/config
        read only = No
        strict locking = Yes
        vfs objects = aio_fbsd streams_xattr shadow_copy_zfs ixnas
        nfs4:chown = true

[media-FUBAR]
        browseable = No
        comment = Multi-media
        ea support = No
        guest ok = Yes
        level2 oplocks = No
        mangled names = no
        oplocks = No
        path = /mnt/data/storage/media
        read only = No
        strict locking = Yes
        vfs objects = zfs_space zfsacl streams_xattr
        catia:mappings = 0x01:0xf001,0x02:0xf002,0x03:0xf003,0x04:0xf004,0x05:0xf005,0x06:0xf006,0x07:0xf007,0x08:0xf008,0x09:0xf009,0x0a:0xf00a,0x0b:0xf00b,0x0c:0xf00c,0x0d:0xf00d,0x0e:0xf00e,0x0f:0xf00f,0x10:0xf010,0x11:0xf011,0x12:0xf012,0x13:0xf013,0x14:0xf014,0x15:0xf015,0x16:0xf016,0x17:0xf017,0x18:0xf018,0x19:0xf019,0x1a:0xf01a,0x1b:0xf01b,0x1c:0xf01c,0x1d:0xf01d,0x1e:0xf01e,0x1f:0xf01f,0x22:0xf020,0x2a:0xf021,0x3a:0xf022,0x3c:0xf023,0x3e:0xf024,0x3f:0xf025,0x5c:0xf026,0x7c:0xf027
        nfs4:chown = true


[media]
        ea support = No
        guest ok = Yes
        level2 oplocks = No
        oplocks = No
        path = /mnt/data/storage/media
        read only = No
        strict locking = Yes
        vfs objects = aio_fbsd shadow_copy_zfs ixnas
        nfs4:chown = true

(/me spot the difference - one of these is not like the others...)
looks like downloads is all YOLO! permissive, which is probably not great in its own sense.

may be best to just reset it all, so I don't have any more surprises.

 

[anodos]

testparm -s will print your current running configuration for SMB.
Is this 12.0-RELEASE or 12.0-U1?

 

[ubuntumuntu]

testparm -s will print your current running configuration for SMB.
Is this 12.0-RELEASE or 12.0-U1?

updated my previous post with this data, to keep everything concise.

running TrueNAS-12.0-RELEASE - kernel FreeBSD 12.2-RC3 FreeBSD 12.2-RC3 7c4ec6ff02c(HEAD) TRUENAS amd64

 

[anodos]

updated my previous post with this data, to keep everything concise.

running TrueNAS-12.0-RELEASE - kernel FreeBSD 12.2-RC3 FreeBSD 12.2-RC3 7c4ec6ff02c(HEAD) TRUENAS amd64

12.0-RELEASE has a bug wherein if [homes] shares are enabled, access to \\server\media will result in user landing in \\server\<username>. This is fixed in U1.

 

[ubuntumuntu]

12.0-RELEASE has a bug wherein if [homes] shares are enabled, access to \\server\media will result in user landing in \\server\<username>. This is fixed in U1.

g'dammit! Well, that explains a lot.
I wanted to say something was not adding up on my share-mounts, but it was not consistent on all the connecting clients & differed when referencing hostname, hostname.local, hostname.fqdn, & IP. (assumed it was some sort of client-side caching issue)

Thought it was just my addled brain or plain incompetence/ineptitude on my part, and saw the U1 update labelled as "This is not a production release, and should only be used for testing.", so held off on that until I got the above issue resolved.

Upgrading now before carrying on with the permissions problem.

Thanks for the tip.

 

[ubuntumuntu]

Upgrading now before carrying on with the permissions problem.

Well, OK then - that just solved a bunch of problems!
Seems that solved the manifestation of this issue that confounded me, but still highlights the discrepancies I've accumulated on my box over the years.

Thanks for the patient assist, @anodos.
I really do appreciate you taking the time.

At least this means I can start moving ahead working on some of my adjoining systems, but it may still be wise to bring them all in line.

(Correct me where I'm wrong, but) seems the tasks still left to me include:

• Clearing ACL from the Dataset
• (re)Set the chown & chmod correctly - www:wheel, +rw-x
• Set SMB (&NFS) access & permissions

For the most part my (security) needs & requirements are quite modest for a home-office/lab.
Pretty-much everything is relatively accessible, with exceptions for:

• $HOMES - which typically is a bit of a "special case"
• one or 2 shares that I could/should possibly move to a dedicated dataset for special treatment, such as backups & configs (so that I don't upset nodes automated backup systems, etc)
• Datasets that are shared with my Docker instances - for the most part those can just be hooked into via NFS, but I will probably expose them via iSCSI one day when I can afford the fibre-channel hardware.

EDIT:
(Meant to include the following comment)
As far as possible I'd like to do as much of this resetting via CLI, so that I can test & script before committing; some things are just a little cumbersome to do via WebUI.
A concern is that doing much via CLI could introduce new problems, i.e. the WebUI provides a degree of abstraction to prevent me from shooting myself in the foot, and doing CLI stuff could break some of these safeguards or leave changes 'disconnected'.
At least that has been my experience with lesser NAS systems.

 

[ubuntumuntu]

Some LMGTFY & online check would indicate to following course of action. IIRC, some of there are not super-awesome, especially around `find`, so checking yet again before pulling the trigger (head's starting to slow now)

Code:

sudo find /mnt/data/storage -type d -exec chmod 755 {} \+
sudo find /mnt/data/storage -type f -exec chmod 644 {} \+
sudo find /mnt/data/storage -exec chown www:wheel {} \+
sudo setfacl -R -b /mnt/data/storage

 

[ubuntumuntu]

I've had some success - partly with help from some kindly IRC peeps in addition to the folks above.

(after extensive testing) I peeled it away quite a lot

• purging ACL's from the Datasets/Filesystems - seconded via `setfacl -R -b /mnt/data/storage`
• setting the Access Mode as 775, user=www, group=wheel recursively/traverse (started testing with a few 777's to drill down to fault)
• reset/recreated most/all my SMB shares with
  • presets for either "Multi-protocol NFS/SMB" or "No presets"
  • browsable, guest access
  • & Aux params of "directory mask=0755" & "create mask=0644" (without this it was simply too YOLO @ 777)
  • SMB/CIFS server has "guest account as www"

The caveat I found was around the ACL pop-up after configuring the share.
This implies/assumes that the set/share wants/needs to go that route, even though nothing in my setup would suggest that (at this time).
This is a degree of complication that's not required for how my home-office is architected, but I can see the merit & purpose of having such more granular controls - something that I'll dig into in more depth as I tighten up controls, but this makes much more sense with a domain controller in the mix and uniform identities across the stacks.

This is not ideal, but gets me functional again, for now, meaning I can finally move forward to (re)building my other systems.
At least this has given me better insights to how ACL's need to be incorporated in future & considerations when integrating connecting systems.

I eventually picked up that part of the problem seems to have been clients-side, i.e. I was testing shares as I was making changes, and seems the client 'cached' permissions (I know how off this sounds; had me pulling hair).
Only when I started testing with additional clients - windows & other POSIX - (while checking effects on the NAS via ssh), did things start behaving as expected.
I lost quite a lot of time through the machine I initially used, where I could make files on the share, but was not able to modify or save content changes - which 'felt' like ACL control, even though I explicitly purged those from the test dataset & shares.

I think I've reached a point where I can put this one to bed; maybe this information will be helpful to someone else.

Lessons learnt:

• bug pre-U1 caused me pain
• avoid ACL unless explicitly needed.
  • less is more
• don't trust your client - it lies.