SBS2k3, OS X SMB File locking problem

  • Thread starter Thread starter Steve
  • Start date Start date
S

Steve

We have an SBS 2003 Server with OS X 10.3 users. We experience a
problem where they are unable to save files because they are locked on
the server. The problems have been observed in Word, Excel, Quark,
Illustrator, and Photoshop. The actual locks are on the resource fork
files (files the same name as the actual file being used but start with
a ._) which for some reason do not appear to get released throughout
the day until the share is disconnected or we manually release the lock
from the server console. As the user works with more and more files,
the read lock on each ._ file stays open after they are done working on
the file. We would like to use the smb shares but the SAVE AS
workaround is not an acceptable answer for these users.

We had been using afp shares prior to this but had the dreaded
disconnect problem where the afp shares would disconnect while the user
was working. We did not have the problem before on the NT4 server. We
have tried resetting all of the server idle time disconnects to no
timeout to no avail (in local security policy, and as specified in.
Hmm, could this be why we have the problems with the locks on the
resource fork files? I think all the auto disconnects are for idle
shares not files.

I have search and read on these problems for months but this is my
first post. Thanks for your assistance. My users are VERY unhappy.
 
Steve said:
We have an SBS 2003 Server with OS X 10.3 users. We experience a
problem where they are unable to save files because they are locked on
the server. The problems have been observed in Word, Excel, Quark,
Illustrator, and Photoshop. The actual locks are on the resource fork
files (files the same name as the actual file being used but start with
a ._) which for some reason do not appear to get released throughout
the day until the share is disconnected or we manually release the lock
from the server console. As the user works with more and more files,
the read lock on each ._ file stays open after they are done working on
the file. We would like to use the smb shares but the SAVE AS
workaround is not an acceptable answer for these users.

We had been using afp shares prior to this but had the dreaded
disconnect problem where the afp shares would disconnect while the user
was working. We did not have the problem before on the NT4 server. We
have tried resetting all of the server idle time disconnects to no
timeout to no avail (in local security policy, and as specified in.
Hmm, could this be why we have the problems with the locks on the
resource fork files? I think all the auto disconnects are for idle
shares not files.

I have search and read on these problems for months but this is my
first post. Thanks for your assistance. My users are VERY unhappy.
Click to expand...


Hi Steve!

This is a common problem with using SMB for file sharing. To date I know
of no solution other than to use a third party server application such
as ExtremeZ-IP <www.grouplogic.com>. Group Logic offers a 30-day trial
download.

Hope this helps! bill
 
Thanks Bill, not exactly the answer I hoped for. I work with a mac
expert who says the 2000 server doesn't have this problem. Is this
problem new with Windows Server 2003? Which side is the bug on - mac or
Windows server?

I have heard some rumors that 10.4 fixes the file locking problem but
we can't go there yet. I guess that means we may have to revert to AFP
shares, which have been problem since day 1 of this install. We had
that problem when the drives disconnect while working due to the
incompatibility of the macs using AFP 3.0 and the server using AFP 2.X.
What I don't understand about that one is why it wasn't a problem for
them on the old NT server.

Any thoughts or suggestions on that one? Anyone?

Steve
 
Try DAVE or ADmitMac. These should work fine for 10.3 and Windows 2003.
I know the locking problem is in Apple's SMB client software.

Paul Nelson
www.thursby.com
 
It has been our observation that these locks are made by the client and the
issue exists with Windows 2000 servers as well.
 
More on this, if you have the option to share the server's file-system via NFS, I have had less file-locking & permissions related issues using NFS.

I ran into this using a (updated to the latest OS) SNAP server - one of our file servers. We have PCs, iMac G5s (half of which have been serviced multiple times for bad power supplies and logic boards!), Solaris, and FreeBSD machines, sharing the SNAP server.

Using regular SMB, iMac users could seldom move files around on the SNAP server. Excel documents and Word docs (to a lesser extent) often remained locked, and un-editable for all users, though no one had them open (the SNAP server would report they were open by one of our Mac users, logging that Mac user out, would generally unlock the file).

So, I enabled NFS on the SNAP server, as stated above, it really appears Apple's SMB client in OS X Panther is broken:

To enable NFS on iMac
info required: the iMac user's UNIX uid
--> 'id username' (at the terminal)
The iMac's IP (should consider using a static internal IP),
and set a root passwd
--> as admin at terminal do:
'sudo su -' (type admin pass) then once authenticated type 'passwd root' to set new passwd - required by the shareware utility to set and automount an NFS server (in this case the SNAP server.

The UID and IP are needed to configure the SNAP NFS server for your user(s). Be aware that this user still may need permissions set on the NFS server. The utility though can mount the server in read-only or writable modes.

Users saving and moving files via this NFS mount (appears under Networks/Servers), have not had the same issues as when using the Mac's SMB client. I hope this will be helpful for those who have the option of NFS. I believe there are NFS servers available for Windows, which should make this an option for Win servers, the shareware Mac client is called "NFS Manager" Good luck! One thing I have noticed is the file transfer speed may be a little slower with NFS...?

S7
 
Back
Top