There seems to be a problem with Samba 4.0 shares covered by scannedonly VFS module. 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 try do delete a directory, I get NT_STATUS_INVALID_HANDLE status, but directory is removed. On Windows, this status spawns an error dialog. Example session: smb: \blah\> ls . D 0 Mon Dec 31 14:48:38 2012 .. D 0 Fri Dec 28 11:50:51 2012 516061624 blocks of size 1024. 489151420 blocks available smb: \blah\> mkdir Test smb: \blah\> ls . D 0 Mon Dec 31 15:48:55 2012 .. D 0 Fri Dec 28 11:50:51 2012 Test D 0 Mon Dec 31 15:48:55 2012 516061624 blocks of size 1024. 489151412 blocks available smb: \blah\> rmdir Test NT_STATUS_INVALID_HANDLE removing remote directory file \blah\Test smb: \blah\> ls . D 0 Mon Dec 31 15:49:01 2012 .. D 0 Fri Dec 28 11:50:51 2012 516061624 blocks of size 1024. 489151420 blocks available smb: \blah\> During this operation, smbd throws those lines into log (timestamps removed for clarity): smbd[10578]: ../source3/smbd/close.c:1255(close_directory) smbd[10578]: Could not close dir! fname=blah/Test, fd=-1, err=9=Bad file descriptor If I do this on a share without scannedonly VFS, everything works without errors. There are no problems with removing files. Only directories are affected.
Created attachment 8440 [details] Do not return private struct on opendir and fdopendir This patch solves the problem, it would be great if someone can have a look to it.
(In reply to comment #1) > Created attachment 8440 [details] > Do not return private struct on opendir and fdopendir > > This patch solves the problem, it would be great if someone can have a look to > it. Great timing. I was just about to upgrade to 4.0.1 :) Looks like your patch fixed the problem. I can remove a directory without the error showing up. I also don't see any problems in a log file. Thank you :)
Ok, reviewing this now. It makes sense as later versions of Samba expect to be able to call DIRFD on a returned DIR pointer, so it isn't really opaque anymore. Jeremy.
Ok this patch won't work as-is unfortunately (although it probably works in the scenario you're testing). It attaches an single open directory 'struct scannedonly_DIR' to the data associated with the connection handle. However clients could open more than one directory simultaneously on a single connection handle, so the 'struct scannedonly_DIR' stored in the struct Tscannedonly must be a list of structures, not just a single one. I'll re-write this and re-submit it for your testing. Cheers, Jeremy.
Created attachment 8683 [details] git-am fix for master and 4.0.next. Can you test this git-am patchset, and see if it fixes the problem ? If you can confirm, I'll submit it to master for review and then get it added to 4.0.next. Thanks, Jeremy.
(In reply to comment #5) > Can you test this git-am patchset, and see if it fixes the problem ? If you can > confirm, I'll submit it to master for review and then get it added to 4.0.next. Currently I cannot do that. I have a Samba upgrade scheduled next week and then I can check it.
Thanks. As soon as you can confirm I'll submit it to the mailing list for merge, and we'll get it into 4.0.next. Jeremy.