...

please try 1 stopping smbd (rcsmb stop) 2 stopping apparmor (rcapparmor stop) 3 unloading the profiles (aa-teardown)

Note that this will unload *all* profiles, and even after reloading them, running processes will stay unconfined (unless you restart them).

https://bugzilla.suse.com/show_bug.cgi?id=1195412 https://bugzilla.suse.com/show_bug.cgi?id=1195412#c10 --- Comment #10 from Noel Power <nopower@suse.com> --- (In reply to Christian Boltz from comment #9) Hi Christian true and this is worth pointing out. for me though this was more about proving to myself that something funky was going on (since this step didn't ensure the new profile stuck)

...

4 removing the cached compiled profile (rm /etc/apparmor.d/cache.d/$(somenumber)/usr.sbin.smb) 5 restart apparmor (rcapparmor start) 6 restart smbd (rcsmb start)

I had to do step 4 (which seems unnecessary, perhaps there is an issue with apparmor) in order to get the profile to start to work

That indeed sounds unnecessary.

I'm pretty certain the cached use.sbin.smb binary profile didn't update after the apparmor was updated. Is there some special step that one should do or is the expectation the cached object should be updated along with the new profile ? IIRC if I manually modify a profile to add a new rule and restart apparmor it normally sticks (which sounds to me like the update should *just* work) I'm going to (later) have a go at reproducing this with a vm (so I can snapshot fully back to state before updating) -- You are receiving this mail because: You are on the CC list for the bug.