Hello, Am Freitag, 4. November 2022, 20:43:17 CET schrieb Joe Salmeri:
To be safe (in case something else post update needed to run that I was not aware of ) I rebooted the server several times but the Linux and Windows clients still got the access denied when trying to access the shares. [...] As I test I tried the following:
systemctl stop apparmor systemctl stop smb
systemctl start apparmor systemctl start smb
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. I wonder why this should give you a different behaviour than the reboots - even if...
As soon as I did that shares and files started working and were accessible from Linux and Windows 10 clients.
... reality shows that it did.
NOTHING was changed and my smb.conf from the 20220908 before zypper dup snapshot matches what is being used with the 20221101 updated snapshot.
Does smb.conf it still have the old timestamp, or a new one? (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.)
I have rebooted the server several times now after stopping and restarting apparmor and smb and everything continues to work now.
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.
That makes no sense to me because all of those reboots would have also stopped and started the services but they didn't work but when I manually did it things start working?
Indeed, that sounds interesting[tm].
Could this be a timing related issue when systemd starts apparmor and smbd that caused the issue since when I manually did it I wait for the other service to start before doing the second one?
Sounds unlikely IMHO.
Looking at /var/log/audit/audit.log I do find lots of DENIED lines so seems clear that the issue was apparmor causing the access denied.
Here are some examples:
Unless I overlooked something, the DENIED lines were for two files:
type=AVC msg=audit(1667529133.916:625): apparmor="DENIED" operation="file_receive" profile="smbd" name="/var/lib/nscd/netgroup" pid=15194 comm="smbd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 type=AVC
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. 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? Now that things are working again, do you still get DENIED lines for this or another file on your shares?
I did NOT switch the profiles to complain mode because when I manually stopped and started apparmor and smbd then everything "magically" started to work.
As I said above, that's "just" a reload of all profiles - and so far, "magic" is the only explanation why this changed something, while reboots didn't.
I have not submitted a bug report but will gladly do so if you want one but you have all the info from this message.
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. Regards, Christian Boltz PS: sorry for the late answer - I clearly need longer days ;-) -- Aren't most of SUSE-employed community members part of the Research&Destroy department? [Sascha Peilicke in opensuse-project]