AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20090324171417.39009e6d@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:mail.onstor.net
NSV:
SSH:
R:<richard.lareau@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@exch1.onstor.net/INBOX	0	BC1C2764A7054243981C090737363857@cssltrhollenbeck
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 24 Mar 2009 17:14:59 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
Cc: Rich LaReau <richard.lareau@onstor.com>
Subject: Re: Unable to delete a file in an NFS mounted directory - case
 11757
Message-ID: <20090324171459.6850164a@ripper.onstor.net>
In-Reply-To: <BC1C2764A7054243981C090737363857@cssltrhollenbeck>
References: <200903241348.n2ODmFL14132@mailhost-rtp.css.glasshouse.com>
	<2779531E7C760D4491C96305019FEEB52AC8B56DD1@exch1.onstor.net>
	<BC1C2764A7054243981C090737363857@cssltrhollenbeck>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Rich,

I sent Alan an email trying to tell him that this is almost certainly
pilot error, ie., that the directory permissions are what's not
allowing the deletes or renames.  I'm not sure if he missed the email
or doesn't believe me.  But the directory permissions and ownership
wasn't shown in the email, so I can't check it myself.  A file's
ownership and permissions isn't what controls whether it can be deleted
or renamed, it's the directory permissions which control that.

The stale NFS handle error is either a bug on our part or a bug on the
client side, I can't tell which.  But I haven't heard of this happening
anywhere else, so I'm guessing it's the client side.  But I won't bet
my pension on it ~:^)


On Tue, 24 Mar 2009 16:45:41 -0700 "Rick Hollenbeck (Glasshouse)"
<rhollenbeck@css.glasshouse.com> wrote:

> I=E2=80=99m not sure about this, you might try rmmod =E2=80=93f and if th=
at doesn=E2=80=99t
> work see if you can see what is using it with fuser or lsof. It is
> definitely is or was a block device.
>=20
> Richard B. Hollenbeck | Systems Support Engineer
> Main: 800-328-7739 | Office: 919 767-5811
> Glasshouse Technologies
> Dedication * Teamwork * Integrity * Enthusiasm
>=20
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed.  If you have received this email in error please
> notify the system manager. This message contains confidential
> information and is intended only for the individual named. If you are
> not the named addressee you should not disseminate, distribute or
> copy this e-mail. ________________________________ From: Rich LaReau
> [mailto:richard.lareau@onstor.com] Sent: Tuesday, March 24, 2009 7:34
> PM To: Alan Cooke (Glasshouse); dl-cstech Subject: RE: Unable to
> delete a file in an NFS mounted directory - case 11757
>=20
> I learned that "b" stands for "block device."
>=20
> ________________________________
> From: Alan Cooke (Glasshouse)
> Sent: Tuesday, March 24, 2009 6:48 AM
> To: dl-cstech
> Subject: Unable to delete a file in an NFS mounted directory - case
> 11757 Hi All,
> Customer is unable to rm the file:
> br-x------ 0 root root 0 0x000000 Jan 1
> 1970 /shared-users/zoomit/ips/archived_reports/sender_enroller/2008/04/P9=
000001101SA/4/d82e9121-0cfd-4f95-851a-5f01ea70def9.xml
>=20
> I have a customer =E2=80=93 ISABEL =E2=80=93 in Belgium who have migrated=
 data to the
> Onstor and are now accessing that data via NFS. They have had various
> problems and have had to eek this volume twice to get it stable. They
> now have a file which is proving stubborn to go.
>=20
> When they try to rm or mv it they get permission denied.
> If they try to chmod it they get Stale NFS file handle
>=20
> Clearly this file should not be here as it is 0 size, dated Unix
> inception =E2=80=93 Jan 1st 1970 and as a blocked device the major and mi=
nor
> numbers are zero. It is tempting to leave it but it may cause
> problems later on.
>=20
> They have run eek on the volume at least twice recently and it all
> comes out clean now.
>=20
> Any suggestions on removing this?
>=20
> Regards =E2=80=A6 Aln.
>=20
