Error using ontape with NFS mounted directory

[Sean Baker]

Hi All,

I'm wondering if anyone has seen this. We're running IDS 11.50.FC6 on Linux RHEL 5, and we use ontape to back up our IDS instances. We have been backing up to an NFS-mounted directory for years. Now we need to change the NFS server. In the past we've used either Windows servers of a NAS device for the NFS server.

The new NFS volume is on a Windows Server 2008 R2 machine. It's mounted with root access, just like we have always done. But ontape give an immediate error:

# ontape -s -L 0
Archive failed - function open archive tape failed code -1 errno 13

Program over.

I can read and copy large files on the NFS volume (90GB) with no problem, as root or Informix. The directories have the proper permissions (otherwise ontape complains). There's not much to setting up an NFS-shared volume on Windows. It seems like ontape is trying to open/create the archive file in a way that NFS doesn't like.

I also exported a directory from a different RHEL host we have, and ontape works fine going to that one. So it definitely seems like the problem is on the server side.

I've run out of things to try, so any ideas would be appreciated!

Thanks,

Sean.

[jrenaut]

Post by Sean Baker
Hi All,
I'm wondering if anyone has seen this. We're running IDS 11.50.FC6 on Linux RHEL 5, and we use ontape to back up our IDS instances. We have been backing up to an NFS-mounted directory for years. Now we need to change the NFS server. In the past we've used either Windows servers of a NAS device for the NFS server.
# ontape -s -L 0
Archive failed - function open archive tape failed code -1 errno 13
Program over.
I can read and copy large files on the NFS volume (90GB) with no problem, as root or Informix. The directories have the proper permissions (otherwise ontape complains). There's not much to setting up an NFS-shared volume on Windows. It seems like ontape is trying to open/create the archive file in a way that NFS doesn't like.
I also exported a directory from a different RHEL host we have, and ontape works fine going to that one. So it definitely seems like the problem is on the server side.
I've run out of things to try, so any ideas would be appreciated!
Thanks,
Sean.

Well, 1 thing I can think of is I seem to recall sometimes having mounted file systems having issues with setuid programs. Ontape should have the setuid and setgid bits on the executable. I don't know if that could be an issue on how the file system is exported on windows, or how to fix it, but that would be the one difference I can think of off the top of my head if you say you can read/write to the file system as root or informix, but ontape is having problems.

Jacques Renaut
IBM Informix Advanced Support
APD Team

[Sean Baker]

-----Original Message-----
Sent: Wednesday, April 02, 2014 12:33 AM
To: Sean Baker; Informix-List (E-Mail)
Subject: Re: Error using ontape with NFS mounted directory

Post by Sean Baker
Hi All,
I'm wondering if anyone has seen this. We're running IDS 11.50.FC6 on Linux

RHEL 5, and we use ontape to back up our IDS instances. We have been
backing up to an NFS-mounted directory for years. Now we need to change the
NFS server. In the past we've used either Windows servers of a NAS device for
the NFS server.

Post by Sean Baker
The new NFS volume is on a Windows Server 2008 R2 machine. It's mounted

with root access, just like we have always done. But ontape give an immediate

Post by Sean Baker
# ontape -s -L 0
Archive failed - function open archive tape failed code -1 errno 13
Program over.

From memory that is permission denied
try ontape -s -L 0 -t STDIO >/some/path/on/the/nfs/file
you might get a more meaningful error
--
Clive Eisen
GPG: 75056DD0

Thanks for the suggestions everyone.

I've tried chmod 777. The path is /ids_ifmx_archive/stdbs, so it's not a long path issue.

I verified that the setuid and setgid bits are set on the ontape executable. I tried turning those off (chmod 755) but still the same error.

The only think that kind of worked was using "-t STDIO" and sending that to a file on the NFS volume. Unfortunately I didn't get an error, it just worked. That makes sense because ontape is not directly creating the archive file. But that messes up my current ontape setup where I have TAPEDEV set to a directory so the archive files are automatically named with the date. I'd hate to lose that because of some funky server having an NFS problem.

