On 2020-03-31 12:21, Rowland penny via samba wrote: > A 'share entry' is exactly that, a file or directory You mean, it's a client trying to delete a file/directory? From what I can see, crossing smbd's log and audit log, the message > [2020/03/30 15:23:16.754076, 0] ../../source3/smbd/close.c:1214(close_directory) > close_directory: Could not delete share entry for SCADENZE FORNITORI does not mean that client was trying to delete that folder. Or is it rather an internal structure in Samba referencing a file/directory? > and whilst it is > probably a bit of a problem, I do not think it is a Samba problem. Could you provide some pointer to what kind of problem this is? >> Yes, MacOS (which is the kind of client that is giving me 99% of the >> problems I see lately). > Ah, I did remember correctly, sorry but this needs to be fixed on your > MacOS machines, Samba is just reporting their problem. I possibly agree here. Only, I don't know what the problem is, so I could not fix it even if I was on the MacOS developping team (which of course I'm not). What I'm asking is not for a fix on the MacOS side; just an explanation on what Samba is complaining about. That explanation might eventually lead to actions on the client side later. bye & Thanks av.
On 31/03/2020 14:45, Andrea Venturoli wrote:> On 2020-03-31 12:21, Rowland penny via samba wrote: > > > A 'share entry' is exactly that, a file or directory > > You mean, it's a client trying to delete a file/directory?It looks to me that the 'client' is deleting something and then doing it again, which is where the messages are coming from. Samba does whatever it was asked to do, but is then asked to do it again (by the client) and cannot because it doesn't exist any more. I repeat, this is highly unlikely to be a Samba problem, it is a 'client' problem. Rowland
On 2020-03-31 16:24, Rowland penny via samba wrote:> It looks to me that the 'client' is deleting something and then doing it > again, which is where the messages are coming from. Samba does whatever > it was asked to do, but is then asked to do it again (by the client) and > cannot because it doesn't exist any more.I'm almost sure this is not the case. No one tried to delete that directory; for sure no one did it twice. If the client is trying to delete something else, I guess the log would not name that something else, not that directory. I'm putting up a test lab, where I hope to be able to repeat all the troubles I'm having with Mac clients. I'll update the list when (if) I'll have get more info. bye av.