Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[YesTheBD]

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, ~* 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]

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  . I should stop using the [url] tag like that.

[YesTheBD]

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 (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 (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 and referenced in the problem described here 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.)

[YesTheBD]

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).

[scaramanga]

Editing the smb.conf file is easy once you telnet/ssh access (which is also straight forward to set-up).

[Biscotte]

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

[YesTheBD]

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.

[YesTheBD]

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]

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:

Code: [Select]

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.

[YesTheBD]

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  (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.

[scaramanga]

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.

[YesTheBD]

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.