The Samba-Bugzilla – Bug 2591
Delete/Rename of File in Root-Share fails although User has got permission from the admin on that folder
Last modified: 2006-07-05 13:12:16 UTC
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
FC3 linux 2.6.10-1.770_FC3
/dev/mapper/vg01-lvghost on /vol/ghost type xfs (rw)
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.
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.
Created attachment 1145 [details]
Level 10 FILE_SHARE_DELETE & assert panic
svn 6307, assert panic is still there.
Created attachment 1146 [details]
The asserts were too cautious. I've checked the fix into SVN.
Thank you Jeremy.
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
This is the document that I created with my user-account on windows in the sys-
-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
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.
(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,
(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,
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
This is probably the same problem as bug #2606, which is fixed by
closing. please reopen if not addressed in 3.0.23.