Solved ufw doesn't stay on after reboot

[ron.alan]

As the title states, the firewall doesn't stay on after a reboot. I ran sudo systemctl enable --now ufw.service and get the following:

sudo systemctl enable --now ufw.service
/usr/bin/systemctl:1541: SyntaxWarning: invalid escape sequence '\w'
  expanded = re.sub("[$](\w+)", lambda m: get_env1(m), cmd.replace("\\\n",""))
/usr/bin/systemctl:1543: SyntaxWarning: invalid escape sequence '\w'
  new_text = re.sub("[$][{](\w+)[}]", lambda m: get_env2(m), expanded)
/usr/bin/systemctl:1628: SyntaxWarning: invalid escape sequence '\w'
  cmd3 = re.sub("[$](\w+)", lambda m: get_env1(m), cmd2)
/usr/bin/systemctl:1631: SyntaxWarning: invalid escape sequence '\w'
  newcmd += [ re.sub("[$][{](\w+)[}]", lambda m: get_env2(m), part)

What are the syntax warnings? I'm assuming that has something to do with the problem. It does turn it on, but it doesn't survive a reboot.

BTW, this is on a fresh install of PCLinuxOS-Debian edition.

 

[PuppyHome]

Have you tried

sudo ufw enable

This is the usual command to enable it at startup.
After rebooting check

sudo ufw status

to see if it's running.

 

[osprey]

As the title states, the firewall doesn't stay on after a reboot. I ran sudo systemctl enable --now ufw.service and get the following:

sudo systemctl enable --now ufw.service
/usr/bin/systemctl:1541: SyntaxWarning: invalid escape sequence '\w'
  expanded = re.sub("[$](\w+)", lambda m: get_env1(m), cmd.replace("\\\n",""))
/usr/bin/systemctl:1543: SyntaxWarning: invalid escape sequence '\w'
  new_text = re.sub("[$][{](\w+)[}]", lambda m: get_env2(m), expanded)
/usr/bin/systemctl:1628: SyntaxWarning: invalid escape sequence '\w'
  cmd3 = re.sub("[$](\w+)", lambda m: get_env1(m), cmd2)
/usr/bin/systemctl:1631: SyntaxWarning: invalid escape sequence '\w'
  newcmd += [ re.sub("[$][{](\w+)[}]", lambda m: get_env2(m), part)

What are the syntax warnings? I'm assuming that has something to do with the problem. It does turn it on, but it doesn't survive a reboot.

BTW, this is on a fresh install of PCLinuxOS-Debian edition.

The syntax warnings are just warnings, rather than errors, so they wouldn't be expected to neutralise the functioning of the ufw service. I ran the error message through AI (perplexity) and the result is in the spoiler. Its comment was that it's just "noisy output - no functional impact", which is consistent with my experience with these sorts of messages.

On the question of the ufw service not enabling after reboot, you could check what the preset is. If the preset is disabled, that can be altered to enabled. To check the preset, run:

systemctl status ufw.service

and check the line:

Loaded: loaded (/usr/lib/systemd/system/ufw.service; enabled; preset: enabled)

This output shows that the preset is enabled, which means that by default it'll run if it's enabled and exists on the system.

If the output is: "preset: disabled", that can be changed by adding the following configuration as root or sudo, to the file: /usr/lib/systemd/system/system-preset/90-systemd.preset

enable ufw.service

Then reboot, check the preset and check to see if ufw has started.

Another means of configuring ufw to start on boot is to create a link in the /etc/systemd/system directory to the ufw service. That can be done as root or sudo by running the following command from within the
/etc/systemd/system directory:

ln -s /usr/systemd/system/ufw.service ufw.service

Then check the list of files in the directory to see if the link has been created, and reboot to check again whether ufw has started.

Either of the above can be done singularly or together.

If none of this works, it's all reversible.

Spoiler: AI output

These SyntaxWarnings occur in the systemctl command (written in Python) due to invalid escape sequences like \w in regex patterns.
Warning Meaning

Python 3.12+ flags \w (and similar regex shorthand like \d) as invalid when used in regular strings, since \w isn't a standard string escape—it's regex syntax. The code should use raw strings (r"...") or escape the backslash (\\w) to silence this. These warnings appear on every systemctl invocation, including your ufw.service command.
Consequences

Currently, just noisy output—no functional impact, as Python still interprets \w as literal w. In future Python versions, invalid escapes will raise SyntaxError, potentially breaking systemctl. This is a known Debian/systemd bug, reported across distros like sid/bookworm.
Fixes

Wait for upstream patch: systemd developers are aware; update your system (sudo apt update && sudo apt upgrade systemd) when fixed.

Suppress warnings temporarily: Prefix with PYTHONWARNINGS=ignore sudo systemctl enable --now ufw.service.

Raw string mod (advanced): Edit /usr/bin/systemctl to prepend r before affected regex strings (e.g., r"[$](\w+)"), but avoid this—it's not recommended and will revert on updates.

 

[johnblackwood1]

run sudo apt update && sudo apt purge ufw then run sudo apt install ufw and after that you enable the firewall and reboot the os. than once the OS is booted and your logged in enter in systemctl status ufw.service like what osprey told you to do. i am so sorry if this does not work im not really that good at linux but im good at scripting. have a great day ron.alan

 

[GatorsFan]

on Debian it is

sudo enable uwf

also try installing gufw it is the GUI for UWF

 

[ron.alan]

Yes I am well aware of sudo ufw enable. That would enable it alright, but it wouldn't survive a reboot (why, I haven't a clue).

If the output is: "preset: disabled", that can be changed by adding the following configuration as root or sudo, to the file: /usr/lib/systemd/system/system-preset/90-systemd.preset

Not sure this would work on PCLinuxOS Debian edition, as PCLOS-Deb doesn't use systemd.

Anyway, I did get it solved. I had to add service ufw start to the /etc/rc.local file. I got it straight from the PCLOS-Debian edition maintainer.

 

[osprey]

Yes I am well aware of sudo ufw enable. That would enable it alright, but it wouldn't survive a reboot (why, I haven't a clue).

