6

I've tried to make the title the most meaningfull I could but it still looks ugly.

The premises.

We are using RHEL3-U8 as OS on most servers here, don't ask me why or suggest to upgrade, it's not on today's schedule. That means kernel used is 2.4.21 I have no access to the remote server, but I know it is a netApp NAS rack.

$> smbclient --version
Version 3.0.9-1.3E.9

Here is the /etc/fstab line :

//NASHOSTNAME/share /mnt/mydir smbfs ro,uid=123,gid=123,workgroup=XXXX,credentials=/somefile 0 0

Here is the following mount output line

//NASHOSTNAME/share on /mnt/mydir type smbfs (0)


The symptoms.

I can list the share without problems, even cd in there. The issue appears if I try to read any file :

$> cat /mnt/mydir/fileX.txt
cat: /mnt/mydir/fileX.txt: Input/output error

In the system logs (/var/log/kernel for example) the following errors appear.

Jul 30 15:40:02 hostname kernel: smb_errno: class ERRHRD, code 31 from command 0x2
Jul 30 15:40:02 hostname kernel: smb_errno: class ERRHRD, code 31 from command 0x2
Jul 30 15:40:02 hostname kernel: smb_open: fileX.txt open failed, result=-5
Jul 30 15:40:02 hostname kernel: smb_errno: class ERRHRD, code 31 from command 0x2
Jul 30 15:40:02 hostname kernel: smb_errno: class ERRHRD, code 31 from command 0x2
Jul 30 15:40:02 hostname kernel: smb_open: fileX.txt open failed, result=-5
Jul 30 15:40:02 hostname kernel: smb_readpage_sync: fileX.txt open failed, error=-5

The ERRHRD code 0x001F error is "General hardware failure" although it seems samba sometimes uses it for a different purpose, see http://www.ubiqx.org/cifs/SMB.html [Strange behaviour Alert]

Additionnal informations : There is another SMB mountpoint on the system pointing to a (linux) host using samba and this one works.


What I have tried.

I have tried adding debug=4 to the mounting options and remounting the share and the logs still look the same.

I have tried to mount the share with smbclient and I am able to fetch files with the get command.

Both targets are in the same subnet, so network problem should be out, even if the LAN goes through a VPN with optimizers, MTU has already been decreased to 1450.

I can also mount the share through NFS but then the files are all root.root 700 and I need to read them with another user...

mveroone
  • 447
  • 7
  • 22
  • What happens when you try an IP address instead of NOSHOSTNAME? I assume you misquoted the line from /etc/fstab - the first column should have backslashes \\ not regular slashes / – tmo Aug 22 '13 at 19:57
  • I tried with IP address, same problem. And i think you're wrong when asking me to use \\ instead of // which is the proper way to call a network disk in linux... – mveroone Aug 23 '13 at 07:34
  • 2
    Is there a reason you're using SMB instead of NFS to the NetApp? What is the output from the following commands "qtree status", "cifs share" and "wcc -u 123" when run on the netapp the NetApp box? I assume mounting the NetApp volume using what ever user uid 123 maps to works from a Windows box? The way a NetApp maps a user ID back to a CIFS user depends on the settings for the volume/qtree you are writing to, we need to know more on the NetApp side to help here. – TheFiddlerWins Aug 23 '13 at 18:35
  • Problem is that I have no hand on the netApp here. All I know is it works well using the same credentials/directory from another server. – mveroone Aug 24 '13 at 11:10
  • This is going to be on the NetApp side. As old as the RHEL version is here, the stack was more than capable of doing what you need. You're going to need access to the NetApp. – ewwhite Aug 29 '13 at 13:26

1 Answers1

1

Realizing that you've moved on to bigger and better things, I still feel compelled to comment....

I've dealt with some pretty crazy setups on much older hardware. Even some with NAS involved, and Samba was the only route to go.

I would recommend looking at the NTFS-style permissions on the files stored in the NAS. If possible, get access to a Windows-based system that can access the share you're mounting, then look at the Permissions of the files. Assuming your smb.conf is using Active Directory (and not "share" or "user" permissions), then any files on the share that permit "Domain Users" to read them, should work.

A very good test would be....can you create a file in the Samba-mount from your RHEL3 system? I realize you're mounting the share read-only, but is it actually shared-out from the NAS with read-write permissions?

Signal15
  • 943
  • 7
  • 27
  • I'm very sorry I didn't came back to this question to say it has been resolved this week. The problem was within the network, some packets were getting corrupted, which broke any communication. Thanks for the valuable inputs anyway. – mveroone Oct 03 '13 at 15:18
  • Hey, no problem! Glad it was that easy of a fix :D – Signal15 Oct 03 '13 at 15:41
  • I'm actually ripping my hair off. The problem came back, but nos there doesn't seem to be network problems anymore. I can download a file through FTP on the server but not read it from command-line... – mveroone Oct 28 '13 at 08:51
  • You've tried unmounting the Samba-share from the NAS, right? Sometimes I've had to unmount it, check /etc/mnttab, find out it's still listed there, then force-unmount it. – Signal15 Oct 28 '13 at 12:54
  • Unfortunately I can't access the corporate NAS. But I have already tried unmounting/remounting the share on the server. What's really weird is that smbclient works, and even worse. I have a FTP server installed on this server, and you can download files located in the SMB mount, even though you can't access them from the command-line... – mveroone Oct 28 '13 at 13:02
  • Nevermind, the FTP maps to another folder. – mveroone Oct 30 '13 at 08:26