Do you use a [Profile] share to give users access to their home directories form Windows? Could you post the [General] and the service section of your smb.conf file?
The Samba 3 HOWTO & Reference Guide ( samba-doc package or their website ) has a chapter ( ch. 17) on File & Record Locking. When sharing files for both samba & nfs users, they recommend turning oplocks off. However it is possible that there could be changes. As I understand it, this is one area being addressed in Samba4 and improvements may be backported to recent samba versions. They may be writing this with NFS 2 in mind as well. (Just my guess)
You might want to ssh into the server before accessing it form windows (i.e. using putty) and then run the "lsof" command to see which programs have a file open. Find out which services have the file open.
Is the samba server running on the LTSP server or the client. Running the Samba on the client could be a problem. However I don't think there would be a problem if you have /home offered as an NFS service and use a [Profile] share which would have a path of %H which would evaluate to the server's /home/<username> directory. ( The path may be different on your system to accommodate the home partition being mounted somewhere else, of course )
Also check the samba logs. The Samba 3 boot may help you understand the logs as well.
Quote:
17.2.1.3 UNIX or NFS Client-Accessed Files
Local UNIX and NFS clients access files without a mandatory file-locking
mechanism. Thus, these client platforms are incapable of initiating an oplock
break request from the server to a Windows client that has a file cached.
Local UNIX or NFS file access can therefore write to a file that has been
cached by a Windows client, which exposes the file to likely data corruption.
If files are shared between Windows clients and either local UNIX or NFS
users, turn oplocks off.
|
In Linux (and Solaris 9) you can enforce manditory locking on a per file system bases by using the "-o mand" option to the mount command. This isn't available before the 2.4.22 kernel or when using FreeBSD 5.2.1 and Mac OS X 10.3. Ref: Advanced Programming in the Unix Environment.
Quote:
|
Originally Posted by man 2 fcntl
Mandatory locking
(Non-POSIX.) The above record locks may be either advisory or manda‐
tory, and are advisory by default.
Advisory locks are not enforced and are useful only between cooperating
processes.
Mandatory locks are enforced for all processes. If a process tries to
perform an incompatible access (e.g., read(2) or write(2)) on a file
region that has an incompatible mandatory lock, then the result depends
upon whether the O_NONBLOCK flag is enabled for its open file descrip‐
tion. If the O_NONBLOCK flag is not enabled, then system call is
blocked until the lock is removed or converted to a mode that is com‐
patible with the access. If the O_NONBLOCK flag is enabled, then the
system call fails with the error EAGAIN or EWOULDBLOCK.
To make use of mandatory locks, mandatory locking must be enabled both
on the file system that contains the file to be locked, and on the file
itself. Mandatory locking is enabled on a file system using the "-o
mand" option to mount(8), or the MS_MANDLOCK flag for mount(2). Manda‐
tory locking is enabled on a file by disabling group execute permission
on the file and enabling the set-group-ID permission bit (see chmod(1)
and chmod(2)).
|
If you mount the filesystem with the -o mand option, and if Samba understands this, it may provide proper manditory locking on a file opened by a Windows client to prevent any other Linux process from access the file.
When you check for processes accessing user files just after they are created, check if the beagle daemon is accessing the file. When you create a new file, it receives an inotify message and then greps through the file. I would expect it to wait until the file is closed but this might be a possibility.
Look at a user's file with getfattr.
Code:
getfattr twim.xml
# file: twim.xml
user.Beagle.AttrTime
user.Beagle.Fingerprint
user.Beagle.MTime
user.Beagle.Uid
jschiwal@hpamd64:~> getfattr -n user.Beagle.AttrTime twim.xml
# file: twim.xml
user.Beagle.AttrTime="20080619144621"
I think that the AttrTime is when beagled indexed the file. If so, that would allow you to compare this time with when you opened the file from a Windows client.
Also, double check a file created from the windows client. Do the owner/group/permissions match one created locally by that user?
