On Tue, Jan 20, 2026 at 13:32:23 -0700, Casey Deccio wrote: > >> 2026-01-20T13:07:09.725140-07:00 quartet rsyslogd: error during config > >> processing: omfile: creating parent directories for file > >> '/home/foobar/foobar.log' failed: Read-only file system [v8.2504.0 try > >> https://www.rsyslog.com/e/2207 ]
> > The answer to your issue is in `systemctl cat rsyslog.service`, i.e. > > /usr/lib/systemd/system/rsyslog.service. > > Thank you! In all my searching, it never occurred to me that it was systemd > and not rsyslog. As a general rule, if a daemon is complaining about "permission denied" or "read-only file system", when the directories in question are not restricted by permissions and the file system in question is not actually read-only, there's a high chance it's a restriction imposed by AppArmor or by the daemon's systemd unit file. This kind of issue happens *frequently* when people try to store files in a different place than normal, either by mounting a file system in an uncommon place, or creating a symbolic link to point a directory to a different location, etc. The default restrictions in Debian's AppArmor and systemd configuration files are often designed to work with standard directories, and prevent writing in any other place. This is done for security purposes (in case an exploit is found, the exploited daemon will be capable of reduced damages), and these restrictions generally become tighter over time. Long story short: if you change the locations where files are being stored, and you get an error about permissions or read-only-ness, look for an AppArmor profile or systemd unit file restriction that may be working against you.
