|
Bugzilla – Full Text Bug Listing |
| Summary: | smb does not start if openSUSE-SLE-15.3-2022-283 is installed and smb.conf has printers set up | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Mathias Homann <Mathias.Homann> |
| Component: | Samba | Assignee: | The 'Opening Windows to a Wider World' guys <samba-maintainers> |
| Status: | RESOLVED FIXED | QA Contact: | The 'Opening Windows to a Wider World' guys <samba-maintainers> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | andreas.osterburg, axel.braun, bjoernv, cobexer, david.mulder, felix.niederwanger, Mathias.Homann, meissner, nopower, pdostal, scabrero, suse-beta |
| Version: | Leap 15.3 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Mathias Homann
2022-02-02 06:23:11 UTC
Same here. It seems that apparmor is the problem. My workaround: Add the following two lines to /etc/apparmor.d/local/usr.sbin.smbd /usr/lib64/samba/samba-bgqd ix, /run/samba/samba-bgqd.pid rw, and reload the appamor profile /sbin/apparmor_parser -r /etc/apparmor.d/usr.sbin.smbd That works for me. Another solution is (if applicable) disabling spoolss in global section of smb.conf: disable spoolss = yes (In reply to Andreas Osterburg from comment #1) > Same here. It seems that apparmor is the problem. > > My workaround: > > Add the following two lines to /etc/apparmor.d/local/usr.sbin.smbd > > /usr/lib64/samba/samba-bgqd ix, > /run/samba/samba-bgqd.pid rw, > > and reload the appamor profile > > /sbin/apparmor_parser -r /etc/apparmor.d/usr.sbin.smbd > > That works for me. > > Another solution is (if applicable) disabling spoolss in global section of > smb.conf: > > disable spoolss = yes I did the apparmor workaround, now my samba server does not have any printers anymore. Rolling back to the previous one instead... again... (In reply to Mathias Homann from comment #2) > (In reply to Andreas Osterburg from comment #1) > > Same here. It seems that apparmor is the problem. > > > > My workaround: > > > > Add the following two lines to /etc/apparmor.d/local/usr.sbin.smbd > > > > /usr/lib64/samba/samba-bgqd ix, > > /run/samba/samba-bgqd.pid rw, > > > > and reload the appamor profile > > > > /sbin/apparmor_parser -r /etc/apparmor.d/usr.sbin.smbd actually: akari:~ # /sbin/apparmor_parser -r /etc/apparmor.d/local/usr.sbin.smbd AppArmor-Analysefehler f?r /etc/apparmor.d/local/usr.sbin.smbd in /etc/apparmor.d/local/usr.sbin.smbd in Zeile 2: syntax error, unexpected TOK_MODE, expecting TOK_OPEN (In reply to Mathias Homann from comment #3) > (In reply to Mathias Homann from comment #2) > > (In reply to Andreas Osterburg from comment #1) > > > Same here. It seems that apparmor is the problem. > > > > > > My workaround: > > > > > > Add the following two lines to /etc/apparmor.d/local/usr.sbin.smbd > > > > > > /usr/lib64/samba/samba-bgqd ix, > > > /run/samba/samba-bgqd.pid rw, > > > > > > and reload the appamor profile > > > > > > /sbin/apparmor_parser -r /etc/apparmor.d/usr.sbin.smbd > > actually: > > akari:~ # /sbin/apparmor_parser -r /etc/apparmor.d/local/usr.sbin.smbd > AppArmor-Analysefehler f?r /etc/apparmor.d/local/usr.sbin.smbd in > /etc/apparmor.d/local/usr.sbin.smbd in Zeile 2: syntax error, unexpected > TOK_MODE, expecting TOK_OPEN You cannot load just the local part, you have to include the whole profile: /sbin/apparmor_parser -r /etc/apparmor.d/usr.sbin.smbd (without "local") You can test whether unconfined mode "ux" works instead of "ix", but the forked process has no security constraints then. (In reply to Andreas Osterburg from comment #4) > (In reply to Mathias Homann from comment #3) > > (In reply to Mathias Homann from comment #2) > > > (In reply to Andreas Osterburg from comment #1) > > > > Same here. It seems that apparmor is the problem. > > > > > > > > My workaround: > > > > > > > > Add the following two lines to /etc/apparmor.d/local/usr.sbin.smbd > > > > > > > > /usr/lib64/samba/samba-bgqd ix, > > > > /run/samba/samba-bgqd.pid rw, > > > > > > > > and reload the appamor profile > > > > > > > > /sbin/apparmor_parser -r /etc/apparmor.d/usr.sbin.smbd > > > > actually: > > > > akari:~ # /sbin/apparmor_parser -r /etc/apparmor.d/local/usr.sbin.smbd > > AppArmor-Analysefehler f?r /etc/apparmor.d/local/usr.sbin.smbd in > > /etc/apparmor.d/local/usr.sbin.smbd in Zeile 2: syntax error, unexpected > > TOK_MODE, expecting TOK_OPEN > > You cannot load just the local part, you have to include the whole profile: > /sbin/apparmor_parser -r /etc/apparmor.d/usr.sbin.smbd > That worked, but the updated samba server does *not* offer any printers. Could you provide a copy of your smb.conf? modifying apparmor shouldn't be necessary apparmor-profiles-2.13.6-150300.3.11.2.noarch should contain a profile for samba-bgqd please try 1 stopping smbd (rcsmb stop) 2 stopping apparmor (rcapparmor stop) 3 unloading the profiles (aa-teardown) 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 (In reply to Mathias Homann from comment #5) > > That worked, but the updated samba server does *not* offer any printers. Hi Mathias, in samba 4.13 the printer list was loaded in smbd startup and refreshed at regular intervals configured by the "printcap cache time" parameter. In samba 4.15 the list is no longer loaded in the startup and you have to wait until the cache times out for the printers to show up. Could you please confirm the printers show up after the configured printcap cache time? Most important note first: the update to the AppArmor 2.13.6 packages (which is needed for the updated samba packages) is quite new - https://build.opensuse.org/package/show/openSUSE:Leap:15.3:Update/apparmor.22444 says "21 hours". Therefore make sure that you have installed the latest updates. If you still have problems with the updated AppArmor package, please attach your /var/log/audit/audit.log (In reply to Noel Power from comment #7) > modifying apparmor shouldn't be necessary > > apparmor-profiles-2.13.6-150300.3.11.2.noarch > > should contain a profile for samba-bgqd > > 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). > 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. BTW: If you have added the workaround from comment #1 to your local/usr.sbin.smbd, please remove it again. It "hides" a rule that comes with the update (using Px + a separate profile instead of ix/inherit), which might in worst case cause some trouble in the future if bgqd needs more permissions. (In reply to Christian Boltz from comment #9) Hi Christian > > 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). 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) (In reply to Noel Power from comment #10) > (In reply to Christian Boltz from comment #9) > > Hi Christian > > > > 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). > 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) (In reply to Christian Boltz from comment #9) > Most important note first: the update to the AppArmor 2.13.6 packages (which > is needed for the updated samba packages) is quite new - > https://build.opensuse.org/package/show/openSUSE:Leap:15.3:Update/apparmor. > 22444 says "21 hours". > Therefore make sure that you have installed the latest updates. That update hasn't made it's way to the mirrors yet. (In reply to Samuel Cabrero from comment #8) > (In reply to Mathias Homann from comment #5) > > > > That worked, but the updated samba server does *not* offer any printers. > > Hi Mathias, > > in samba 4.13 the printer list was loaded in smbd startup and refreshed at > regular intervals configured by the "printcap cache time" parameter. In > samba 4.15 the list is no longer loaded in the startup and you have to wait > until the cache times out for the printers to show up. > > Could you please confirm the printers show up after the configured printcap > cache time? I have changed that time to 30 seconds, and now it's several minutes since I've restarted samba. No printers. (In reply to Mathias Homann from comment #12) > I have changed that time to 30 seconds, and now it's several minutes since > I've restarted samba. No printers. that was actually a typo. Sometimes I hate vim. Now I've actually set that timeout to 30 seconds instead of 3330 seconds, and the printers show up as expected. I do still need that workaround for apparmor, the update mentioned above is not public yet. (In reply to Noel Power from comment #10) > (In reply to Christian Boltz from comment #9) > > > > > 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) well, perhaps I was imagining things :-) I retried this on a fresh leap15.3 vm (NOTE: leap15.3 has the apparmor update even since this morning) samba started fine after the update localhost:~ # smbd --version Version 4.13.4-git.187.5ad4708741a1.34-SUSE-oS15.0-x86_64 localhost:~ # zypper up samba apparmor* Loading repository data... Reading installed packages... Resolving package dependencies... " " localhost:~ # rpm -qa | grep apparmor-profiles apparmor-profiles-2.13.6-150300.3.11.2.noarch localhost:~ # smbd --version Version 4.15.4-git.324.8332acf1a63150300.3.25.3-SUSE-oS15.0-x86_64 localhost:~ # rcsmb restart localhost:~ # rcsmb status ● smb.service - Samba SMB Daemon Loaded: loaded (/usr/lib/systemd/system/smb.service; disabled; vendor pres> Active: active (running) since Wed 2022-02-02 15:31:24 GMT; 3s ago Docs: man:smbd(8) man:samba(7) man:smb.conf(5) Process: 5606 ExecStartPre=/usr/share/samba/update-apparmor-samba-profile (> Main PID: 5617 (smbd) Status: "smbd: ready to serve connections..." Tasks: 4 (limit: 2346) CGroup: /system.slice/smb.service ├─5617 /usr/sbin/smbd --foreground --no-process-group ├─5619 /usr/sbin/smbd --foreground --no-process-group ├─5620 /usr/sbin/smbd --foreground --no-process-group └─5622 /usr/lib64/samba/samba-bgqd --ready-signal-fd=47 --parent-w> Feb 02 15:31:24 localhost.localdomain systemd[1]: Starting Samba SMB Daemon... Feb 02 15:31:24 localhost.localdomain update-apparmor-samba-profile[5606]: Relo> Feb 02 15:31:24 localhost.localdomain smbd[5617]: [2022/02/02 15:31:24.358209, > Feb 02 15:31:24 localhost.localdomain smbd[5617]: smbd version 4.15.4-git.324> Feb 02 15:31:24 localhost.localdomain smbd[5617]: Copyright Andrew Tridgell a> Feb 02 15:31:24 localhost.localdomain systemd[1]: Started Samba SMB Daemon. (In reply to Andreas Osterburg from comment #1) > Another solution is (if applicable) disabling spoolss in global section of > smb.conf: > > disable spoolss = yes That fixed it for me, no other tweak required The apparmor update should be available now, please reopen if necessary. |