samba - Jan 2024 - 'Permission denied' Journal entries for '/var/log/samba/log.rpcd_classic'

Hi,

This is a question about getting a Samba file server to work. I am a
newbie about Samba, however not an unexperienced Linux user. I am
using Arch Linux with Samba 4.19.3.

The reason for this question is output in the systemd Journal of the
server machine, consisting of two lines like the following (separated
here by a blank line):


[2024/01/08 10:34:11.358889,  0] ../../lib/util/debug.c:1264(reopen_one_log)

reopen_one_log: Unable to open new log file
'/var/log/samba/log.rpcd_classic': Permission denied


This pair of messages is repeated 3 times when I run ``$ smbclient -L
<host> -U <wgroup>/<user>`` on a client machine.

I experimented systematically and searched the web but couldn't find a
solution. I tried:

1.  When I 'chown' the mentioned log file to the samba user I am
authenticating as, the error disappears.

2.  I experimented with "log file = /var/log/samba/by-user/%u.log" and
"... /by-user/%U.log" but this did not yield the change of behaviour I
hoped for. "%u.log" is just used verbatim (the "%u" is not
replaced).
"%U.log" only wrote ".log", even though the abovementioned
error did
not show up. Each of the two experiments created a bunch of
directories in '/var/log/samba/by-user/'. I removed that entire
directory afterwards, and continued to experiment.

3.  I've tried to direct all log messages to the systemd Journal by
writing "logging = systemd", with no change regarding the initial
error message. Writing "logging = file at 0" inhibits *any* output,
including the error lines. So I tried "logging = systemd file at 0" in
an
attempt to direct the lines to the Journal, but not to any logging
file, however with this configuration the "Permission denied" error
reappeared.

My 'smb.conf' is currently very minimal to rule out any interference.
This is okay until I am going production; there is currently no
valuable data on the share. The 'smb.conf' content is:

[global]
server role = standalone
<logging options>
[Extern]
path = /srv/smb/extern

After each change, I restarted the entire Samba service by '#
systemctl restart smb'.  The call of '$ smbclient -L <...>' on
the
client successfully lists the "Extern" share.

I am stuck here, even though I performed searches and read quite a
bit. So any advice would be greatly appreciated.

TIA
Friedrich

On Mon, 8 Jan 2024 12:18:10 +0100
Friedrich Romstedt via samba <samba at lists.samba.org> wrote:
> Hi,
> 
> This is a question about getting a Samba file server to work. I am a
> newbie about Samba, however not an unexperienced Linux user. I am
> using Arch Linux with Samba 4.19.3.
> 
> The reason for this question is output in the systemd Journal of the
> server machine, consisting of two lines like the following (separated
> here by a blank line):
> 
> 
> [2024/01/08 10:34:11.358889,  0]
> ../../lib/util/debug.c:1264(reopen_one_log)
> 
> reopen_one_log: Unable to open new log file
> '/var/log/samba/log.rpcd_classic': Permission denied
It seems fairly obvious that whatever is trying to create the logfile
is not being allowed to by the permissions on the /var/lib/samba
directory. I use Debian, where the permissions on that directory are:

drwxr-x--- 3 root adm 4096 Jan  7 00:00 /var/log/samba/

So only 'root' is allowed to write to the directory.

If it is 'root' trying to write the log file, then I would take a look
at apparmor, that could be denying access.
 
Rowland

Hi Rowland,

Am Mo., 8. Jan. 2024 um 12:18 Uhr schrieb Friedrich Romstedt
<friedrichromstedt at gmail.com>:
>
> The reason for this question is output in the systemd Journal of the
> server machine, consisting of two lines like the following (separated
> here by a blank line):
>
>
> [2024/01/08 10:34:11.358889,  0]
../../lib/util/debug.c:1264(reopen_one_log)
>
> reopen_one_log: Unable to open new log file
> '/var/log/samba/log.rpcd_classic': Permission denied
>
> [...]
>
> 1.  When I 'chown' the mentioned log file to the samba user I am
> authenticating as, the error disappears.
It is indeed fairly obvious, that the process which is attempting to
write to '/var/log/samba/log.rpcd_classic' is probably belonging to
the nonprivileged used, just as you said. This is the less challenging
observation. However, I did not find a way to solve the problem
arising from this situation, this is why I am writing to the list in
the first place.

On my box, the permissions for '/var/log/samba/' are 'root:root
755',
those for the files within that directory all 'root:root 644'. I
didn't tinker around with these.

It would make the error message most probably disappear when I would
make the log files world-writable. However, this would not appear to
me to be a real solution.

What are the permission bits for the log files within
'/var/log/samba/' on Debian?

I can guess two approaches here: 1) Making smbd prevent from giving up
its 'root' privilege, or 2) Finding a way to receive the logs without
rw access to log files for the unprivileged user.

However, for neither of both ideas I could find a way to go studying
them. This is why I'm writing. I hope there is some third way emerging
from our discussion.

For instance, I do not understand why 'logging = systemd file at 0'
yields the error message reported on in the beginning, while just
'logging = file at 0' makes the error not pop up. I would expect that
file 'file at 0' prevents log file writing in both cases.

The second approach I reported on, using '%u' or '%U', pointing
to the
option to open only part of the log files for 'world' to be writable,
also didn't succeed, because '%U' evaluated to the empty string for
the root master process (effectively writing to a dot-file '.log' when
'%U.log' was requested), and '%u' just wasn't substituted.
There might
be room for improvement in this direction, however I do not know which
steps to take next.

Thank you so far for your reply!

Looking forward,
Friedrich


P.S.: 'apparmor' is not installed on my system