Highlighted
Robert_W_Brandt Absent Member.
Absent Member.
3186 views

Corrupt Files ( fstab/mount info)

I'm not sure if this is a Linux, NSS or Novell Client issue, but...

We will frequently see problems with corrupt files. (However it appears as if the file is not actually corrupt, but rather the user is unable to access the correctly)
For example, an end-user will access a Word or OpenOffice document, expecting to see their document, however what they see is text which resembles the FSTAB file and the MOUNT command output:
[INDENT]
rootfs / rootfs rw 0 0
udev /dev tmpfs rw 0 0
/dev/sda1 / ext3 rw,data=ordered 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
debugfs /sys/kernel/debug debugfs rw 0 0
devpts /dev/pts devpts rw 0 0
/dev/sda2 /var/log ext3 rw,data=ordered 0 0
/dev/sda3 /var/opt/novell ext3 rw,data=ordered 0 0
/dev/sdb2 /srv/sys ext3 rw,data=ordered 0 0
/dev/sdb3 /usr/snapvault/db ext3 rw,data=ordered 0 0
/dev/sdb2 /usr/novell/sys ext3 rw,data=ordered 0 0
fusectl /sys/fs/fuse/connections fusectl rw 0 0
novfs /var/opt/novell/nclmnt novfs rw 0 0
/dev/evms/DATA /opt/novell/nss/mnt/.pools/DATA nsspool rw 0 0
admin /_admin nssadmin rw 0 0
HOME /home nssvol rw 0 0
HOME /srv/home nssvol rw 0 0
GROUP /srv/group nssvol rw 0 0
nfsd /proc/fs/nfsd nfsd rw 0 0
proc /var/lib/ntp/proc proc rw 0 0
[/INDENT]
I thought the problem was a combination of using samba and having the Network Order changed on the client.

At first I modified the Registry Key HKLM\SYSTEM\CurrentControlSet\NetworkProvider\Order to ensure that the NetwareWorkstation was first (this is the default when installing the Novell Client, but I think some of our custom software messes up the default order). This did appear to solve the problem, but touching evey workstation was not an ideal solution.

A more permenant fix was to seperate Samba on another interface (i.e. Novell eDirectory and NCP only listened on the main IP and Samba only listened on the secondary IP) This seemed to solve the problem.

However, I just found another instance of the problem where neither of these fixes work and we still see the problem. I have even stopped Samba and saw no difference. But when I cat the file on the linux command line, I don't see the text I see on the Windows client??

The specs of the server are:
[INDENT]Linux servername 2.6.16.60-0.59.1-vmi #1 SMP Thu Jan 14 18:30:10 UTC 2010 i686 i686 i386 GNU/Linux
SLES10SP2 OES2a[/INDENT]

Thanks
Bob
Labels (2)
0 Likes
11 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Corrupt Files ( fstab/mount info)

robert,

It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.

Has your problem been resolved? If not, you might try one of the following options:

- Visit http://support.novell.com and search the knowledgebase and/or check all
the other self support options and support programs available.
- You could also try posting your message again. Make sure it is posted in the
correct newsgroup. (http://forums.novell.com)

Be sure to read the forum FAQ about what to expect in the way of responses:
http://forums.novell.com/faq.php

If this is a reply to a duplicate posting, please ignore and accept our apologies
and rest assured we will issue a stern reprimand to our posting bot.

Good luck!

Your Novell Product Support Forums Team
http://forums.novell.com/

0 Likes
ataubman Absent Member.
Absent Member.

Re: Corrupt Files ( fstab/mount info)

Bizarre, to be sure. Just to be clear, this only happens with users that don't have the Novell client, so non-NCP connections and non-NSS volumes?

Also it looks like you haven't patched for some time. We're now up to SLES 10 SP4 and OES2 SP3.

Andrew C Taubman (Sorry, support is not provided via e-mail) Opinions expressed above are not necessarily those of Micro Focus.
0 Likes
Robert_W_Brandt Absent Member.
Absent Member.

Re: Corrupt Files ( fstab/mount info)

Sorry the late reply, I guess the email notification isn't working...

I have been testing this and i can confirm that the only time the file "appears" to the corrupted is when access the file from a workstation via the Novell Client (NCP)

If I access the file via Samba, web or directly from the server console, the file is perfectly fine.

For testing, I created two IP Addresses on the server and bound the eDirectory to the first IP and Samba to the second.

Because of this I was able to map two drives (from the same workstation), one drive via the Novell Client and one drive to the Samba interface.
Accessing the same file found that only the NCP connection had the problem.
If I copied the file from the server to the desktop via NCP, the file was still corrupt.
If I accessed the file from the Samba mapping, it opened perfectly fine.
If I copied the file from the server to the desktop via Samba, the file was still perfect.
If i copied the same file back to the server, via NCP and tried to open it again, it opened fine??? Something about creating the file via NCP fixed the problem?

Again this problem is very hit and miss, so I can only troubleshoot when a problem pops up...

I don't know if the problem survives a server reboot (since I can't just bounce a production machine for one corrupt file...)?
I also don't know which log files I should be looking at to help solve the problem?

Thanks for any help you can provide.

Bob
0 Likes
Robert_W_Brandt Absent Member.
Absent Member.

Re: Corrupt Files ( fstab/mount info)

Sorry...

Also, I know their is a new service pack, but we made a decsion not to service pack since we were in the middle of a large rollout and thought it best to have all the server on the exact same software. ( we rollout out 100+ virtual servers)

But if we need to upgrade, we need to upgrade...

Thanks
0 Likes
ataubman Absent Member.
Absent Member.

Re: Corrupt Files ( fstab/mount info)

What desktop OS, SP, and client versions?

