"Brendan C. LeFebvre" wrote in message
news:1134820051.427820.37630@g14g2000cwa.googlegro ups.com...
> We came in yesterday morning to learn that our Linux server had
> suffered a power outage overnight. Fortunately, we started up again and
> there were no problems with disk or data corruption that we could
> detect, but suddenly we had a problem when accessing the Samba shares
> from our Windows 2000 workstation. The server is running Fedora Core 3
> and samba-3.0.10-1.fc3.

Did you do an "fsck" on the down system? And has the user on the Windows box
logged out and back in, to make sure that any mounted shares are released?

> Let's call our user "bob". Before this outage, everything was working
> fine. He had full access to the share, which we'll call SHARE. After
> the outage, logged in at his W2K station, he can create and modify
> files, but not delete them. An attempt to do so results in the Windows
> error "Cannot delete : Access is denied. The source file may be
> in use."
>
> The directory to which SHARE is mapped has 777 permission. Its user
> owner is someone other than "bob", but its group owner is a group that
> contains "bob".

Take a look at the directory from the Linux file. There may be lock files
left behind, often starting with a "~".. Get rid of those and you may fix
the problem.

> One thought I had was that perhaps unbeknownst to us we had long ago
> made some sort of crippling change in our smb.conf but then neglected
> to restart the daemon, preventing the error from arising until now. But
> I found a backup of smb.conf dated some time ago and the one currently
> in place matches it. Still, I cannot rule this possibility out
> entirely.
>
> One last thing: if I am logged into the Linux station as "bob", I have
> full access and can create, modify, and delete files from the directory
> to which SHARE is mapped.

So the file system is alive.

> So the only thing that has changed for "bob" is that he cannot delete
> files from the shares in which he had free reign before the outage.
> This might not be a big problem except that Photoshop refuses to save
> documents at all when it cannot delete its temp files. So unfortunately
> our work is more or less halted until I can get this fixed.

Can "bob" create a new file and delete that? And has he logged out and back
in?

Brendan C. LeFebvre wrote:

.....
> Let's call our user "bob". Before this outage, everything was working
> fine. He had full access to the share, which we'll call SHARE. After
> the outage, logged in at his W2K station, he can create and modify
> files, but not delete them. An attempt to do so results in the Windows
> error "Cannot delete : Access is denied. The source file may be
> in use."
>
> The directory to which SHARE is mapped has 777 permission. Its user
> owner is someone other than "bob", but its group owner is a group that
> contains "bob".
>
.....
> One last thing: if I am logged into the Linux station as "bob", I have
> full access and can create, modify, and delete files from the directory
> to which SHARE is mapped.
>
So the problem is with windows, not linux filesystem. Sometimes security
related windows updates create similar problems, or virus scanner updates.
You may try a more recent samba version with more tweaks to overcome the
windows "extensions" to the smb/cifs protocol.
--
vista policy violation: Microsoft optical mouse detected penguin patterns
on mousepad. Partition scan in progress to remove offending
incompatible products. Reactivate MS software.
Linux 2.6.12-mm2 [LinuxCounter#295241,ICQ#4918962]

Brendan C. LeFebvre wrote:

snip
>
> One thought I had was that perhaps unbeknownst to us we had long ago
> made some sort of crippling change in our smb.conf but then neglected
> to restart the daemon, preventing the error from arising until now. But
> I found a backup of smb.conf dated some time ago and the one currently
> in place matches it. Still, I cannot rule this possibility out
> entirely.
>
snip

>
> Brendan LeFebvre

This is not going to help you resolve your problem, but I'll say it
anyway: afaik changes to smb.conf take effect pretty much immediately
(a couple of minutes?), not the next time Samba gets restarted.