On Tue, Nov 16, 2021 at 10:44 PM Oleksandr Natalenko <oleksandr@xxxxxxxxxxxxxx> wrote: > > Hello Namjae et al. > > With the latest ksmbd from the next branch I have an issue with wife's Windows > 10 laptop while copying/removing files from the network share. On her client it > looks like copy operation (server -> laptop) reaches 99% and then stalls, and > on the server side there's this in the kernel log: > > ``` > ksmbd: Unsupported addition info: 0xf) > ksmbd: Unsupported addition info: 0x20) > ``` > > repeated multiple times. I must note that in fact the file gets copied to her > laptop, but Windows copy dialog just hangs. > > Any idea what it could be and how to avoid it? This also happened before (I'm > a pretty early ksmbd adopter), but I'm reporting it just now because I naïvely > hoped it would be fixed automagically :). This never happened to me with > userspace Samba though. > > This is my smb.conf: > > ``` > [global] > workgroup = KANAPKA > server string = ksmbd server %v > netbios name = defiant > valid users = __guest > > [Shared] > valid users = __guest > path = /mnt/shared > force user = _shared > force group = _shared > browsable = no > writeable = yes > veto files = /lost+found/ > ``` > > Appreciate your time and looking forward to your response. > > Thanks. > Hello, This sounds like an issue reported on github a couple of months ago [1]. Can you specify the exact Windows version (+ edition) ? Are you accessing the share through a network-mapped drive ? If not, can you try to reproduce it ? Does this happen with files of any type ? IIRC, the "Unsupported addition info" message you're seeing is related to Windows requesting some attributes that are not handled yet by ksmbd. It seems it was added to fix windows 10 clients after ACLs support was added [2]. Makes me wonder if Windows doesn't like the fake response it is getting when it's trying to read the SACLs. https://github.com/cifsd-team/ksmbd-tools/issues/208 https://github.com/namjaejeon/ksmbd/commit/cb9167856ffca6483 > -- > Oleksandr Natalenko (post-factum) > >