samba - May 2005 - File Modify/Delete Problems with Samba 3.0.14a and Windows XP

Hi,

I recently upgraded from Samba 3.0.7 to Samba 3.0.14a. This is a Debian
Woody box using the packages by Sino[1], running Linux kernel 2.6.11.8
and the XFS filesystem with ACL support disabled.

[1] http://us3.samba.org/samba/ftp/Binary_Packages/Debian/samba3/

Suddenly I am having problems with Windows XP workstations. Users can
create files and folders, but cannot modify or remove files, even those
that they own. Nothing in the logs to help me out.

Here's a snippet of my smb.conf, in case it helps. Feedback would be
great. Thanks!

	[global]
		; General Information
		workgroup = SOLUTIONS
		netbios name = SERVER
		server string = Primary File Server

		; Security
		encrypt passwords = true
		passdb backend = tdbsam guest
		interfaces = eth1 lo
		bind interfaces only = yes
		hosts allow = 192.168.1.0/255.255.255.0 127.0.0.1
		invalid users = root guest
		dont descend = /boot,/dev,/proc,/root
		wide links = no
		null passwords = yes

		; Optimization
		socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=8192
SO_SNDBUF=8192
		deadtime = 15
		oplocks = no
		level2 oplocks = no

		; Name Resolution
		name resolve order = wins
		wins support = yes
		dns proxy = no

		; Logging
		log file = /var/log/samba/log.%m
		log level = 1
		max log size = 5000
		syslog only = no
		syslog = 0

		; Domain Logon Settings
		security = user
		domain logons = yes
		domain master = yes
		preferred master = yes
		os level = 100
		logon drive = h:
		logon home = \\%N\%U\.profile
		logon path = \\%n\%U\.profile
		logon script = common.bat

		; Misc Stuff
		lock directory = /var/run/samba
		nt acl support = no
		time server = true
		panic action = /usr/share/samba/panic-action %d

		; Password Management
		pam password change = yes
		unix password sync = yes
		passwd program = /usr/bin/passwd %u
		passwd chat = *ew\sUNIX\spassword* %n\n *etype* %n\n
*all\sauthentication\stokens\supdated\ssuccessfully*

	[netlogon]
		comment = Network Logon Service
		path = /etc/samba/netlogon
		guest ok = yes
		writeable = no
		browseable = yes
		create mode = 0664
		directory mode = 0775
		force group = staff

	[homes]
		comment = Personal User Home Directory
		browseable = no
		writeable = yes
		create mode = 0600
		directory mode = 0700
		hide dot files = yes

	[accounting]
		comment = Accounting
		path = /var/lib/shares-data/accounting
		create mode = 0660
		directory mode = 0770
		force group = staff
		writeable = yes
		valid users = user1,user2,user3

	[public]
		comment = Public File Exchange
		path = /var/lib/shares-data/public
		create mode = 0660
		directory mode = 0770
		writeable = yes
		force group = staff

 --> Jijo

-- 
Federico Sevilla III : jijo.free.net.ph : When we speak of free software
GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price.

On Fri, May 06, 2005 at 02:06:19PM +0800, Federico Sevilla III
wrote:
> Suddenly I am having problems with Windows XP workstations. Users can
> create files and folders, but cannot modify or remove files, even those
> that they own. Nothing in the logs to help me out.
I forgot to mention that access from Windows 98 workstations works
perfectly, with the same users who have problems from the Windows XP
workstations.

 --> Jijo

-- 
Federico Sevilla III : jijo.free.net.ph : When we speak of free software
GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price.

On Fri, May 06, 2005 at 02:06:19PM +0800, Federico Sevilla III
wrote:
> Suddenly I am having problems with Windows XP workstations. Users can
> create files and folders, but cannot modify or remove files, even
> those that they own. Nothing in the logs to help me out.
Another follow up from a user just came in.

An interesting workaround is that a user can create a new folder in a
share, to which he/she can copy files from anywhere else or create new
files, he/she can also delete and modify files in said new directory. So
the new directory created works as it should.

The user can also copy files from this new directory back into the main
share (where user couldn't modify/delete). However, once that's done,
the user can't modify/delete the file anymore.

All file permissions look correct (0660 and 0770 as specified in the
smb.conf). Ownerships, too.

What could be wrong?

 --> Jijo

-- 
Federico Sevilla III : jijo.free.net.ph : When we speak of free software
GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price.

On Fri, May 06, 2005 at 02:06:19PM +0800, Federico Sevilla III
wrote:
> I recently upgraded from Samba 3.0.7 to Samba 3.0.14a. This is a
> Debian Woody box using the packages by Sino[1], running Linux kernel
> 2.6.11.8 and the XFS filesystem with ACL support disabled.
Errata: previous version was Samba 3.0.8, from Backports.org
(3.0.8-0.backports.org.2).

Some additional information:

I rolled back to that version (3.0.8-0.backports.org.2) and everything
works as is. Same kernel, same config, same everything else except for
Samba.

The latest pre-3.0.14a version in Backports.org, 3.0.11 (3.0.11-0woody1)
also works fine. That's what we've decided to use for now.

Samba 3.0.14a, whether from Backports.org or from the Samba site (built
by Sino), do NOT work. They exhibit the error mentioned in the original
post.

 --> Jijo

-- 
Federico Sevilla III : jijo.free.net.ph : When we speak of free software
GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price.

Hi Federico 

I have the same problems that you describe.
Using force group with Samba 3.0.14a casues problems as
described by you and me (see "force group broken in 3.0.14 in the
May archive") for Win XP Pro SP2 clients.
Win 98 Clients - no problems
Win XP Pro SP1 - no problems up a certain point/update which I haven´t
nailed down yet.
I have not tried to roll back Samba as you did, but that also solved
the problem?! 

It seems as some unhappy combination of changes within XP but also
within Samba. I really love this kind of shit - undocumented as it
propably is......
My problem is that we could just change the configuration to something
that works, like force user f.eks, but I like the way it works now.
But I wonder why everybody is ignoring our threads: I think the problem
is relevant, and I'm pretty sure that I have a theoretically correct
configuration. 

What are we going to do about it. Call Microsoft and/or Tridqell? 

Hans Otto Lunde
Egmont Højskolen
Denmark