[Samba] samba ad integrated file server Permission denied

[Markus Huether]

Hello,
I have solved the problem and found out who triggers the log entries 
with access denied at 5:12 a.m.
The command
“id -un 2001103” resolves the UID 2001103 into the user. In my case, it 
was a Windows client that attempted to scan the “basisordner” directory 
for viruses with Windows Defender at exactly 5:12 a.m.
I disabled the trigger in Task Scheduler and the log entries on the file 
server are gone.

I would like to thank Rowland very much for his persistence in helping me.

Best regards,
Markus

Am 23.11.25 um 13:20 schrieb Rowland Penny via samba:
> On Sun, 23 Nov 2025 12:58:20 +0100
> Markus Huether via samba<samba at lists.samba.org> wrote:
>
>> I have no idea,
>> because I haven't seen the output of 'getfacl
>> /mnt/volume1_daten/basisordner'
>>
>> Here is the output of getfacl from the directory
>> /mnt/volume1_daten/basisordner.
>>
>> root at fs1:/mnt/volume1_daten# getfacl -R
>> /mnt/volume1_daten/basisordner/ |more
>> getfacl: Removing leading '/' from absolute path names
>> # file: mnt/volume1_daten/basisordner/
>> # owner: root
>> # group: domain\040users
>> # flags: --t
>> user::rwx
>> user:root:rwx
>> user:administrator:rwx
>> user:domain\040users:r-x
>> group::r-x
>> group:administrator:rwx
>> group:domain\040users:r-x
>> mask::rwx
>> other::---
>> default:user::rwx
>> default:user:root:rwx
>> default:user:administrator:rwx
>> default:group::---
>> default:group:administrator:rwx
>> default:group:domain\040users:---
>> default:mask::rwx
>> default:other::---
>>
> That just confirms what I said, members of Domain Computers have no
> permissions on the share and the log message is just stating that 'fs1'
> cannot traverse to the shares directory. Now as to why it is trying to
> traverse to the share is another question. I personally wouldn't really
> worry about it, if it just happens once a day, if was happening a lot
> more often, then I would worry.
>
> Rowland
>
>
>
>
>
>> I set the rights for the “basisordner” when installing the file
>> server using the following commands:
>>
>> sudo chmod 1770 /mnt/volume1_daten/basisordnersudo chgrp "domain
>> users"mnt/volume1_daten/basisordner
>>
>> Is that correct? It should be, as the file server then works with the
>> rights assignment via the RSAT tools.
>> I will continue to investigate who accessed the system at 5:15 a.m.
>>
>> Markus
>>
>>
>> Am 18.11.25 um 16:23 schrieb Rowland Penny via samba:
>>> On Tue, 18 Nov 2025 14:45:52 +0100
>>> Markus Huether via samba<samba at lists.samba.org> wrote:
>>>
>>>> rowland at devstation:~$ getent passwd devstation$
>>>> devstation$:*:12657:10515::/home/devstation_:/bin/bash
>>>>
>>>> But if I only have one uid, getent doesn't help me. I have already
>>>> checked all users and computers stored in AD with getent.
>>>>
>>>>
>>>> If I run 'cat /etc/cron.d/sysstat', I get this:
>>>>
>>>> # The first element of the path is a directory where the debian-sa1
>>>> # script is located
>>>> PATH=/usr/lib/sysstat:/usr/sbin:/usr/sbin:/usr/bin:/sbin:/bin
>>>>
>>>> # Activity reports every 10 minutes everyday
>>>> 5-55/10 * * * * root command -v debian-sa1 > /dev/null &&
>>>> debian-sa1 1 1
>>>>
>>>> # Additional run at 23:59 to rotate the statistics file
>>>> 59 23 * * * root command -v debian-sa1 > /dev/null && debian-sa1
>>>> 60 2
>>>>
>>>> I get the same result here. The cron runs every 10 minutes and
>>>> additionally at 11:59 p.m. However, I always receive the syslog
>>>> entries at 5:15 a.m. and only then. So this has nothing to do with
>>>> these cron entries.
>>>>
>>> I now think that the cron entry is a blind alley, as I said, it
>>> appears to be an 'housekeeping' command run on a regular basis, it
>>> just seems to happen before your real problem, I do not think the
>>> two are connected. Lets examine the permissions set on your shares
>>> directory: drwxrwx--T+ 5 root domain users 4096 Sep 30 18:31
>>> basisordner
>>>
>>> Working left to right:
>>> The 'd' shows it is a directory
>>> The first 'rwx' shows that the owner has full permissions on the
>>> directory The second 'rwx' shows that the group has full
>>> permissions on the directory the final '--T' is a bit special, it
>>> shows that 'others' have no permissions on the directory and that
>>> the 'sticky bit' is set on the directory.
>>>
>>> There is also a '+' at the very end, more about this later.
>>>
>>> The standard permissions shows that the owner (root) and members of
>>> the group (Domain Users) have full permisions on the directory
>>> (read,write and enter), others cannot even enter the directory.
>>> Because the 'sticky bit' is set, then any files in the directory
>>> can only be renamed or deleted by the files owner, the directory's
>>> owner, or root (in this case the same user)
>>>
>>> Now something is attempting, via smbd, to change directory into the
>>> 'basisordner' directory, that 'something' in your case is the
>>> computer fs1. Because 'fs1' is not 'root' or a member of Domain
>>> Users it is being denied access. However there is that '+', that
>>> shows that there are extended acls set on the directory, what they
>>> are, I have no idea, because I haven't seen the output of 'getfacl
>>> /mnt/volume1_daten/basisordner', but, from the error you are
>>> getting, I doubt they show 'fs1' having permission to enter the
>>> directory.
>>>
>>> Your main problem is tracing the 'something' that is triggering
>>> smbd to attempt to chdir, it could be something on the server or
>>> something connecting from another computer.
>>>
>>> Rowland
>>>
>>>
>>>
>>>
>>>
>