Not sure this would work on PCLinuxOS Debian edition, as PCLOS-Deb doesn't use systemd.

Anyway, I did get it solved. I had to add service ufw start to the /etc/rc.local file. I got it straight from the PCLOS-Debian edition maintainer.

Sorry to have been misled by the references to debian and systemctl in post #1. I should have asked whether you'd actually introduced systemd to PCLOS-debian, which would have made sense of the systemctl command. Nevermind. Glad you got it going.

 

[MikeWalsh]

@osprey :-

The Chromium browser codebase does pretty much the same thing. Anyone who has ever started Chromium OR its many 'clones' from the terminal will be convinced that their browser is on the point of melt-down, and will explode at any moment.....

Much of what is displayed IS just 'warnings'......because YOUR runtime environment doesn't precisely match that under which it was compiled. That said, even running it on the same system under which it was compiled STILL produces a ton of output. That's the nature of the beast.

The simple fact here is the decision was taken, very early in the development process - around 20 years ago, now - to run a live, ongoing 'debug' session concurrently with the browser GUI.....all the time it's running.

The idea was primarily to make it easy for developers to see exactly what the browser is doing at any given moment. Truth to tell, it DOES make troubleshooting very much easier when things misbehave; you have to remember, here, that browsers are highly complex pieces of software, and trying to track down issues IF the underlying code is obscured, or "hidden" would be almost impossible.

Hence, why these browsers are known for being very "noisy" in the terminal. And before anybody says it, the 'zilla-based browsers are just the same....AND the various WebKit-based ones, too.

They ALL do this.

(shrug...)


Mike.

 

[Condobloke]

So, to 'turn the lights on here' ......

PCLinuxOS-Debian edition.

and the firewall spoken of is ufw .....UncomplictaedFireWall

Does this point to an unnecessary complication in Debian.... such that if a new user achieves satisfaction that he/she has turned the firewall on, and is now protected by that firewall, only to discover some time later that this not the case and the rotten thing did not survive the first reboot ! ?

from : https://askubuntu.com/questions/22667/why-is-the-firewall-disabled-by-default

Out of the box, Ubuntu ships with no TCP or UDP ports open, hence the belief that there's no reason to run Uncomplicated Firewall (ufw) by default. I agree, though, that having ufw disabled is a strange decision. My reasoning being that inexperienced users are feasibly going to install things like Samba, Apache and such like as they experiment with the system put before them. If they don't understand the implications of this, they will expose themselves to malicious behaviour on the internet.

Example - I've got my laptop configured with Samba which is fine in my home network protected with WPA2. But if I take my laptop to a Starbucks, I might not think anything of it, but that laptop is now advertising my shares to all and sundry. With a firewall, I can restrict my samba ports to only my home server or peer devices. No need to worry as much now about who might be trying to connect to my laptop. Same goes for VNC, SSH, or a huge number of other useful services my laptop might be running, or trying to connect to.


Ubuntu takes a very on/off approach to certain elements of security, a philosophy I can't agree with. Security might be technically on or off, but by layering elements of security over one another, you end up with a better system. Sure, Ubuntu's security is good enough for a large number of use cases, but not all.


Bottom line, run ufw. Better safe than sorry.


Uncomplicated Firewall has a number of graphical front ends, but the simplest is Gufw.

-------------------------------------------

Given and acknowledged that this topic was first posted in
Asked 15 years, 3 months ago

and the Answer I post above is from 2011

it has to be high time for the so-called powers that be to drag their heads out of their &&&*&.....and take a fresh look at the influx of new users, who, if they are not warned in BIG CAPITAL LETTERS to enable the firewall, will be quite likely the subject of "" they will expose themselves to malicious behaviour on the internet.""....(thats from the answer dated 2011.....15 years ago ! )

Better still..ENABLE the ufw by DEFAULT. If some clown wishes to turn it off, then that is a conscious action, and they get to wear the consequences of that action.

 

[ron.alan]

Does this point to an unnecessary complication in Debian.... such that if a new user achieves satisfaction that he/she has turned the firewall on, and is now protected by that firewall, only to discover some time later that this not the case and the rotten thing did not survive the first reboot ! ?

I'd say not, as I have never had this issue with Devuan. Seems to me to be only specific to PCLOS Debian edition. It's strange, yes.

And I agree, run the firewall. There's no reason not to. Also I agree that it should just already be enabled by the OSs out of the box.

 

[ron.alan]

Got this fixed soon after the last post here, sorry to update this thread just now. The fix was, as root, to put "service ufw start" into the file "/etc/rc.local".

EDIT
I guess I'm losing my memory. I already posted the fix in post #6. I don't know why I didn't tag it as solved back then.