Bug 1556 - Cannot delete/move/rename folder once used
Summary: Cannot delete/move/rename folder once used
Status: RESOLVED WORKSFORME
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.4
Hardware: x86 Linux
: P3 major
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-07-23 08:43 UTC by Volker Tanger
Modified: 2004-07-27 07:54 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Volker Tanger 2004-07-23 08:43:13 UTC
First using Samba 2.2.3a (Debian Woody package, recompiled with ACL
support), then switched to 3.0.4 from backports.org - same problem in both versions.

Running on XFS using, ACLs (nt acl support = yes), windbind and security=domain. 

Directly below the share directory I have 

[group_dirs]
	group1
	group2
	group3

The [group_dirs] itself does not have any ACL settings.

All group? dirs have permission set to 0770 plus ACLs set (via setfacl)
like
	# file: group1
	# owner: root
	# group: DOMAIN\Domain-User
	user::rwx
	user:DOMAIN\user1:rwx
	user:DOMAIN\user2:rwx
	group::---
	mask::rwx
	other::---
	default:user::rwx
	default:user:DOMAIN\user1:rwx
	default:user:DOMAIN\user2:rwx
	default:group::---
	default:mask::rwx
	default:other::---


I cannot move, rename or delete the directories from a WinNT/W2k/WinXP client as
soon as it had been used (i.e. files or subdirectories were created within or
copied into). Everything else is fine, renamable, deletable. Regular files are
not a problem at all.

Trying to delete complains with a "Zugriffsverletzung" (Access
violation?). Fiddling with locking=no or oplocks=no did not help, neither did
working with various combinations of [force] (create|directory) [security]
(mask|mode) settings or setting/unsetting "inherit permissions".
Comment 1 Volker Tanger 2004-07-26 06:17:51 UTC
Replacing "inherit permissions" with "inherit acls" made the ACLs look more
consistent - but did not solve the problem. 

Neither Unix-permissions nor ACLs change during "use" of the directory. Created
files are consistently owned by root:DOMAIN-User, btw.

Crosscheck: using smbclient everything works beautiful and without any problems.
Trying to use smbmount (from Debian 3.0/Woody)gives me "access denied", even
when exlicitly giving domain, uid, etc.
Comment 2 Volker Tanger 2004-07-27 07:54:53 UTC
Found some references to non-compatible language settings (i.e. space within
filename was garbled) and wanted to check that.

Single letter directories - everything works fine.
Directories with space in their names - works too.

Huh? Retry. Works. HUH?

I did not change settings, did not restart (neither client nor server).
Strange - but works (mostly).

Still the SMBMOUNT won't want to work - but that's only a secondary (and a
different problem).