Hi Christian,>> for the explanation), therefore you basically did stop smb, start/reload
>> apparmor (= reload all profiles) and then start smb.

When I did the systemctl stop apparmor followed by a systemctl status apparmor

it does show that the apparmor service is loaded but inactive hence the confusion.

So maybe when the start/reload apparmor occurred that is what caused the issue

to resolve itself?

smb.conf DOES have a new timestamp because at one point I edited the file

and saved it but I didn't make any changes and it still compares to the version from

the snapshot before the update when the problems occurred.   The before

snapshot had a timestamp of 11/16/2021 which is the last time that I had to

make a config change to smb.conf. 

>> (A newer timestamp means /usr/share/samba/update-apparmor-samba-profile

So it would appear that because once I saved the file with a newer timestamp that

triggered the reload as you described, however, the file didn't really change which

begs the question as to why didn't it work after the TW update or should the TW

update have forced a reload of the profile and didn't which caused the issue?

>> Wild guess: did your /etc/apparmor.d/local/usr.sbin.smbd-shares get
>> updated when smb was (re)started? Please check the file timestamp to
>> verify this.

You are correct that the /etc/apparmor.d/local/usr.sbin.smbd-shares file does have a newer

timestamp which is about 2 min later than the saved ( but unchanged ) smb.conf file.

So the timestamps on both files are newer BUT I just compared the current 

/etc/apparmor.d/local/usr.sbin.smbd-shares file to the one from the snapshot before the

TW update and it too compares.

So BOTH smb.conf and usr.sbin.smbd-shares from the before snapshot compare to their

current versions and the only difference is that they now have newer timestamps.

So I am back to my prior question....If BOTH files are exactly the same as they were

before the TW update and the only difference is the newer timestamps on the current

files then why did it stop working?

>> Unless I overlooked something, the DENIED lines were for two files:

I did not give you all the denied lines but that had access denied.

Looking at the log I can break the denied lines into 3 groups

1) /var/lib/nscd/netgroup

2) files on smb shares which I have setup

3) lines which are for samba-dcerpcd

Here are some examples of the samba-dcerpcd log lines:

type=AVC msg=audit(1662039375.496:2612): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F4465736B746F702F53686F7720746F2044656E6973652F pid=26458 comm="samba-dcerpcdr requested_mask="r" denied_mask="r" fsuid=0 ouid=1000
type=AVC msg=audit(1662039375.496:2613): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F4465736B746F702F53686F7720746F2044656E6973652F pid=26458 comm="samba-dcerpcd" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000
type=AVC msg=audit(1662415128.929:3390): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F50696374757265732F53616C6D6572692046616D696C792F pid=742 comm="samba-dcerpcd" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000
type=AVC msg=audit(1662415128.929:3392): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F50696374757265732F53616C6D6572692046616D696C792F4B696D6265726C792F537572676572792030392D30352D323031322F pid=742 comm="samba-dcerpcd" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000
type=AVC msg=audit(1662415128.929:3393): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F50696374757265732F53616C6D6572692046616D696C792F pid=742 comm="samba-dcerpcd" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000
type=AVC msg=audit(1662415128.929:3394): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F50696374757265732F53616C6D6572692046616D696C792F4B696D6265726C792F537572676572792030392D30352D323031322F pid=742 comm="samba-dcerpcd" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000
type=AVC msg=audit(1662415128.929:3395): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F50696374757265732F53616C6D6572692046616D696C792F4B696D6265726C792F537572676572792030392D30352D323031322F494D475F343335392E4A5047 pid=742 comm="samba-dcerpcd" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000
type=AVC msg=audit(1662415128.929:3396): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F50696374757265732F53616C6D6572692046616D696C792F4B696D6265726C792F537572676572792030392D30352D323031322F494D475F343336302E4A5047 pid=742 comm="samba-dcerpcd" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000

Note that since I did the systemctl stop of apparmor ( which did nothing ) and stop of smb and then start for both everything has worked flawlessing and no access denied errors have occurred.

So it seems the timestamp change for smb.conf caused the /etc/apparmor.d/local/usr.sbin.smbd-shares to be regenerated but as I said both files still compare to the files from the before TW snapshot so that doesn't explain why smb stopped working and was getting the denied errors after the TW update.

>> The profile already allows reading /etc/netgroup, therefore also allowing

Thanks

>> That said - getting this denied is probably "just" an annoyance for
>> smbd, but it shouldn't break accessing your shares.
>> For that, we have (had?) the other log event:
>> >> msg=audit(1667529133.916:626): apparmor="DENIED"
>> >> operation="open" profile="smbd" name="/vol/g/joe/bin/profile.ps1"
>> >> pid=15194 comm="smbd" requested_mask="r" denied_mask="r" fsuid=1000
>> >> ouid=1000 type=AVC
>> I guess that's a file on one of your samba shares?

Yes, that is a reference to a file that is on one of the samba shares.   See above for a breakdown of the 3 "groups" 

of files that were getting the access denied errors prior to restarting the servies.

>> Now that things are working again, do you still get DENIED lines for

No, everything has worked flawlessly since the timestamp changed on smb.conf causing the reload.
>> a mail reply is enough. If you get more/different log lines, please open
>> a bugreport and attach your audit.log.

Correct no denied errors since I restart the services.