Thanks,

Sean.

[jrenaut]

Post by Sean Baker

-----Original Message-----
Subject: Re: Error using ontape with NFS mounted directory

Post by Sean Baker
Hi All,
I'm wondering if anyone has seen this. We're running IDS 11.50.FC6 on Linux

RHEL 5, and we use ontape to back up our IDS instances. We have been
backing up to an NFS-mounted directory for years. Now we need to change the
NFS server. In the past we've used either Windows servers of a NAS device for
the NFS server.

Post by Sean Baker
The new NFS volume is on a Windows Server 2008 R2 machine. It's mounted

with root access, just like we have always done. But ontape give an immediate

Post by Sean Baker
# ontape -s -L 0
Archive failed - function open archive tape failed code -1 errno 13
Program over.

From memory that is permission denied
try ontape -s -L 0 -t STDIO >/some/path/on/the/nfs/file
you might get a more meaningful error
--
Clive Eisen
GPG: 75056DD0

Thanks for the suggestions everyone.
I've tried chmod 777. The path is /ids_ifmx_archive/stdbs, so it's not a long path issue.
I verified that the setuid and setgid bits are set on the ontape executable. I tried turning those off (chmod 755) but still the same error.
The only think that kind of worked was using "-t STDIO" and sending that to a file on the NFS volume. Unfortunately I didn't get an error, it just worked. That makes sense because ontape is not directly creating the archive file. But that messes up my current ontape setup where I have TAPEDEV set to a directory so the archive files are automatically named with the date. I'd hate to lose that because of some funky server having an NFS problem.
Thanks,
Sean.

My only other thought would be to take off the setuid/setgid bits (they can sometimes mess with strace's ability to get output depending on who the user is running the command) and get strace output from the ontape command to verify exactly what file that ontape is trying to open that is returning the error 13 (or EACCES).

The man page on Linux for open has the following for causes of EACCES error:

EACCES The requested access to the file is not allowed, or search per-
mission is denied for one of the directories in the path prefix
of pathname, or the file did not exist yet and write access to
the parent directory is not allowed. (See also path_resolu-
tion(2).)

Assuming you've verified all those conditions, maybe it's having a problem with some other file that isn't obvious, but hopefully will be from the strace output.

Jacques Renaut
IBM Informix Advanced Support
APD Team

[Clive Eisen]

Post by Sean Baker
Hi All,
I'm wondering if anyone has seen this. We're running IDS 11.50.FC6 on Linux RHEL 5, and we use ontape to back up our IDS instances. We have been backing up to an NFS-mounted directory for years. Now we need to change the NFS server. In the past we've used either Windows servers of a NAS device for the NFS server.
# ontape -s -L 0
Archive failed - function open archive tape failed code -1 errno 13
Program over.

From memory that is permission denied

try ontape -s -L 0 -t STDIO >/some/path/on/the/nfs/file

you might get a more meaningful error

--
Clive Eisen
GPG: 75056DD0

[Clive Eisen]

Post by Sean Baker
Thanks for the suggestions everyone.
I've tried chmod 777. The path is /ids_ifmx_archive/stdbs, so it's not a long path issue.
I verified that the setuid and setgid bits are set on the ontape executable. I tried turning those off (chmod 755) but still the same error.
The only think that kind of worked was using "-t STDIO" and sending that to a file on the NFS volume. Unfortunately I didn't get an error, it just worked. That makes sense because ontape is not directly creating the archive file. But that messes up my current ontape setup where I have TAPEDEV set to a directory so the archive files are automatically named with the date. I'd hate to lose that because of some funky server having an NFS problem.
Thanks,

It is trivial to bash script the functionality to name the backups by date, day of the week or whatever

here is one I use which gzips the archive as well

#!/bin/bash
cd /u01/archive
. ~/.bashrc
ontape -t STDIO -s -L 0 | gzip -9 > Level0-`/bin/date '+%a'`.gz