What cache and file commit settings do you have on the client? What oplock, cache and cross-protocol lock settings on the server?

Andrew C Taubman (Sorry, support is not provided via e-mail) Opinions expressed above are not necessarily those of Micro Focus.
0 Likes
ataubman Absent Member.
Absent Member.

Re: Corrupt Files ( fstab/mount info)

If this turns out to be a file cache, oplock or cross-protocol lock issue then yes, I'm going to be recommending patching.

Andrew C Taubman (Sorry, support is not provided via e-mail) Opinions expressed above are not necessarily those of Micro Focus.
0 Likes
Robert_W_Brandt Absent Member.
Absent Member.

Re: Corrupt Files ( fstab/mount info)

ataubman;2142347 wrote:
What desktop OS, SP, and client versions?

What cache and file commit settings do you have on the client? What oplock, cache and cross-protocol lock settings on the server?


It is happening on a number of different client versions but I will use mine as an example:
Windows XP SP3 (all the latest updates)
Novell Client 4.91 SP5 IR1
File Caching is ON
File Caching on exclusive opened files is OFF
File Commit is OFF

On the Server side:
OPLOCK_SUPPORT_LEVEL = 2
CROSS_PROTOCOL_LOCKS = 1
MAXIMUM_CACHED_FILES_PER_SUBDIRECTORY = 2048
MAXIMUM_CACHED_FILES_PER_VOLUME = 20000
MAXIMUM_CACHED_SUBDIRECTORIES_PER_VOLUME = 50000

Thanks
Bob
0 Likes
ataubman Absent Member.
Absent Member.

Re: Corrupt Files ( fstab/mount info)

OK, I'd suggest disabling everything as a test and see if that helps:

File Caching -> OFF

On the Server side:
OPLOCK_SUPPORT_LEVEL = 0
CROSS_PROTOCOL_LOCKS = 0

Andrew C Taubman (Sorry, support is not provided via e-mail) Opinions expressed above are not necessarily those of Micro Focus.
0 Likes
Robert_W_Brandt Absent Member.
Absent Member.

Re: Corrupt Files ( fstab/mount info)

Just wanted to check in. Like I said I can't reproduce this in the lab, so I have to wait for production problems...

Nothing useful has poped up yet, but I did implement the server suggestions on a couple servers so see if it helps. I'll get back to you as soon as I have something.

ataubman;2142825 wrote:
OK, I'd suggest disabling everything as a test and see if that helps:

File Caching -> OFF

On the Server side:
OPLOCK_SUPPORT_LEVEL = 0
CROSS_PROTOCOL_LOCKS = 0
0 Likes
Robert_W_Brandt Absent Member.
Absent Member.

Re: Corrupt Files ( fstab/mount info)

ataubman;2142825 wrote:
OK, I'd suggest disabling everything as a test and see if that helps:
File Caching -> OFF
On the Server side:
OPLOCK_SUPPORT_LEVEL = 0
CROSS_PROTOCOL_LOCKS = 0


Okay I have a result (I think)

I had two servers where I had this problem frequently. I disabled File Caching and OPLOCKS rebooted the server so it would take affect and have not seen the problem again (yet).

I left Cross Protocol Locks because we are using Samba and a third party backup utility.

I will keep an eye on this, but so far so good.

Bob
0 Likes
Robert_W_Brandt Absent Member.
Absent Member.

Re: Corrupt Files ( fstab/mount info)

Just to close out this call... I did find the cause.

Turns out I was did something I apparently shouldn't have. I will explain my stupidity in detail so other can avoid my mistake!

I had two volumes (HOME and GROUP) in one NSS partition and I was mounted the HOME volume twice, once at /srv/home and also at /home
I was mounting every as /srv/ for a number of reasons, but just incase the admins logged into the server I wanted it mounted at /home as well.

So using the mount command you would see something like:

/dev/evms/DATA on /opt/novell/nss/mnt/.pools/DATA type nsspool (rw,name=DATA)
admin on /_admin type nssadmin (rw)
HOME on /srv/home type nssvol (rw,name=HOME,norename)
HOME on /home type nssvol (rw,name=HOME,norename)
GROUP on /srv/group type nssvol (rw,name=GROUP,norename)

Normally mounting a filesystem it two places is a no-no, but I figured since the partition is first mounted, then the volumes, it would be like binding a directory to two other directory locations.
Also the reason I didn't just bind /home to /srv/home was that the timing of mounting the filesystems was off. It took too long for the NSS volumes to mount, so what happened was that /home was mounted to the emtpy directory not the NSS volume...


I knew that the odds of the same file being accessed at the same time in two different locations was slim to none. Regardless, I did extensive testing of this configuration and I never had any problems (in fact I was NEVER able to replicate this problem in the lab of on production machines).
Also, I was seeing corrupt file in the GROUP volume as well as the HOME volume so it never occured to me that this would be the problem...

Anyway, just for giggles, I stopped doing this and changed the /home folder to bind mount /srv/home. To get around the timing problem I used a _netdev mount type and created a init.d script that performed a "mount -a". all these hoops is the reason I didn't do this in the first place.
So using the mount command you would see something like:

/dev/evms/DATA on /opt/novell/nss/mnt/.pools/DATA type nsspool (rw,name=DATA)
admin on /_admin type nssadmin (rw)
HOME on /srv/home type nssvol (rw,name=HOME,norename)
GROUP on /srv/group type nssvol (rw,name=GROUP,norename)
/srv/home on /home type none (rw,bind,_netdev)


Well, we had a couple sites that were having these problems daily, so I implemented this configuration on those sites and the problems stopped immediately! After a week, I rolled this config out to the rest of the servers and we have not had a corrupt file since...

Thanks and sorry for wasting your time.

Bob
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.