samba - Dec 2020 - Strange logs: check_usershare_stat: file /var/lib/samba/usershares/ owned by uid 0 is not a regular file

On 02/12/2020 09:06, Rowland penny via samba wrote:
> On 01/12/2020 22:55, Jeremy Allison wrote:
>> On Tue, Dec 01, 2020 at 10:46:05PM +0000, Rowland penny via samba
wrote:
>>> On 01/12/2020 22:35, Jeremy Allison wrote:
>>>> On Tue, Dec 01, 2020 at 10:32:32PM +0000, Rowland penny via
samba
>>>> wrote:
>>>>> On 01/12/2020 22:23, Andrew Bartlett wrote:
>>>>>> On Tue, 2020-12-01 at 14:19 -0800, Jeremy Allison via
samba wrote:
>>>>>>> On Tue, Dec 01, 2020 at 10:08:34PM +0000, Rowland
penny via samba
>>>>>>> wrote:
>>>>>>>
>>>>>>>> could this have anything to do with it:
>>>>>>>>
>>>>>>>> 4.12.0
>>>>>>>> Default: usershare max shares = 0
>>>>>>>>
>>>>>>>> 4.13.2
>>>>>>>> Default: usershare max shares = 100
>>>>>>> Good catch. Yes, that would cause
>>>>>>> the usershare load path to be executed
>>>>>>> now whereas it wasn't before.
>>>>>> Even if we didn't change the default, Debian does.?
But the code
>>>>>> should
>>>>>> work of course, be it enabled by default or by the
administrator...
>>>>>>
>>>>>> Andrew Bartlett
>>>>>
>>>>> Yes, it is Debian, just found this out by downloading the
relevant
>>>>> file from Louis's repo, they appear to be turning
usershares on
>>>>> without actually setting up usershares. I would suggest the
code
>>>>> would work if usershares were actually set up correctly, I
have
>>>>> used usershares in the past and I don't remember syslog
getting
>>>>> spammed.
>>>>
>>>> Well I still don't know why he's seeing syslog spam
from
>>>> an empty usershare directory. That shouldn't happen even
>>>> if the code is going down the usershare path now.
>>>
>>> He is not alone, I didn't know I had a problem until I checked 
>>> syslog, my lines are bit different:
>>>
>>> Dec? 1 09:14:25 raspberrypi smbd[21036]: [2020/12/01 
>>> 09:14:25.671948,? 0] 
>>> ../../source3/param/loadparm.c:3422(process_usershare_file)
>>> Dec? 1 09:14:25 raspberrypi smbd[21036]: process_usershare_file: 
>>> stat of /var/lib/samba/usershares/profiles.v6 failed. Permission
denied
>>
>> Hang on a minute - the above says "Permission denied"
>> for "/var/lib/samba/usershares/profiles.v6"
>>
>> That means the directory scanner found something
>> inside:
>>
>> /var/lib/samba/usershares
>>
>>> Dec? 1 09:14:25 raspberrypi smbd[21036]: [2020/12/01 
>>> 09:14:25.676259,? 0] 
>>> ../../source3/param/loadparm.c:3422(process_usershare_file)
>>> Dec? 1 09:14:25 raspberrypi smbd[21036]: process_usershare_file: 
>>> stat of /var/lib/samba/usershares/profiles.v6 failed. No such file 
>>> or directory
>>
>> Now it says "No such file or directory" for
>> "/var/lib/samba/usershares/profiles.v6"
>>
>> Which is right ?
>
> There is nothing inside /var/lib/samba/usershares , do you think I 
> would put profiles inside a usershare ?
>
> Rowland
>
>
>
OK, I have realised why this is happening, but not how (or is that how, 
but not why ?)

I set 'profilePath' to '//raspberrypi/profiles' in my AD object,
unfortunately the 'raspberrypi' that is running now isn't the same
one
that was running when I set it and it doesn't have a profiles share. The 
question has to be, is this a Samba problem, or is it a Windows problem 
? To me, it seems that Windows looks for the profile and having not 
found it, searches on 'raspberrypi' for it, so should Windows be doing 
this and should Samba be allowing this ?

Rowland

On Wed, Dec 02, 2020 at 09:54:16AM +0000, Rowland penny via samba wrote:
>OK, I have realised why this is happening, but not how (or is that 
>how, but not why ?)
>
>I set 'profilePath' to '//raspberrypi/profiles' in my AD
object,
>unfortunately the 'raspberrypi' that is running now isn't the
same one
>that was running when I set it and it doesn't have a profiles share. 
>The question has to be, is this a Samba problem, or is it a Windows 
>problem ? To me, it seems that Windows looks for the profile and 
>having not found it, searches on 'raspberrypi' for it, so should 
>Windows be doing this and should Samba be allowing this ?
We can't control clients asking for anything unfortunately.

OK, I see the problem. There are two paths into process_usershare_file.
One is the directory scanner. But the second one is if a client asks for an
unknown
share and usershares are enabled it calls:

load_usershare_service()

- we end up in process_usershare_file() and go into the path:

         if (sys_lstat(fname, &lsbuf, false) != 0) {
                 DEBUG(0,("process_usershare_file: stat of %s failed.
%s\n",
                         fname, strerror(errno) ));
                 goto out;
         }

A debug level zero is a valid thing to do if we're processing a name
from the directory scanner, but not from an unknown share.

Fix is to bump this debug to DBG_INFO. If there really was
a problem and we're coming in from the directory scanner,
then we'll end up in check_usershare_stat() and the admin
will get notified that way.

Rowland, can you log a bug and I'll create a patch MR
for this ?

Thanks,

Jeremy.