Zypper dup 23 hours ago - Wireguard fails, Samba fails

English Install/Boot/Login
1

Hi,

did zypper dup yesterday, after reboot Wireguard tunnels running for years not comming back anymore:

systemctl status wg-quick@wg0
× wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/usr/lib/systemd/system/wg-quick@.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Sun 2026-05-17 15:01:33 CEST; 28min ago
 Invocation: b4a2103c135e4e82becc213befd6e30b
       Docs: man:wg-quick(8)
             man:wg(8)
             https://www.wireguard.com/
             https://www.wireguard.com/quickstart/
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
    Process: 1948 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=126)
   Main PID: 1948 (code=exited, status=126)
        CPU: 26ms

May 17 15:01:33 dellscsi80722 systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
May 17 15:01:33 dellscsi80722 wg-quick[1948]: [#] ip link add dev wg0 type wireguard
May 17 15:01:33 dellscsi80722 wg-quick[1978]: /usr/bin/wg-quick: line 32: /usr/bin/ip: Permission denied
May 17 15:01:33 dellscsi80722 wg-quick[1980]: Unable to access interface: No such device
May 17 15:01:33 dellscsi80722 wg-quick[1948]: [#] ip link delete dev wg0
May 17 15:01:33 dellscsi80722 wg-quick[1992]: /usr/bin/wg-quick: line 32: /usr/bin/ip: Permission denied
May 17 15:01:33 dellscsi80722 systemd[1]: wg-quick@wg0.service: Main process exited, code=exited, status=126/n/a
May 17 15:01:33 dellscsi80722 systemd[1]: wg-quick@wg0.service: Failed with result 'exit-code'.
May 17 15:01:33 dellscsi80722 systemd[1]: Failed to start WireGuard via wg-quick(8) for wg0.

and

# wg-quick up wg0
[#] ip link add dev wg0 type wireguard
/usr/bin/wg-quick: line 32: /usr/bin/ip: Permission denied
Unable to access interface: No such device
[#] ip link delete dev wg0
/usr/bin/wg-quick: line 32: /usr/bin/ip: Permission denied

and

journalctl -xeu wg-quick@wg0.service

May 17 15:01:33 dellscsi80722 systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
░░ Subject: A start job for unit wg-quick@wg0.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit wg-quick@wg0.service has begun execution.
░░ 
░░ The job identifier is 321.
May 17 15:01:33 dellscsi80722 wg-quick[1948]: [#] ip link add dev wg0 type wireguard
May 17 15:01:33 dellscsi80722 wg-quick[1978]: /usr/bin/wg-quick: line 32: /usr/bin/ip: Permission denied
May 17 15:01:33 dellscsi80722 wg-quick[1980]: Unable to access interface: No such device
May 17 15:01:33 dellscsi80722 wg-quick[1948]: [#] ip link delete dev wg0
May 17 15:01:33 dellscsi80722 wg-quick[1992]: /usr/bin/wg-quick: line 32: /usr/bin/ip: Permission denied
May 17 15:01:33 dellscsi80722 systemd[1]: wg-quick@wg0.service: Main process exited, code=exited, status=126/n/a
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ An ExecStart= process belonging to unit wg-quick@wg0.service has exited.
░░ 
░░ The process' exit code is 'exited' and its exit status is 126.
May 17 15:01:33 dellscsi80722 systemd[1]: wg-quick@wg0.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The unit wg-quick@wg0.service has entered the 'failed' state with result 'exit-code'.
May 17 15:01:33 dellscsi80722 systemd[1]: Failed to start WireGuard via wg-quick(8) for wg0.
░░ Subject: A start job for unit wg-quick@wg0.service has failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit wg-quick@wg0.service has finished with a failure.
░░ 
░░ The job identifier is 321 and the job result is failed.

Moreover, Samba won’t start, with some nmb error in log, disabled nmb service, reboot brought back samba, but fails after some 80 MB copying of files and won’t come back on restart:

# systemctl stop smb
# systemctl start smb

hangs for ever.

Any ideas how to proceed? Did a zypper dup some hour ago or so, reboot didn’t help.

2

https://bugzilla.opensuse.org/show_bug.cgi?id=1265394

3

That explains that, samba still a mystery…

4

For what it’s worth:

sudo smbstatus
[sudo] password for root: 

Samba version 4.23.7-git.473.9487af01c24SUSE-oS16.9-x86_64
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing              
----------------------------------------------------------------------------------------------------------------------------------------

Service      pid     Machine       Connected at                     Encryption   Signing     
---------------------------------------------------------------------------------------------

No locked files

…but not accepting connections from any Dolphin or Thunar (xfce) on the net.

5

zypper dup this morning → reboot → resolved for SAMBA, Wireguard still not coming up…

 # wg-quick up wg0
[#] ip link add dev wg0 type wireguard
/usr/bin/wg-quick: line 32: /usr/bin/ip: Permission denied
Unable to access interface: No such device
[#] ip link delete dev wg0
/usr/bin/wg-quick: line 32: /usr/bin/ip: Permission denied
6

Too early: After some minutes samba fails again, no connection possible anymore…

But it worked after the reboot:

~> sudo smbstatus
[sudo] password for root: 

Samba version 4.23.7-git.473.9487af01c24SUSE-oS16.9-x86_64
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing              
----------------------------------------------------------------------------------------------------------------------------------------
4402    (auth in progress)        1x.x.x.x (ipv4:1x.x.x.x:49822)          SMB3_11           -                    -                    
4402    nobody       nobody       1x.x.x.x (ipv4:1x.x.x.x:49822)          SMB3_11           -                    -                    
4387    nobody       nobody       1y.y.y.y (ipv4:1y.y.y.y:48624)            SMB3_11           -                    -                    
4388    nobody       nobody       1y.y.y.y (ipv4:1y.y.y.y:48626)            SMB3_11           -                    -                    

Service      pid     Machine       Connected at                     Encryption   Signing     
---------------------------------------------------------------------------------------------
fx4         4402    1x.x.x.x     Mon May 18 10:57:47 2026 CEST    -            -           
fx4         4388    1y.y.y.y  Mon May 18 10:57:32 2026 CEST    -            -           
fx4         4387    1y.y.y.y  Mon May 18 10:57:32 2026 CEST    -            -           


Locked files:
Pid          User(ID)   DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
4387         65534      DENY_NONE  0x1         RDONLY     NONE             /mnt/md0/fx4   .   Mon May 18 10:57:32 2026
7

Are you running SELinux? If so, are there any SELinux-related errors?

ausearch -m avc,user_avc -ts boot
8 
# ausearch -m avc,user_avc -ts boot

.............
time->Mon May 18 11:02:30 2026
type=AVC msg=audit(1779094950.450:712): apparmor="DENIED" operation="exec" class="file" profile="wg-quick" name="/usr/sbin/ip" pid=4620 comm="wg-quick" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
----
time->Mon May 18 11:02:30 2026
type=AVC msg=audit(1779094950.450:713): apparmor="DENIED" operation="open" class="file" profile="wg-quick" name="/usr/sbin/ip" pid=4620 comm="wg-quick" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
----
time->Mon May 18 11:02:30 2026
type=AVC msg=audit(1779094950.451:714): apparmor="DENIED" operation="exec" class="file" profile="wg-quick" name="/usr/sbin/ip" pid=4621 comm="wg-quick" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
----
time->Mon May 18 11:02:30 2026
type=AVC msg=audit(1779094950.451:715): apparmor="DENIED" operation="open" class="file" profile="wg-quick" name="/usr/sbin/ip" pid=4621 comm="wg-quick" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
----
time->Mon May 18 11:02:30 2026
type=AVC msg=audit(1779094950.455:716): apparmor="DENIED" operation="exec" class="file" profile="wg-quick" name="/usr/sbin/ip" pid=4624 comm="wg-quick" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
----
time->Mon May 18 11:02:30 2026
type=AVC msg=audit(1779094950.455:717): apparmor="DENIED" operation="open" class="file" profile="wg-quick" name="/usr/sbin/ip" pid=4624 comm="wg-quick" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

which has no real priority for TW

https://bugzilla.opensuse.org/show_bug.cgi?id=1265394

…it’s just some random tunnel issue.

9

Looks like you are not running SELinux but apparmor.

Did you try the updated apparmor profile given in the bugreport you mentioned?

10

I do zypper dup, no config-tinkering of any kind…

The samba problem is at least as annoying as the wg f*** **.

But maybe related? over wg there are two nfs shares to be mounted on boot, maybe the fail results in samba fail? No idea…

11

Is Samba configured to share those NFS locations? Because if it is than you could see samba hang waiting for them to become available.

But you haven’t shown any information about smb’s hang, just said that it does.

12

No, the NFS shares are not in the samba config. Can’t show anything, as there isn’t anything to show.

After a fresh reboot the samba share is reachable for some minutes:

# journalctl -xeu smb

May 18 18:24:39 dellscsi80722 systemd[1]: Starting Samba SMB Daemon...
░░ Subject: A start job for unit smb.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit smb.service has begun execution.
░░ 
░░ The job identifier is 331.
May 18 18:24:39 dellscsi80722 update-samba-security-profile[2538]: /usr/share/samba/update-samba-security-profile: line 218: /sbin/selinuxenabled: No such file or directory

…then it becomes unavailable from Dolphin/Thunar:

# journalctl -xeu smb
May 18 18:24:39 dellscsi80722 systemd[1]: Starting Samba SMB Daemon...
░░ Subject: A start job for unit smb.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit smb.service has begun execution.
░░ 
░░ The job identifier is 331.
May 18 18:24:39 dellscsi80722 update-samba-security-profile[2538]: /usr/share/samba/update-samba-security-profile: line 218: /sbin/selinuxenabled: No such file or directory
May 18 18:29:39 dellscsi80722 systemd[1]: smb.service: start operation timed out. Terminating.
May 18 18:29:39 dellscsi80722 systemd[1]: smb.service: Failed with result 'timeout'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The unit smb.service has entered the 'failed' state with result 'timeout'.
May 18 18:29:39 dellscsi80722 systemd[1]: Failed to start Samba SMB Daemon.
░░ Subject: A start job for unit smb.service has failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit smb.service has finished with a failure.
░░ 
░░ The job identifier is 331 and the job result is failed.
May 18 18:29:39 dellscsi80722 systemd[1]: smb.service: Consumed 3.254s CPU time over 5min 380ms wall clock time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The unit smb.service completed and consumed the indicated resources.
13

Increase the logging level.

14

I guess your system must be running AppArmor. I’ve recently learned that OpenSUSE now uses SELinux by default, but it won’t migrate existing installations away from AppArmor automatically to avoid breakage. Somewhat ironically, it appears that due to AppArmor integration no longer being sufficiently tested by the OpenSUSE team, one of the latest updates has caused some truly massive breakage as a result of mistakes and/or omissions in the new AppArmor profiles.

A profile defines what a program can do, and if it does not say so explicitly, it means AppArmor will deny access unless the corresponding profile is switched to “complain” mode. In this mode, any action that would violate the security policy is logged but still allowed through.

Here’s a list of programs I’ve found to no longer work properly unless AppArmor is completely disabled (not recommended!), or the corresponding profile is somehow tweaked or switched to “complain” mode. Some of these issues seem to have already been reported on Bugzilla. Should I bother reporting the rest? I highly suspect this is only the tip of the proverbial iceberg…

1. Samba

Symptoms: the commands sudo systemctl start smb, sudo systemctl start nmb time out, services do not start.

Solution: First, activate complain mode:

sudo aa-complain /etc/apparmor.d/usr.sbin.smbd
sudo aa-complain /etc/apparmor.d/usr.sbin.nmbd

However, only in this particular case it is not enough! /var/log/audit/audit.log showed that everything was allowed, but something was still wrong. Notice these: “Failed name lookup - disconnected path”:

type=AVC msg=audit(1779136299.639:3892): apparmor="ALLOWED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="smbd" name="systemd/journal/dev-log" pid=7275 comm="smbd" requested_mask="w" denied_mask="w" fsuid=1000 ouid=0
type=AVC msg=audit(1779136299.639:3893): apparmor="ALLOWED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="smbd" name="systemd/journal/dev-log" pid=7275 comm="smbd" requested_mask="w" denied_mask="w" fsuid=1000 ouid=0
type=AVC msg=audit(1779136493.320:428): apparmor="ALLOWED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="smbd" name="systemd/notify" pid=3741 comm="smbd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
type=AVC msg=audit(1779136493.338:429): apparmor="ALLOWED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="smbd" name="systemd/notify" pid=3741 comm="smbd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
type=AVC msg=audit(1779136591.444:528): apparmor="ALLOWED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="smbd" name="systemd/notify" pid=4673 comm="smbd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
type=AVC msg=audit(1779136591.457:529): apparmor="ALLOWED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="smbd" name="systemd/notify" pid=4673 comm="smbd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
type=AVC msg=audit(1779136684.053:585): apparmor="ALLOWED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="smbd" name="systemd/journal/dev-log" pid=5584 comm="smbd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0

With some help from Google and its AI assistant, I’ve found that the workaround is to fix the profiles manually. In /etc/apparmor.d/usr.bin.smbd, change the following line:

profile smbd /usr/{bin,sbin}/smbd flags=(complain) {

to:

profile smbd /usr/{bin,sbin}/smbd flags=(complain, attach_disconnected) {

Similarly, in /etc/apparmor.d/usr.bin.nmbd, change the following line:

profile nmbd /usr/{bin,sbin}/nmbd flags=(complain) {

to

profile nmbd /usr/{bin,sbin}/nmbd flags=(complain, attach_disconnected) {

Finally, reload AppArmor profiles by running sudo systemctl reload apparmor, and Samba should start up normally.

2. PHP-FPM

Symptoms: the command sudo systemctl start php-fpm times out. The PHP-FPM service does not start.

Solution: Activate complain mode: sudo aa-complain /etc/apparmor.d/php-fpm, and it should work normally.

3. Transmission (headless)

Symptoms: the command sudo systemctl start transmission-daemon times out. The Transmission service does not start and produces log messages similar to the following:

ERR variant.cc:587 Couldn't save '/var/lib/transmission/.config/transmission-daemon/settings.json': Permission denied (13) (variant.cc:587)
ERR variant.cc:587 Couldn't save '/var/lib/transmission/.config/transmission-daemon/bandwidth-groups.json': Permission denied (13) (variant.cc:587)
ERR utils.cc:159 Couldn't read '/var/lib/transmission/.config/transmission-daemon/queue.json': Permission denied (13) (utils.cc:159)
ERR utils.cc:159 Couldn't read '/var/lib/transmission/.config/transmission-daemon/settings.json': Permission denied (13) (utils.cc:159)

Solution: The only solution that worked for me is to activate complain mode: sudo aa-complain /etc/apparmor.d/transmission.

I’ve also attempted to tweak the profile by allowing read-write access to /var/lib/transmission, and could see no “DENIED” messages in /var/log/audit/audit.log, but still could not get it working. It does actually start up, but systemd is unable to receive a notification and terminates the process after a timeout.

4. ProFTPd

Symptoms: the service might not start with an error message: fatal: AuthUserFile: unable to use /etc/proftpd/auth/passwd: Permission denied on line XX of '/etc/proftpd/proftpd.conf'. Even if it does, some features like the scoreboard might not work.

Solution: Activate complain mode: sudo aa-complain /etc/apparmor.d/proftpd, and it should work normally.

5. who

Symptoms: the who command does not produce any output.

Solution: Create a new file: /etc/apparmor.d/local/who with the following content:

"/run/systemd/sessions/*" r,
"/dev/pts/" r,

Then, reload AppArmor profiles by running sudo systemctl reload apparmor, and who should start working normally.

5. lsusb

Symptoms: lsusb errors out with a message: unable to initialize usb spec.

Solution: Activate complain mode: sudo aa-complain /etc/apparmor.d/lsusb, and it should work normally.

Note that this issue has been reported on Bugzilla, and should be fixed automatically in the next update. When it happens, you can switch back to enforce mode by running sudo aa-enforce /etc/apparmor.d/lsusb.

Very interestingly, rolling back to a previous snapshot did fix some of the above, like who and lsusb, but not the rest. I have no idea why, but it doesn’t matter in the long term anyway since the only proper solution is fixing the profiles upstream.

15

If nobody reports it, nothing will get fixed. Should be logic.

That is quite some FUD. It needs some understanding what openQA is and what scenarios it can cover. It isn’t possible to catch all issues and missfunctions with openQA. Package incompatibilities and stuff like that are quite possible to catch, but not 100% of the functions of the package.

It is quite some complaining on a high niveau. Other distributions don’t even have such tools like openQA. On some distributions the QA team consists of 3 or 4 ppl. They install a package from the testing repo and give their go for release after they didn’t found any issues on their 3 machines. Much more ineffective as openQA used by openSUSE. And as nicely explained by one of the maintainers in the Apparmor bugreport, as long as there are only ppl which complain and are not willing to help make the openQA tests better, nothing will change. Also in the future some issues will slip through openQA. It is impossible to catch all issues.

16

It just seems to me right now that it could’ve been easier to roll back the profiles en masse with the next update in order to revert the breakage immediately, and take some time to do more testing instead of trying to deal with the oncoming torrent of bug reports by fixing them one by one. But if the latter approach is more desirable for some reason, I will of course be filing them as soon as I have the time. It is, after all, in my best interest for the OS I’m running to be as bug-free as possible.

I understand I might be acting on emotion somewhat, and I have to apologize - it did take somewhat of a toll on me having to spend extra hours to get everything back in working order. But it’s really the first time in years I’ve encountered something this big. Sure, from time to time there have always been minor issues here and there, but never anything that would suddenly cause a whole bunch of programs to cease functioning properly. While I can’t really blame anyone, especially because I’m not paying anything to use this product, this still looks like a major QA oversight to me.

17

Wasn’t enough to break update path to leap 16, now TW has to be killed?

How to turn of this AppArmor thing?

18

Note that I don’t recommend completely disabling it because it does increase the overall security of your system. But here’s what worked for me:

First, edit /etc/default/grub: find the line starting with GRUB_CMDLINE_LINUX_DEFAULT=..., and replace security=apparmor with apparmor=0.

Then, run either sudo update-bootloader, or sudo grub2-mkconfig -o /boot/grub2/grub.cfg.

Finally, reboot, and AppArmor should be disabled.

19

found it in yast, wireguard working now, samba working now.

Painful.

20

“increasing” the “security” of a system to a level that it becomes unusable for the intended purpose is, let me put it in friendly way, [bu[]s[*]].

Many thanks for the suggestion.

Found this here:

So apparently SELinux is not a simple drop-in replacement for this UnderArmor thingy.