D-Link Forums
The Graveyard - Products No Longer Supported => D-Link Storage => DNS-323 => Topic started by: YesTheBD on February 15, 2011, 12:27:35 PM
-
My DNS-323 works flawlessly for me except for one really big thing...
While working in an MS Office 2003 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.
In Word, for instance, after the connection is broken and reestablished, if I try to save the file again, I get the error: "Word cannot complete the save due to a file permission error." (followed by the path and file name of the file).
If I exit Word and try to rename the file from Windows Explorer, I get the message: "Cannot rename <filename>: It is being used by another person or program. Close any programs that might be using the file and try again." After a period of about 10 minutes, if I do nothing at all, I can rename the file.
This problem is especially frustrating since I work wirelessly a lot and lose my connection (very briefly) a couple of times per hour.
The problem seems to be unique to MS Office files. It does not occur when working with files, for instance, in Notepad or MS Paint.
I can replicate the problem at will by manually disabling and enabling the connection. Breaking a wired connection has the same effect.
I am running several XP Pro machines and the problem occurs on all of them. Also, when I get locked out of a file, I am locked out on all of the machines.
All the XP machines have the same username (and no password). The NAS does not have any users set up.
The problem existed on DNS-323 firmware 1.04 and still exists on 1.09. I have not fun-plugged the NAS.
Router firmware is the latest Tomato. I have a second router (also Tomato) acting as a wireless ethernet bridge to which the NAS is connected.
Thanks a ton in advance to anyone who can give an explanation or fix.
-
Have you considered fixing the original problem rather than trying to find a work around? Why are you having a dropped connection.
-
I'm not sure about this, but it's worth a shot: under network access, you can try and change the share setting Oplock option.
You can read more about it here:
http://www.smallnetbuilder.com/nas/nas-features/30039-nas-tutorial-oplocks-and-nases
http://www.superbase.com/services_tech_support_oplocks.htm
-
Be warned - an incorrect oplock setting in a multi-user environment can lead to file corruption and data loss. The risk of creating additional problems with that work around is very high - fix the root cause of the problem, your network infrastucture has a serious problem, deal with it and get it done with.
-
scaramanga,
Thanks for the suggestion. Yesterday, I tried switching the oplocks from "No" to "Yes" and it didn't make a difference. However, after making that switch, I did not reboot the NAS (maybe this is necessary?) so I think I will try it again with a reboot just in case (and with Fordem's caveat in mind). I'll let you know if it works.
Fordem,
I've worked on the wireless connectivity issue a fair bit and have concluded that these drops in my wireless connection are an unfortunate fact of life in my house, especially in one room that I work in.
-
You can try Tomato's wireless survey if you haven't already. Might help you find a channel with less interference.
-
scaramanga,
Changing the oplocks to "yes" and an NAS reboot didn't make any difference.
As to finding the clearest channel, I've done that (and several other things like adjusting router transmit power and tweaking my wireless adapter settings). I probably have the best wireless connectivity I'm going to have in this old house without bringing in additional equipment. And even if I do that, I'm far from sure that I'd eliminate the drops.
It seems odd that such a common and usually trivial event as dropping a wireless connection would always cause the major headache of getting locked out of any open MS Office file. I have to imagine that I've got something set up wrong (or not set up that should be) in XP, MS Office or on the NAS. For as much as I know, the answer could be pretty basic.
Thanks a million for any light you can shed.
-
It seems odd that such a common and usually trivial event as dropping a wireless connection would always cause the major headache of getting locked out of any open MS Office file. I have to imagine that I've got something set up wrong (or not set up that should be) in XP, MS Office or on the NAS. For as much as I know, the answer could be pretty basic.
Thanks a million for any light you can shed.
First - on the dropped wireless connections...
You're running the tcp/ip suite of protocols, designed to be self healing, and to withstand a nuclear attack, it actually takes either a woefully poor connection or an extremely high level of errors to result in a dropped connection.
Common - it may be, trivial - certainly not.
Second - on the file lock out.
Microsoft Office is designed to work in a multi-user environment, a file opened by one user is locked to prevent it from being simultaneously opened by a second user, this is done to prevent corruption and loss of data - imagine what would happen if user_1 opened a spreadsheet containing sales figures for the month to add yesterday's sales, whilst user_2 had it open to change the mark up - whoever saves the file first will have his/her changes overwritten when the other user makes his/her save.
If the file is properly closed, the lock is released but if the connection is dropped, it remains locked - this is the cause of your problem.
-
Fordem,
Thanks. I understand all that you've said.
Once the connection is dropped, the lock remains, sure. But once the connection is reestablished, you would think that this lock would not lock out the same user who opened the file, is still on the same computer, in the same session of the application, and even when no changes to the file have been made during the loss of connectivity.
In fact, when I use Computer X to open a MS Office file on a network share on Computer Y, then break Computer X's network connection, I am not locked out of the file in any regard when the connection is reestablished. The lockout problem only happens if the file is on the DNS-323.
-
In fact, when I use Computer X to open a MS Office file on a network share on Computer Y, then break Computer X's network connection, I am not locked out of the file in any regard when the connection is reestablished. The lockout problem only happens if the file is on the DNS-323.
If that's the case, then I'm guessing the problem lies with the smb server. From here, it seems, you have a couple of options, both require installing fun-plug:
1. try to tweak the smb.conf file. If you figure it out that way, you can make your changes permanent by writing a script that modifies smb.conf when the DNS-323 boots.
2. Replace smb.d. There's a samba package in Fon'z repository. Maybe a different (newer?) smb server doesn't suffer from this bug.
-
scaramanga,
I think you're right. There must be an issue with the smb server--maybe something interactional with the way MS Office tries to do its locks.
The fact that the lock expires 10 minutes after Office has quit says something--but I don't know what.
Maybe I don't have Windows properly configured with respect to oplocks. I was kinda poking around / researching that last night.
I don't relish going under the DNS-323's hood. I'm already out of my depth.
FWIW, I created a user acct on the NAS with the same username and password as on all my machines, but it didn't make any difference.
-
The 1.10 FW version is on its way, it seems. If seems that D-Link is more active on this forum (http://forum.dsmg600.info/viewtopic.php?id=6311) than here. You can ask your question there.
-
No guarantees here but the locks that all the m$oft documents that i produce look like this:
File name
"assessment summary.DOC"
Lock the document name
"~$sessment summary.DOC"
This is a 162 byte file with read only and hidden file attributes.
Most people dont see this as their IT admin people set up systems so that they do not show hidden files.
Once you delete this (example above) ~$sessment summary.DOC file, you can do what you like with the document it refers to / it controls the opening of. It has worked since before word 97, on 2003 and 2007 that i know of.
In short kill the corresponding 162 byte file and you are back in business.
Last obvious comment - dont kill the other ~$xxx.doc files, they are keeping the system honest.
-
I think I got the same issue but without using Microsoft Word. I tried installing something on my laptop directly from the NAS, however my laptop froze and I rebooted it. I tried deleting the file from another laptop and it says that another system is holding a lock on it.
-
scaramanga,
Thanks again--which forum are you referring to?
Biscotte,
While trying to troubleshoot this problem, I found that these MS Word ~$ owner files are only created when the file is opened on a local drive.
These files are not created (anywhere) when the file that's open is on the DNS-323 or a share on another XP computer. The locking must be handled differently when a network file is involved.
(This contradicts what MS says about owner files on network drives here: http://support.microsoft.com/kb/211632 (http://support.microsoft.com/kb/211632).)
When you open a MS Word file on your NAS, is a ~* owner file created?
Thanks for your help.
-
Biscotte,
An update. I don't think the ~* owner files are related to the locking problem on the NAS for the reason I stated in my last message. But I want to be add to my last message for the sake of completeness.
My tests were with the MS Word (Tools / Options / Save) "Make local copy of files stored on network or removable drives" option turned on. In accord with http://support.microsoft.com/kb/277010 (http://support.microsoft.com/kb/277010), ~* owner files are not created on network storage when that option is on.
The lockout behavior is the same regardless of whether or not that option is selected.
In short, my system isn't doing anything unexpected with respect to the creation or non-creation of MS Word's owner files--and I don't think these owner files are related to the lockout problem.
-
scaramanga,
Thanks again--which forum are you referring to?
Links are a bit hard to see on this forum. Just hover your mouse on the words "on this forum" in my previous post and you'll see 8). I should stop using the [url] tag like that.
-
I'm short of time right now, but I have a feeling that the info below may be useful in sleuthing this out. Still, I don't why a broken connection to the NAS is the thing that triggers the lockout. Maybe subsequent iterations of Samba addressed the problems below, but the broken connection thing is a new wrinkle.
From http://www.mail-archive.com/samba@lists.samba.org/msg09052.html (http://www.mail-archive.com/samba@lists.samba.org/msg09052.html) (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.
*******
From http://www.mail-archive.com/samba@lists.samba.org/msg21497.html (http://www.mail-archive.com/samba@lists.samba.org/msg21497.html) (2003)
Re: R: [Samba] Samba rewrite file's owner
> I've got two group "groupA" and "groupB". My user say "userA" is part of
> "groupA" and "groupB".
> Another user "userB" is part only of "groupB". userB create a file "fileX".
> userA modify this file.
> the final result is that now the fileX is owned by userA with group "groupB"
> and so it's no more
> readable by userB. This conceptually overrides the creator concept that was
> "userB". How can I manage this
> situation in a clear way?
Please, please do some homework before posting this type of request.
The facts, as mentioned many many times on this list is that Microsoft
Word does the following when you modify/change a Word document:
1. Word Creates a NEW document with a temporary name
2. Word then closes the old document and deletes it
3. Word then renames the new document to the original document name
There is NO mechanism by which Samba CAN IN ANY WAY know that the new
document really should be owned by the owners of the original file. Samba
has no way of knowing that the file will be renamed by MS Word.
Precisely HOW would you like the Samba-Team to modify Samba to "preserve"
ownership and permissions? As far as Samba is able to tell, the file that
gets created is a NEW file, not one that the application (Word) that
creates it has open.
There is a work-around to solve the permissions problem. That work-around
involves understanding how you can manage file system behaviour from
within Samba smb.conf configuration, as well as understanding how Unix
file systems work.
In short:
- set on the directory in which you are changing word documents
chmod g+s 'directory_name'
This ensures that all files will be created with the group that owns the
directory.
- in smb.conf share declaration section set:
force create mode = 0660
force directory mode = 0770
These two setting will ensure that all directories and files that get
created in the share will be read/writable by the owner and group.
This is well documented in the Samba-HOWTO-Collection.pdf for Samba-3.0.0
that is available off the Samba web site, that ships with Samba-3.0.0
betas. Refer to chapter 13, in particular a specific example in the Common
Errors section of this chapter.
This should solve your problem.
******
From http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/AccessControls.html#id2615334 (http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/AccessControls.html#id2615334) and referenced in the problem described here http://infrant.com/forum/viewtopic.php?f=23&t=45048&start=0 (http://infrant.com/forum/viewtopic.php?f=23&t=45048&start=0) (2010)
Question: “When user B saves a word document that is owned by user A, the updated file is now owned by user B. Why is Samba doing this? How do I fix this?”
Answer: Word does the following when you modify/change a Word document: MS Word creates a new document with a temporary name. Word then closes the old document and deletes it, then renames the new document to the original document name. There is no mechanism by which Samba can in any way know that the new document really should be owned by the owners of the original file. Samba has no way of knowing that the file will be renamed by MS Word. As far as Samba is able to tell, the file that gets created is a new file, not one that the application (Word) is updating.
(OP/YesTheBD: The above workaround is then cited.)
-
And there's something important I forgot to mention in my last post that makes me think that my lockout problem may be related to the problems referenced there...
After the break in network connection, a failed save leaves a Word ~*.tmp file in the source file directory. I am not locked out of the ~*.tmp file. Word hangs because it's locked out of the original file (can't delete it) before it would rename the ~*.tmp file to the original file name.
It seems that one or both the following may be happening: 1) the NAS is seeing me as a different user after the connection is reestablished (regardless of whether I started as a "nobody" user or a manually created NAS user); 2) permissions / ownership of the original file are changed by the disconnection or reconnection (and not changed back).
-
Editing the smb.conf file is easy once you telnet/ssh access (which is also straight forward to set-up).
-
YesTheBD
For what it is worth, I copied a document onto my home DNS-323.
I opened it and yes, it opened a 162 byte (lockout) file in the same DNS directory as the file resides. When the (locked out) file was closed, windoze deleted the 162 byte file in the same directory. On all my networked machines at home, and at work over a network, including DNS this is the way it works - 2000, XP and vi$ta. (On both c:\ drives and network drives).
Once the 162 byte file is killed, this allows the document file to be directly opened by another user. If the file is not open I don’t see any reason to lock it, so I am not surprised there is no locking file when the file is not in use.
I maybe missing something - local drive? In all cases the lockout file is always in the same directory as the file being opened, no matter what drive it is opened on. Why would it be anywhere else? Like I say maybe I’m missing something.
Good luck anyway.
Biscotte
-
Biscotte,
Thanks for looking into it. I think the purpose of these ~$*.* owner files is to allow Word to indicate who already has the file open when another user tries to open it. The owner files can't be a necessary part of locking because they are not even created when a file is opened on a network drive and the Word option "Make local copy of files stored on network or removable drives" is turned on. In this case, when someone else tries to open an already open file on a network drive, the file is still locked, but the locking message doesn't indicate the name of the person who already has it open (since there's no owner file). Instead, Word generically indicates that the file is being used by "another user."
If you wouldn't mind doing another quick test, I'd love to know whether you can replicate my problem. If you open a test Word file stored on the DNS-323, then disconnect from your network, wait ten seconds or so, then reconnect, can you save that file--or do you get an error? Also, what version of Word are you running?
Thanks a lot.
-
scaramanga,
You suggested that replacing the smb.d file might help. This sounds pretty painless. Would there be any significant risk of data loss for files already on the NAS?
After fun_plugging and going through the steps to get secure command line access, is it really just a matter of swapping in a different version of that one file (smb.d) and rebooting the NAS? I assume reversing the process would be just as easy, right?
Thanks very much.
-
scaramanga,
You suggested that replacing the smb.d file might help. This sounds pretty painless. Would there be any significant risk of data loss for files already on the NAS?
No, unless you do something royally stupid. You do have access to the command line, and with great powers comes great responsibility.
After fun_plugging and going through the steps to get secure command line access, is it really just a matter of swapping in a different version of that one file (smb.d) and rebooting the NAS?
Actually, for starters, you don't need to restart the NAS, just restart the smb service, like so:
smb restartWhat, actually, happens is that the smb.conf file is stored in flash memory, and during system boot, it is loaded to a ram drive. If you replace that file, on the next boot, it will revert back to the original file. To make something more permanent, you'll need a startup script the replaces this file on every boot. It's very easy to do. You can find similar instructions here: http://wiki.dns323.info/howto:bettersamba#how_to_make_the_windows_archive_bit_work. The problem with this approach, however, is that if you make changes to shares from the web interface, you'll need to manually make changes to the file.
I had an smb.conf problem myself, and opted for a different approach: Instead of replacing the smb.conf file, I wrote a script that edits it. You can find it here: http://forums.dlink.com/index.php?topic=14522.msg85152#msg85152
Obviously, you'll need to make different changes to the smb.conf file.
I suggest, however, that you first make the changes manually to the smb.conf file, restart the smb service and see if all's well. Then, pick the method of choice to make the changes permanent.
I assume reversing the process would be just as easy, right?
Absolutely, yes. Since we change files during boot, just remove the script(s) that do that (or change their permissions so that they don't run) and a boot later it's as if nothing ever happened.
-
Thanks again, scaramanga. It's really awesome of you to help me like this.
One thing I'm confused about: Would swapping the smb.d file require edits to smb.conf? I mean, is the smb server in the Fonz package also called "smb.d" and can I just move or rename the original smb.d and then drop in the Fonz smb.d, then restart the service? And would this change be persistent across rebooting? (I'm thinking of how people used to fix a corrupt Windows .dll -- just replace the corrupt file with a good one.)
I know this is a shot in the dark at fixing my problem--that maybe, for whatever reason, the Fonz smb server won't bring up the disconnect/lockout problem. But time pressures have me hoping for a lucky five-minute fix rather than having to sink time into getting myself up to speed and really sleuthing the problem out. There's probably a fair bit of learning and sleuthing to do because I've realized that the fixes from the links in my prior post are probably not on point. They deal with a situation where a brand new file isn't created with the desired owner or permissions. My situation involves a pre-existing file that loses its former owner or permissions--or somehow otherwise gets locked out.
I'd like to get in there and learn my way around, but other work is calling--and I hope I'm not the only one for whom solving computer problems always takes much longer than anticipated.
P.S. The one thing from researching my problem that actually does seem like a good clue is...
From http://www.mail-archive.com/samba@lists … 09052.html (http://www.mail-archive.com/samba@lists … 09052.html) (2002)
> > It also appears that somewhere [in the save process] 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.
-
Oh dear, please scratch my previous answer. I misread your post and thought you're planning just to change smb.conf (just the configuration file), not replace the smbd (the samba server software).
When you install fun-plug packages, they're installed along-side the firmware, they do not replace anything. When the DNS-323 boots, it has a built-in hook where you can run your own stuff. That's what the fun-plug script is. Since the root filesystem is a ram changes you make to it will not persist across boots. what you do is write scripts that make those changes on every boot.
Undoing those changes is as simple as uninstalling a fun-plug package, or disabling it from running at startup by changing its execution permissions. Almost all (with the exception of the telnet daemon, if I'm not mistaken) fonz' fun-plug packages will not run on startup by default.
I have no experience with the samba ffp package. I think you'd better read more about it here: http://forum.dsmg600.info/viewtopic.php?id=5441
Oh, and one last thing: Since Firmware version 1.10 beta should be released in a short while, you might want to wait a bit and see if it might contain changes/fixes to help with your issue.
-
Right on, scaramanga. Thank you again.
I see the process is a little involved for a newb like me, but I'll look forward to diving in before too long.