This behaviour starts with 3.0.12 and 3.0.13. I'm running samba under solaris9 and solaris10, but this is not solaris-related, as I talked to someone who's using linux and ran into the same problem. The problem is, that if I try to rename/remove a file under windows that has been added by me, it will fail with "access is denied, file may be in use". The folder has been added on the windows-side by an admin and I've been added and given full-control to it. To reproduce all steps done in windows): 1. Use the adminaccount which can add folders and modify permissions. 2. Open a share and add a folder 3. Open properties and add a user to the added folder 4. Give the user full-control 5. Switch to the user and open the added folder 6. Add a textfile 7. Try to rename the textfile --> fails 8. Try to remove the textfile --> fails Renaming/Removing Directories works fine. If I go back to 3.0.11 I don't have this problem. This problem starts with 3.0.12 and shows the same effect on linux On the unix-side, the added folder is owned by root. If I manually change the owner and try again, the file finally can be deleted. samba is compiled with acl-support and winbind-support
> The problem is, that if I try to rename/remove a file under windows that has > been added by me, it will fail with "access is denied, file may be in use". > > Renaming/Removing Directories works fine. This is very similar to a problem I have with FC3 and xfs file system. I can rename a directory in the root dir, but not a filename. samba panics. I can rename files in subdirectories. Let me know if it's unrelated and I'll file a seperate bug report. samba3 svn 6290 xfs on lvm2 on raid5 xfsprogs-2.6.13-2 lvm2-2.00.25-1.01 mdadm-1.6.0-2 FC3 linux 2.6.10-1.770_FC3 /dev/mapper/vg01-lvghost on /vol/ghost type xfs (rw) [ghost] path = /vol/ghost read only = no create mask = 0775 nt acl support = yes Maybe it's the same section of code. If not, I'll open a different bug report. Regards, Doug PANIC: assert failed at smbd/posix_acls.c(3893) [2005/04/02 18:31:13, 0] lib/util.c:smb_panic2(1483) PANIC: assert failed [2005/04/02 18:31:13, 0] lib/util.c:smb_panic2(1491) BACKTRACE: 13 stack frames: #0 /usr/local/samba3/sbin/smbd(smb_panic2+0x194) [0x81b9a42] #1 /usr/local/samba3/sbin/smbd(smb_panic+0x10) [0x81b98ac] #2 /usr/local/samba3/sbin/smbd [0x80ccbcd] #3 /usr/local/samba3/sbin/smbd(can_delete_file_in_directory+0x10a) [0x80cce56] #4 /usr/local/samba3/sbin/smbd(can_delete+0x13d) [0x80a1919] #5 /usr/local/samba3/sbin/smbd(reply_ntcreate_and_X+0x63e) [0x80985f6] #6 /usr/local/samba3/sbin/smbd [0x80ce8b1] #7 /usr/local/samba3/sbin/smbd [0x80ce93b] #8 /usr/local/samba3/sbin/smbd(process_smb+0x1b7) [0x80cec37] #9 /usr/local/samba3/sbin/smbd(smbd_process+0x158) [0x80cf762] #10 /usr/local/samba3/sbin/smbd(main+0x784) [0x8227352] #11 /lib/tls/libc.so.6(__libc_start_main+0xe3) [0x90ae33] #12 /usr/local/samba3/sbin/smbd [0x807ab59]
I changed this code recently to fix something that looks like this bug, line 3893 is no longer an assert in the current SAMBA_3_0 SVN code. Please re-checkout and test again. Thanks, Jeremy.
Created attachment 1145 [details] Level 10 FILE_SHARE_DELETE & assert panic svn 6307, assert panic is still there.
Created attachment 1146 [details] patch
The asserts were too cautious. I've checked the fix into SVN. Jeremy.
Thank you Jeremy. Doug
The fix didn't solve the problem I had when opening this bug report. I tried again with 3.0.14 and 3.0.15pre2. The last version that works like expected is 3.0.11, all later versions I tried don't work. Here's some more info: This directory was created using the admin-account on windows: drwxrwxr-x+ 11 FORSCHUNG\fs0005 20001 512 Apr 20 09:35 sys-admin The acls look like this: # file: sys-admin # owner: FORSCHUNG\fs0005 # group: 20001 user::rwx user:DEKON\fuchs_mi:rwx #effective:rwx group::--- #effective:--- mask:rwx other:r-x default:user::rwx default:user:DEKON\fuchs_mi:rwx default:group::--- default:mask:rwx default:other:r-x This is the document that I created with my user-account on windows in the sys- admin folder: -rwxrwxr-x+ 1 DEKON\fuchs_mi 20001 0 Apr 20 09:35 New Text Document (2).txt Here are the acls: # file: New Text Document (2).txt # owner: DEKON\fuchs_mi # group: 20001 user::rwx user:DEKON\fuchs_mi:rwx #effective:rwx group::--- #effective:--- mask:rwx other:r-x Like I said in my first post, I can add content to it, but as soon as I try to rename or delete the file I get an error telling me that the source file may be in use (which it isn't) or that the access is denied. Samba was compiled with acl support. This starts with 3.0.12. Michael
(In reply to comment #7) > Like I said in my first post, I can add content to it, but as soon as I try > to rename or delete the file I get an error telling me that the source file > may be in use (which it isn't) or that the access is denied. I'm seeing this as well with 3.0.14a on Debian Sarge. I've also noticed that WinXP clients behave this way but WinNT clients work normally.
(In reply to comment #8) > (In reply to comment #7) > > I'm seeing this as well with 3.0.14a on Debian Sarge. I've also noticed that > WinXP clients behave this way but WinNT clients work normally. after deleting, have you refreshed the folder? The file might appear again, undeleted.
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > > I'm seeing this as well with 3.0.14a on Debian Sarge. I've also noticed > > that WinXP clients behave this way but WinNT clients work normally. > > after deleting, have you refreshed the folder? The file might appear again, > undeleted. As I recall, I was looking at it from the Linux side. I've gone back to 3.0.11 for now. I should also not that the Linux filesystem is ext3 without ACL support.
This is probably the same problem as bug #2606, which is fixed by http://websvn.samba.org/cgi-bin/viewcvs.cgi?rev=6378&view=rev
closing. please reopen if not addressed in 3.0.23.