DSM-G600, DNS-3xx and NSA-220 Hack Forum

I love my DNS-323, but have a big problem that I think needs advanced expertise to sleuth out and solve.  I wasn't successful with this issue at the D-Link forum, though some folks over there did try.

In a nutshell, while working in an MS Word 2003 or 2007 file stored on my DNS-323, if I lose or break my network connection, I am locked out of that file when I reestablish the connection.  The same goes for Excel files.  For instance, if I'm working on a Word document and lose my wireless connection briefly (old house, lots of wireless networks around), I'm locked out of saving that file when the connection is reestablished ("Word cannot complete the save due to a file permission error.")

If I then exit Word, I'm unable to delete or rename the file for about 10 minutes ("Cannot rename <filename>: It is being used by another person or program. Close any programs that might be using the file and try again.")  Word's inability to delete the file probably explains the inability to save it--because Word's save process is: 1) save a temp file version of the document; 2) delete original file; 3) rename temp file to original file name.  When trying to save the document after the connection is restored, the temp file is created, but the process apparently fails when Word tries and fails to delete the original file.

The disconnect/lockout problem does not occur when working with files in Notepad or MS Paint stored on the NAS.  The problem also does not occur with MS Office files stored on a network share on another computer on my home network.

I am running several XP Pro machines (all with the same username and password) and the problem occurs on all of them.  It makes no difference whether or not any users have been set up on the NAS.  It also makes no difference whether a user is set up on the NAS with the same username and password as my XP username and password.

Changing the oplocks setting makes no difference.

From what I can see in XP, the permissions and owner of the original file are exactly the same before, during and after the disconnection (full control for Unix group 501, Everyone and "nobody"; "nobody" is owner (when no NAS user has been set up)).

I don't have a good sense for how locking (and different flavors of locking) might be managed among Word/Office, Windows and the NAS--but from playing around with things quite a bit, it sure seems like there might be a complex interplay among them.

In any event, the disconnect/lockout problem occurs no matter whether Word has paired the file with a companion "owner file" on the NAS (per a user-configurable setting in Word).  If present, these companion "owner files" provide the username of the person using the file, but they are not essential to locking.

The problem existed on DNS-323 firmware 1.04 and still exists on 1.09.

I can replicate the problem at will by manually disabling and enabling the connection.  Breaking a wired connection has the same effect.

Why does a brief disconnection from the NAS create this kind of lockout and how can it be stopped?  You wouldn't think that a brief disconnection would lock out a user who owns the file, has full permissions, recently opened the file, is still on the same computer, in the same session of the application, and hasn't even changed the document before, during or after the loss of connectivity.

To make things more difficult, I have not fun-plugged the NAS and am out of my depth when it comes to that sort of thing.  I'm willing to learn how to go under the hood a bit and do some simple stuff if that's what's necessary.

Thanks for reading all this and for any help you can give me.

P.S.  I have a weak hunch that the following is a clue...

From http://www.mail-archive.com/samba@lists … 09052.html in (2002)

> > No one is able to edit (in place) documents with Word 2000 on a samba
> > (2.2.6) disk share.  A user can open word and save a document to the
> > share, but when they go to edit the document Word says "Word cannot
> > complete the save due to a file permission error".  From Microsoft KB
> > Q211632 it appears that Word 2000 performs the following steps to Save an
> > Edited File:
> >
> > 1.) Create a temp file (Create ~wrdxxxx.tmp)
> > 2.) Write temp file (Save example data to ~wrdxxxx.tmp)
> > 3.) Delete original file (Delete EXAMPLE.DOC)
> > 4.) Move temp to target name (Move ~wrdxxxx.tmp to EXAMPLE.DOC)
> >
> > >From examining the samba debug log (attached) it does appear that this
> > happens.  It also appears that somewhere in steps 1 and 2 above Word sends
> > a request to turn off the read,write,and execute bits for the owner of the
> > file.  When you look at this filesystem after the attempted save the
> > original file does indeed have these bits cleared (i.e. the user has no
> > read,write,or execute permissions on the file), and that I think is why
> > the error is being generated.