Hi Christian,
Sorry for the delayed reply as I've been sick and recovering.
>> For the records: systemctl stop does nothing (see systemctl cat apparmor
>> 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?
>> Does smb.conf it still have the old timestamp, or a new one?
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
>> will update /etc/apparmor.d/local/usr.sbin.smbd-shares and reload the
>> profile when you (re)start smb.)
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
>> to read the nscd-cached variant makes sense. I'll make sure to get that allowed.
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
>> this or another file on your shares?
No, everything has worked flawlessly since the timestamp changed on smb.conf causing the reload.
>> If the only new log events you still get are for /var/lib/nscd/netgroup,
>> 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.
So do we have an explanation as to what occurred? Seems odd that the files compare and that the only change is that the smb.conf
got a new timestamp causing apparmor to reload the both files still compared to before the update.
So I guess if it happened again, I would just touch smb.conf causing apparmor to reload and then it would work again?
>> PS: sorry for the late answer - I clearly need longer days ;-)
No worries, as I said I've been sick and recovering.