User Journal ACL problem after upgrade

[gwaitsi]

Since upgrading to Cobia, I am seeing the below entry for each of the users

systemd-journald[516]: Failed to set ACL on /var/log/journal/d7f7614ae8894a0e80dadfcb72bf2018/user-1004.journal, ignoring: Operation not supported

 

[anodos]

Since upgrading to Cobia, I am seeing the below entry for each of the users

systemd-journald[516]: Failed to set ACL on /var/log/journal/d7f7614ae8894a0e80dadfcb72bf2018/user-1004.journal, ignoring: Operation not supported

ACL support is disabled by default on boot-pool. This is in accordance with various STIG guidelines that ACL support not be enabled on various system paths. Perhaps we need to enable here. Who is uid 1004? Is that something running in an app?

 

[gwaitsi]

i didn't set this up, it was always like that from 11.x onwards. so this is a change. surely, they should have cleaned this up. and where should the journal be saved now? why was it not re-directed as part of the upgrade process?

 

[anodos]

i didn't set this up, it was always like that from 11.x onwards. so this is a change. surely, they should have cleaned this up. and where should the journal be saved now? why was it not re-directed as part of the upgrade process?

Reviewing the systemd log the ACL entry is supposed to ensure the user can read the log file. Since mode for these files is already 755 I doubt there's anything to this other than log spam. Are you seeing actual impact to services?

 

[gwaitsi]

i deleted all the user related journal entries and then rebooted. It seems to have created all new user files and they do not appear to be giving the above error, so far.

 

[gwaitsi]

so, deleting the files did not help. seems the system as a problem - but this has only occured since the upgrade to cobia

Code:

Nov  4 08:17:01 nas systemd-journald[513]: Data hash table of /var/log/journal/d7f7614ae8894a0e80dadfcb72bf2018/system.journal has a fill level at 75.0 (8535 of 11377 items, 6553600 file size, 767 bytes per hash table item), suggesting rotation.
Nov  4 08:17:01 nas systemd-journald[513]: /var/log/journal/d7f7614ae8894a0e80dadfcb72bf2018/system.journal: Journal header limits reached or header out-of-date, rotating.
Nov  4 08:17:01 nas systemd-journald[513]: Failed to set ACL on /var/log/journal/d7f7614ae8894a0e80dadfcb72bf2018/user-1004.journal, ignoring: Operation not supported
Nov  4 08:17:01 nas systemd-journald[513]: Failed to set ACL on /var/log/journal/d7f7614ae8894a0e80dadfcb72bf2018/user-1001.journal, ignoring: Operation not supported

 

[artstar]

Joining in on this conversation to say that I am experiencing the same thing and oddly, some 19 hours since I performed the upgrade, my system crawled down to an almost grinding halt. None of my shares were accessible and the web UI seemed to load the login page but could not get beyond that. Couldn't even ssh in to diagnose what was going on and no glaring clues in the syslog stream other than it stopped dead after some smbd activity.

Performed a soft shutdown via IPMI and it took approximately 30 minutes for all services to timeout and be forcibly killed before powering down. System back to normal after powering up but this journald notification is happening for me too.

That being said, I don't believe the two issues to be related, given that journalctl --disk-usage reveals only about 34MB (hah!) so those errors are most likely just noise, more than anything else. This is in 23.10.0.1.

 

[Slovak]

Upgraded from latest TrueNAS CORE to Cobia several days back and getting the same log message:

Code:

systemd-journald[590]: /var/log/journal/657dd9fd636b452abee7765e7e07daa9/system.journal: Journal header limits reached or header out-of-date, rotating.
systemd-journald[590]: Failed to set ACL on /var/log/journal/657dd9fd636b452abee7765e7e07daa9/user-1001.journal, ignoring: Operation not supported
systemd-journald[590]: Failed to set ACL on /var/log/journal/657dd9fd636b452abee7765e7e07daa9/user-1003.journal, ignoring: Operation not supported

 

[lemba]

I had the same. My solution was:
Go to "Credentials"->"Local Users" and search for the corresponding user-id (UID).
Click on "Edit" and go to "User ID and Groups".
Click on "Auxiliary Groups" and add "systemd-journal"
Worked for me...

 

[anodos]

I had the same. My solution was:
Go to "Credentials"->"Local Users" and search for the corresponding user-id (UID).
Click on "Edit" and go to "User ID and Groups".
Click on "Auxiliary Groups" and add "systemd-journal"
Worked for me...

That's not a good solution. You're elevating privileges of your local users to remove a benign log message.

 

[DGTM]

That's not a good solution. You're elevating privileges of your local users to remove a benign log message.

So what is the correct solution?

Joining the club, I began to see this as well:

Code:

Feb  8 00:00:02 truenas syslog-ng[2344]: Configuration reload request received, reloading configuration;
Feb  8 00:00:02 truenas syslog-ng[2344]: Configuration reload finished;
Feb  8 08:32:53 truenas systemd-journald[443]: Data hash table of /var/log/journal/e681036496f84ba6b8d2e16d9b309930/system.journal has a fill level at 75.0 (8533 of 11377 items, 6553600 file size, 768 bytes per hash table item), suggesting rotation.
Feb  8 08:32:53 truenas systemd-journald[443]: /var/log/journal/e681036496f84ba6b8d2e16d9b309930/system.journal: Journal header limits reached or header out-of-date, rotating.
Feb  8 08:32:53 truenas systemd-journald[443]: Failed to set ACL on /var/log/journal/e681036496f84ba6b8d2e16d9b309930/user-3000.journal, ignoring: Operation not supported

 

[Master-DXT]

Same issue here! At first, I occasionally get prompted, now every single day.

 

[m3ki]

Same issue here after upgrade to cobia

 

[smithj33]

Just upgraded from Core to Cobia and have the same. 1000 is my root use from Core.

Code:

Mar 25 09:39:54 tesseract-2-nas systemd-journald[542]: Failed to set ACL on /var/log/journal/327341f888494309885678c6455a1ffa/user-1000.journal, ignoring: Operation not supported