Sharing violation while removing a file

Sharing violation while removing a file

Post by --==[bman]==- » Fri, 20 Jun 2003 11:41:45



I've run into a problem and I wonder if this is a bug or not.  I'm using
version 2.2.x series.  What's happneing is that if I transfer a file, let's
say 100Mb+ to my SAMBA server, I cannot remove it right away even though I
am the owner of that file and the share is writeable by the owner (for the
simplicity sake, let's talk here about [homes] directive.

It does not happen with smaller files.  My dead time is set right now to 5
minutes because it appears that if I don't do anything for 5 minutes,
whatever is locking that file releases it and I can remove it.

But here is a kicker.  I have to leave the folder opened.  If I close it, no
go.  So if I leave the folder open for 5 minutes and my 'dead time' kicks
in, I have no problems removing that file.

P.S.  The system in question that has this issue is Windows 2000.  I haven't
confirmed it yet on my Linux client so I do it tomorrow.

Any ideas what might be going on?

Thanks.

 
 
 

Sharing violation while removing a file

Post by Nico Kadel-Garci » Fri, 20 Jun 2003 12:20:31



> I've run into a problem and I wonder if this is a bug or not.  I'm using
> version 2.2.x series.  What's happneing is that if I transfer a file, let's
> say 100Mb+ to my SAMBA server, I cannot remove it right away even though I
> am the owner of that file and the share is writeable by the owner (for the
> simplicity sake, let's talk here about [homes] directive.

Hmm. I've seen some interesting lock file issues with various *old* SMB
servers, not this one with Samba. What is the OS and filesystem of the
server? And which Samba server *exactly* are you using, with what Samba
settings for the share?
Quote:> It does not happen with smaller files.  My dead time is set right now to 5
> minutes because it appears that if I don't do anything for 5 minutes,
> whatever is locking that file releases it and I can remove it.

> But here is a kicker.  I have to leave the folder opened.  If I close it, no
> go.  So if I leave the folder open for 5 minutes and my 'dead time' kicks
> in, I have no problems removing that file.

> P.S.  The system in question that has this issue is Windows 2000.  I haven't
> confirmed it yet on my Linux client so I do it tomorrow.

> Any ideas what might be going on?

> Thanks.


 
 
 

Sharing violation while removing a file

Post by Mark » Fri, 20 Jun 2003 12:41:30




Quote:> I've run into a problem and I wonder if this is a bug or not.  I'm using
> version 2.2.x series.  What's happneing is that if I transfer a file, let's
> say 100Mb+ to my SAMBA server, I cannot remove it right away even though I
> am the owner of that file and the share is writeable by the owner (for the
> simplicity sake, let's talk here about [homes] directive.

> It does not happen with smaller files.  My dead time is set right now to 5
> minutes because it appears that if I don't do anything for 5 minutes,
> whatever is locking that file releases it and I can remove it.

> But here is a kicker.  I have to leave the folder opened.  If I close it, no
> go.  So if I leave the folder open for 5 minutes and my 'dead time' kicks
> in, I have no problems removing that file.

> P.S.  The system in question that has this issue is Windows 2000.  I haven't
> confirmed it yet on my Linux client so I do it tomorrow.

> Any ideas what might be going on?

> Thanks.

Post your smb.conf, also it would be nice to know the exact version
Samba you are using

smbd -V

Any log output would also be handy here.

It also could be caused by a misconfigured DNS.

Also do not play with dead time....if your TCP/IP network is setup
properly, there is no need to change the default of 0.

****From the Samba documentation****

deadtime (G)
The value of the parameter (a decimal integer) represents the number of
minutes of inactivity before a connection is considered dead, and it is
disconnected. The deadtime only takes effect if the number of open files
is zero.

This is useful to stop a server's resources being exhausted by a large
number of inactive connections.

Most clients have an auto-reconnect feature when a connection is broken
so in most cases this parameter should be transparent to users.

Using this parameter with a timeout of a few minutes is recommended for
most systems.

A deadtime of zero indicates that no auto-disconnection should be
performed.

Default: deadtime = 0

--
Regards,
Mark
Samba Setup Guide
www.samba.netfirms.com

 
 
 

Sharing violation while removing a file

Post by --==[bman]==- » Sat, 21 Jun 2003 10:20:20


Pertinent info follows below:




>> I've run into a problem and I wonder if this is a bug or not.  I'm using
>> version 2.2.x series.  What's happneing is that if I transfer a file,
>> let's say 100Mb+ to my SAMBA server, I cannot remove it right away even
>> though I am the owner of that file and the share is writeable by the
>> owner (for the simplicity sake, let's talk here about [homes] directive.

>> It does not happen with smaller files.  My dead time is set right now to
>> 5 minutes because it appears that if I don't do anything for 5 minutes,
>> whatever is locking that file releases it and I can remove it.

[snip]

Quote:

> Post your smb.conf, also it would be nice to know the exact version
> Samba you are using

> smbd -V


Version 2.2.7-security-rollup-fix


Linux myhost 2.4.18-14bigmem #1 SMP Wed Sep 4 11:58:10 EDT 2002 i686 i686
i386 GNU/Linux

I am running on RedHat 8.0

Quote:

> Any log output would also be handy here.

> It also could be caused by a misconfigured DNS.

Not the case.  I would like to avoid the "point the finger" game...  As I
mentioned, the problem does not occur while transfering smaller files.  I
am on a "huge" network so I can vouch for our DNS not being misconfigured.
If it was, somebody's head would be rolling... :-)

Quote:

> Also do not play with dead time....if your TCP/IP network is setup
> properly, there is no need to change the default of 0.

My experience tells me otherwise.  With any Windows box if I do not set the
dead time, the connections always stay open even if no active takes place
for a prolonged period of time.  The only thing I can say that I am not
sure if I had this isse before or not because only up until recently I
tried to do these huge file transfers.  Ooh, just another thing.  Even
though I cannot remove the file, I can overwrite it.  Now, this does not
make sense to me at all now....

Quote:

> ****From the Samba documentation****

[snip]

Here is my smb.conf file (I sanitized the names and IP addresses):

 # Global parameters
[global]
        workgroup = myworkgroup
        netbios name = mysystem
        server string = mystring
        interfaces = eth*
        bind interfaces only = Yes
        security = SHARE
        encrypt passwords = Yes
        min passwd length = 6
        obey pam restrictions = No
        pam password change = No
        passwd program = /usr/bin/passwd %u
        passwd chat = *New*password* %n\n *Retype*new*password* %n\n
*passwd:*all*authentication*tokens*updated*successfully*
        unix password sync = Yes
        log file = /var/log/samba/%m.log
        max log size = 0
        announce version = 5.0
        deadtime = 10
        socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
        load printers = No
        os level = 65
        preferred master = Yes
        domain master = Yes
        dns proxy = No
        wins server = 10.0.0.1
        create mask = 0774
        directory mask = 0775
        printing = lprng
        mangle case = Yes
        hide unreadable = Yes
        veto files = /etc/passwd/usr/.?*/Mail/

[homes]
        comment = Home Directories
        valid users = %S
        guest ok = No
        create mask = 0664
        block size = 65536
        write cache size = 8388608
        writeable = Yes
        browseable = No

[printers]
        comment = All Printers
        path = /var/spool/samba
        printable = Yes
        browseable = No

BTW, with respect to the section referring to 'block size' and 'write cache
size', it does not make any difference.  The problem still persists.

 
 
 

Sharing violation while removing a file

Post by --==[bman]==- » Sat, 21 Jun 2003 10:22:54




>> I've run into a problem and I wonder if this is a bug or not.  I'm using
>> version 2.2.x series.  What's happneing is that if I transfer a file,
>> let's say 100Mb+ to my SAMBA server, I cannot remove it right away even
>> though I am the owner of that file and the share is writeable by the
>> owner (for the simplicity sake, let's talk here about [homes] directive.

> Hmm. I've seen some interesting lock file issues with various *old* SMB
> servers, not this one with Samba. What is the OS and filesystem of the
> server? And which Samba server *exactly* are you using, with what Samba
> settings for the share?

[snip]


Version 2.2.7-security-rollup-fix


Linux myhost 2.4.18-14bigmem #1 SMP Wed Sep 4 11:58:10 EDT 2002 i686 i686
i386 GNU/Linux

To avoid repeating my comments, I posted a more detailed reply in this
thread to Mark...

Thanks.

 
 
 

Sharing violation while removing a file

Post by Mark » Sat, 21 Jun 2003 11:56:24


comments inline



> Pertinent info follows below:




> >> I've run into a problem and I wonder if this is a bug or not.  I'm using
> >> version 2.2.x series.  What's happneing is that if I transfer a file,
> >> let's say 100Mb+ to my SAMBA server, I cannot remove it right away even
> >> though I am the owner of that file and the share is writeable by the
> >> owner (for the simplicity sake, let's talk here about [homes] directive.

> >> It does not happen with smaller files.  My dead time is set right now to
> >> 5 minutes because it appears that if I don't do anything for 5 minutes,
> >> whatever is locking that file releases it and I can remove it.

Running XP by chance?

- Show quoted text -

> [snip]

> > Post your smb.conf, also it would be nice to know the exact version
> > Samba you are using

> > smbd -V


> Version 2.2.7-security-rollup-fix


> Linux myhost 2.4.18-14bigmem #1 SMP Wed Sep 4 11:58:10 EDT 2002 i686 i686
> i386 GNU/Linux

> I am running on RedHat 8.0

> > Any log output would also be handy here.

> > It also could be caused by a misconfigured DNS.

> Not the case.  I would like to avoid the "point the finger" game...  As I
> mentioned, the problem does not occur while transfering smaller files.  I
> am on a "huge" network so I can vouch for our DNS not being misconfigured.
> If it was, somebody's head would be rolling... :-)

Gotcha..hope it would not your head !

Quote:

> > Also do not play with dead time....if your TCP/IP network is setup
> > properly, there is no need to change the default of 0.

> My experience tells me otherwise.  With any Windows box if I do not set the
> dead time, the connections always stay open even if no active takes place
> for a prolonged period of time.  The only thing I can say that I am not
> sure if I had this isse before or not because only up until recently I
> tried to do these huge file transfers.  Ooh, just another thing.  Even
> though I cannot remove the file, I can overwrite it.  Now, this does not
> make sense to me at all now....

Everyone's mileage differs. My experience with various clients
(over 125 different clients on over 500 workstations running NT, 2000,
XP, and almost every version of linux and Samba) I have yet to change
the default deadtime parameters.

- Show quoted text -

Quote:

> > ****From the Samba documentation****

> [snip]

> Here is my smb.conf file (I sanitized the names and IP addresses):

>  # Global parameters
> [global]
>         workgroup = myworkgroup
>         netbios name = mysystem
>         server string = mystring
>         interfaces = eth*
>         bind interfaces only = Yes
>         security = SHARE
>         encrypt passwords = Yes
>         min passwd length = 6
>         obey pam restrictions = No
>         pam password change = No
>         passwd program = /usr/bin/passwd %u
>         passwd chat = *New*password* %n\n *Retype*new*password* %n\n
> *passwd:*all*authentication*tokens*updated*successfully*
>         unix password sync = Yes
>         log file = /var/log/samba/%m.log
>         max log size = 0
>         announce version = 5.0
>         deadtime = 10
>         socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
>         load printers = No
>         os level = 65
>         preferred master = Yes
>         domain master = Yes
>         dns proxy = No
>         wins server = 10.0.0.1
>         create mask = 0774
>         directory mask = 0775
>         printing = lprng
>         mangle case = Yes
>         hide unreadable = Yes
>         veto files = /etc/passwd/usr/.?*/Mail/

> [homes]
>         comment = Home Directories
>         valid users = %S
>         guest ok = No
>         create mask = 0664

Why create mask 0664 on a users directory?

Quote:>         block size = 65536
>         write cache size = 8388608
>         writeable = Yes
>         browseable = No

> [printers]
>         comment = All Printers
>         path = /var/spool/samba
>         printable = Yes
>         browseable = No

Passed testparm on my pc's, thats a good sign.

Quote:> BTW, with respect to the section referring to 'block size' and 'write cache
> size', it does not make any difference.  The problem still persists.

Any info in /var/log/samba (maybe different on Redhat)

Post the current Linux permissions of your /home directory and it's sub
directories.

--
Regards,
Mark
Samba Setup Guide
www.samba.netfirms.com

 
 
 

Sharing violation while removing a file

Post by --==[bman]==- » Sat, 21 Jun 2003 13:43:39


comments in-line

> comments inline



>> Pertinent info follows below:




>> >> I've run into a problem and I wonder if this is a bug or not.  I'm
>> >> using

> Running XP by chance?

Nope.  It's Windows 2000 Professional.  It's happening from more than just
one machine.  This problem is re-producible every time.


>> Version 2.2.7-security-rollup-fix


>> Linux myhost 2.4.18-14bigmem #1 SMP Wed Sep 4 11:58:10 EDT 2002 i686 i686
>> i386 GNU/Linux

>> I am running on RedHat 8.0

[snip]
>> for a prolonged period of time.  The only thing I can say that I am not
>> sure if I had this isse before or not because only up until recently I
>> tried to do these huge file transfers.  Ooh, just another thing.  Even
>> though I cannot remove the file, I can overwrite it.  Now, this does not
>> make sense to me at all now....

> Everyone's mileage differs. My experience with various clients
> (over 125 different clients on over 500 workstations running NT, 2000,
> XP, and almost every version of linux and Samba) I have yet to change
> the default deadtime parameters.

So that means that connections from your clients to your SAMBA server always
stay open... Unless you tweaked your Win2K boxes which would disconnect
themselves after a certain inactivity period....

[snip]

Quote:>>         create mask = 0774
>>         directory mask = 0775
>>         printing = lprng
>>         mangle case = Yes
>>         hide unreadable = Yes
>>         veto files = /etc/passwd/usr/.?*/Mail/

>> [homes]
>>         comment = Home Directories
>>         valid users = %S
>>         guest ok = No
>>         create mask = 0664
> Why create mask 0664 on a users directory?

It's a special case. In one particular situation one user also maintains
another home directory which is used as "common" for a certain group.
Because his id is different than the groups, I have to make sure that
whatever he writes there has 0664 permissions for files or 775 for
directories.  The group's home directory is a softlink in his.

Quote:

>>         block size = 65536
>>         write cache size = 8388608
>>         writeable = Yes
>>         browseable = No

>> [printers]
>>         comment = All Printers
>>         path = /var/spool/samba
>>         printable = Yes
>>         browseable = No

> Passed testparm on my pc's, thats a good sign.

I would be surprised if it didn't. :-)

Quote:

[snip]
> Post the current Linux permissions of your /home directory and it's sub
> directories.

/home - 0700
/home/client - 0700
/home/group - 2775 (for my client's needs to inherit group ownership of the
parent directory, in this case, /home/group)  Any file written to
/home/group HAS TO HAVE 664 or 775 for a directory.

Again, I'm not sure why you want to take a look at the permissions if I
mentioned earlier that I could remove smaller files with no problems or
better yet, I could overwrite the same large file right away without any
issues.  It definitely looks to me like some kind of SAMBA locking
issue/bug...

 
 
 

1. DOS Sharing violation on SAMBA shared file

I'm running RH7.1 with Samba 2.0.7, and I have a w98 machine with a
fully shared drive. I modify and save a file on the windows box. Then
I view the file on a netscape browser on the windows box, accessed
through the file:// which is an html doc, open on the linux box in
emacs.

Once I view the html doc, I can no longer make changes to a gif in the
doc on the windows box. This gif is in My Documents on the windows
box. Instead I get a DOS Sharing violation.

Even if I close the browser and every application on both boxes, I
cannot make changes to that file unless I restart SAMBA on the linux
box.

I have write access on the linux box, and as I said full access on the
windows shared drive.

The only thing that looks odd is that root shows up as the owner of
all of the windows files on the linux box. I think that's because I
smbmounted the windows disk as root?

Any advice is appreciated.

-G

2. Devanagari Font

3. Share violation on file ...

4. FS A3000 /w NEC 3D monitor and a NEC 3D monitor

5. Share violation on mdb files

6. Problem with Java to Oracle via Native Methods

7. Removed File & Printer Sharing - How do I add back

8. ORA-01722 invalid number error & subquery

9. Suggestion: SMS should remove files from despoolr.box when package remove is sent

10. Sharing violation - Cannot rename/delete

11. Sharing violation and Read Only occurances

12. ARC Serve error EC=Sharing Violation

13. Sharing violation updating DLL