Comment # 4 on bug 1195463 from Christian Boltz

Hmm, that's interesting[tm] - in theory it should work with these packages.

The log in your initial bugreport looks like you didn't have the updated
profiles yet, therefore a few questions:
- do you still see the same DENIED lines in /var/log/audit/audit.log ?
- can you show the lines for the samba and apparmor packages from
  /var/log/zypp/history ? (The timestamp is relevant for the next question.)
- when the profiles were reloaded during installing the update, does audit.log
  say   operation="profile_replace" info="same as current profile, skipping" 
  or just   operation="profile_replace"   for the   smbd   profile?
  (If it has "same as current profile", there might be something interesting
  with your cache.)
  See [1] below regarding timestamps in audit.log.

Speaking about the cache - I'd also be interested in the result of

ls -l /etc/apparmor.d/usr.sbin.smbd /etc/apparmor.d/local/usr.sbin.smbd*
/var/cache/apparmor/*/usr.sbin.smbd

to see the timestamps of your profile, included local files, and the cache
files.


With some luck, the output of above ls already explains the problem - my wild
guess is that your /etc/apparmor.d/local/usr.sbin.smbd-shares could be newer
than the packaged profile, and therefore the cache looks "new enough".



[1]
If you want to search for the audit.log entries at the time of installing the
update yourself, you might wonder where the timestamp in audit.log hides - it's
at the beginning of the line at msg=audit(1644003177 (as unix timestamp) and  
date -d @1644003177   will translate it  to a human-readable date. 

For the other way round (translating the timestamp from zypper.log to a unix
timestamp) you can use   date +%s -d '2022-02-04 20:05'

If you don't want to search for the relevant audit.log timestamp, just provide
the zypp/history sniplet and attach your full audit.log.