Reports -> Samba audit: no records

NethServer Version: 7RC1
Module: File server - Samba audit

Hi guys,

I have the following situation: nothing is shown in Reports -> Samba audit window, even there are records in Administration -> Log viewer: /var/log/smbaudit.log

Does anyone else have this problem?


I don’t have this problem on NS 7b2.

For me, with a fresh installation of NS7rc1, it seems to work…

I have installed from scratch for 4 times!

Sorry, my fault.

I see the log on “Samba audit” only until 21/10/2016

The today log is present in /var/log/smbaudit.log but the data aren’t present in “Samba audit”

It can be forced from CLI:

But it is supposed to parse the logs on a daily basis (nightly?).
The manual says the parsing can be forced from web-ui, but if it’s the reload link (unsure) it does not work for me.

1 Like

The command that you wrote seems to work.

I tried to click on “update/reload” link in “samba audit” but that doesn’t work.

Agree !

There’s a script /etc/logrotate.d/smbaudit where’s the command is executed

/var/log/smbaudit.log {
    rotate 5
    create 640 root root

So it’s possible that the database is updated overnight

1 Like

Already tried!
About two days!

The last installation of NS was yesterday.
Nothing over the night

I will check over two hours.
I’m on the road to home now.

Anyway, this must be “live”.

Usually, nightly update is about 3 am on my rc1, but manual reload is always a fail.

I’m home now, in front of my laptop.

As I said, on NS 7b2 everything worked fine (even shared folder access, R&W, as guest; but this will be another topic).

On NS 7b2, from GUI, if I press “Reload” I can see the last records about the shared folder access. In NS 7RC1, nothing happen.

Samba audit must be in real time, not overnight.

Here are the two scripts for logrotate: one is from test machine with NS 7b2 and one is from the new NS 7RC1. There are the same.


After two days from installation of the NS 7RC1 as DC/AD/File server, in this morning I see this in Samba Audit window!
The update was at 03:49 AM, as @fasttech said. Nothing if I press “Reload”.

I still think that is not how supposed to work the Samba Audit module.
As system administrator, I should see everything in real time.
IMO, after I have pressed “Reload”, I should see also the latest actions about file sharing access, not only a refresh after a search action in this window.


Stupid question: if I change in /etc/logrotate.d/smbaudit “daily” with “minute”, the update will be after every minute?

No, acording this:
only daily, weekly, monthly, yearly.

Can be used this?
-f, --force
Tells logrotate to force the rotation, even if it doesn’t think this is necessary. Sometimes this is useful after adding new entries to a logrotate config file, or if old log files have been removed by hand, as the new files will be created, and logging will continue correctly.”


This module, as principle of operation, cannot be adapted and used for searching in other log files (email log, …)? Except, of course, “the update”. Should be in real time. Something like a trigger: when is something new in /var/log/…

Samba audit was an old dead project ( based on Samba 3.2 if I remember correctly.
The original software was a VFS samba module, the module was writing a new query directly into MySQL for each operation of files.
The log was written in real time but as soon as as a couple of clients where connected, the whole Samba was slowed down waiting for I/O on MySQL db.

For a while I maintained a fork (slow as hell) for new releases of Samba, but it was too much work.
The new solution is based on full_audit VFS module which writes to a log file.
Each night, the logrotate parses the logs and copy it to a MySQL table.

In short:

  • logs are not in real time
  • the “Reload” button must work

In NS 6 the web interface is using perlsuid which isn’t available on NS 7.
I think there is a bug in file mode, can someone please try this fix? (not tested):

chmod 0755 /usr/bin/
chmod 0440 /etc/sudoers.d/samba-audit

Thanks for such detailed insights :+1:

1 Like

Sorry, but I have no time to dig into it right now.

What we basically need to do is execute this script /usr/bin/ using sudo via logrotate.

Maybe the behavior of logrotate changed a bit?

After the chmod (no problem if the first one failed), try to hit the “Reload” button :wink:

I did it! Nothing change!
Maybe sometime …

Anyway, thank you!

1 Like