search for: close_directori

On 2020-03-30 14:33, Rowland penny via samba wrote: > It might help if you don't crop lines like the above from your logs, out > of context they are meaningless. > > If you are going to post log fragments, post the entire log fragment and > a few lines above and below it. Sorry. Here a full excerpt: > [2020/03/30 14:56:31.559263, 0]

Hello. I'm seeing several of the above messages in my smbd logs. I see three different kinds: > close_directory: Could not delete share entry for . > close_directory: Could not delete share entry for {filename} > close_remove_share_mode: Could not delete share entry for file {filename} I could find no explanation on their meaning. Anyone has a pointer? bye & Thanks av.

Dear all, we updated to 4.12.10-10 using the sernet packages. After approx. 30 minutes I obtainted the following messages in syslog: root at ctdb-ho-2:~# journalctl -f -- Logs begin at Wed 2020-11-11 08:53:27 CET. -- Nov 13 13:00:18 ctdb-ho-2 smbd[30956]: [2020/11/13 13:00:18.616823, 0] ../../source3/smbd/close.c:1150(close_directory) Nov 13 13:00:18 ctdb-ho-2 smbd[30956]: close_directory:

Encountering a strange one... has been occuring since samba 4.15.x and continues to occur even in 4.17.5 and 4.18 Issue does not occur in earlier versions (4.13.x) and have switched back and forth between versions to confirm. Servers are winbind joined, PAM and krb5 auth, all seems to work fine (reading, writing, creating, moving) until trying to delete an empty folder on the share from Windows

On Wed, Mar 15, 2023 at 04:53:16PM +0000, Rowland Penny via samba wrote: > > >On 15/03/2023 16:47, Jeremy Allison via samba wrote: >>On Wed, Mar 15, 2023 at 11:29:10AM -0400, CaptainTrips28 via samba wrote: >>>Encountering a strange one... has been occuring since samba 4.15.x and >>>continues to occur even in 4.17.5 and 4.18 >>> >>>Issue does not

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

On 2020-03-31 11:38, Rowland penny via samba wrote: > I wouldn't worry about those, they are just warnings that something is > trying to delete something that it shouldn't or cannot. i.e something > that has already been deleted or it doesn't have the permission to delete. Well, I guess so :) Any hint on what that "something" is? What is a "share

Release Announcements --------------------- This is the latest stable release of the Samba 4.15 release series. Changes since 4.15.3 -------------------- o? Jeremy Allison <jra at samba.org> ?? * BUG 14928: Duplicate SMB file_ids leading to Windows client cache ???? poisoning. ?? * BUG 14939: smbclient -L doesn't set "client max protocol" to NT1 before ???? calling the

Release Announcements --------------------- This is the latest stable release of the Samba 4.15 release series. Changes since 4.15.3 -------------------- o? Jeremy Allison <jra at samba.org> ?? * BUG 14928: Duplicate SMB file_ids leading to Windows client cache ???? poisoning. ?? * BUG 14939: smbclient -L doesn't set "client max protocol" to NT1 before ???? calling the

Hi guys I have a problem with Samba 4.0 shares covered by scannedonly VFS. Example configuration of one of those shares: path = /foo/bar/baz read only = No browseable = No vfs objects = scannedonly scannedonly:domain_socket = True scannedonly:socketname = /var/lib/scannedonly/scan scannedonly:hide_nonscanned_files = True scannedonly:allow_nonscanned_files = False Whenever I

This is just a information in case somebody runs into the same issue: I was unable to upload drivers to a samba-server (3.0.28a and 3.0.29) via the windows add printer wizard. The driver files started uploading, then processing stopped saying the driver is not compatible to windows xp. In the logs the following message popped up. However some files could be copied: [2008/05/27 10:30:09, 0]