Permission denied attempting to create special device files

[avamaruser]

Hello,

For testing purposes I am attempting to create special device / character files on a Netapp volume using the linux utility 'mknod' but am getting permission denied messages:

root@XXXXX:/mnt/fas2040-vol0/#: mknod blk1 b 0 6
mknod: `blk1': Permission denied

The filer i am using is a Netapp fas2040 with Ontap 8.0. Also it is mounted via NFS on the linux client and i have fuller read/write permissions. Qtree containing the volume also has mixed(nfs/cifs) type. What else can I check for on the filer to make sure I have full control via NFS?

Note: I have anohter Netapp filer which I have no problem creating these device files. I tried comparing the settings between the two volumes and can't find the cause.

Thanks!

[rkaramchedu1]

make sure that the volume is exported with root squash disabled... i.e. make sure you have the option anon=0 option set..

Here's an example:

$ ssh -l root 172.16.56.141 "version; exportfs"
root@172.16.56.141's password: 
NetApp Release 8.0RC3X8 7-Mode
/vol/vfiler_80sql_vol1  -sec=sys,rw,nosuid
/vol/vol0/home  -sec=sys,rw,nosuid
/vol/volroot64  -sec=sys,rw,anon=0
/vol/vol0       -sec=sys,rw,anon=0,nosuid
/vol/src732_mir -sec=sys,rw,anon=0,nosuid

Now, as root

sh-3.2# mount 172.16.56.141:/vol/volroot64 /mnt
sh-3.2# cd /mnt
sh-3.2# mknod blk1 b 0 6
sh-3.2# ls -l blk1
brw-r--r--  1 root  wheel    0,   6 May 15 21:24 blk1
sh-3.2# 

HTH

[bikash]

Have you tried with just "UNIX" qtree security style instead of "mixed"?

[olaf]

Hi,

I found this bug report:

http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=21821

 The "mknod" command will fail when executed from a Linux NFS client.
 Creating a named pipe will result in a zero-byte file.  Creating a block
 or character file will give the error message "Operation not permitted",
 with no file created.

Workaround

 Since this behavior is coded directly within the Linux kernel itself,
 use something other than Linux when executing "mknod" over NFS.

In other words: it works on HP-UX, Solaris, etc.

This was the behaviour on old kernels though:

     I checked both the latest stable (2.2.14) and development (2.3.42)
     kernels and found this in fs/nfs/inode.c:

          /*
           * File system information
           */
          static struct file_system_type nfs_fs_type = {
               "nfs",
               0 /* FS_NO_DCACHE - this doesn't work right now*/,
               nfs_read_super,
               NULL
          };

     Compare this to a filesystem which allows the "dev" option to mount
     (in fs/ext2/super.c):

          static struct file_system_type ext2_fs_type = {
               "ext2",
               FS_REQUIRES_DEV /* | FS_IBASKET */,     /* ibaskets have unresolved bugs */
               ext2_read_super,
               NULL
          };

     So basically, whatever you do with "mount" from the user command
     regarding "dev" or "nodev" with an NFS filesystem will have no effect
     in the Linux kernel; it will always be "nodev".

Did you use another Linux kernel on the other Filer ?

Also, ONTAP 8, 7-Mode may behave differently then ONTAP 7, since the underlying layer is different.

Hope this helps.

Cheers,

O.

[rkaramchedu1]

Also, ONTAP 8, 7-Mode may behave differently then ONTAP 7, since the underlying layer is different.

Whoa - If it does behave differently, it's imperative that this stuff be *well* documented. Because many folks are upgrading to ONTAP 8 in predominantly NFS environments and if there are NFS implementation level changes that are not fully backward compatible and documented, then this could mean bad juju. *real* bad juju.

[olaf]

I would also suggest you open a case with tech support in your "area" and have them file

a bug report under ONTAP 8 7-Mode, either by the TSE who gets it (if he dares), or ask him

to go through an Escalation Engineer.

Also practical would be to trace the test with the Filer's pktt command.

Usage is described in a KB on now.netapp.com, a simple search will get you there quickest.

Make sure to use "-d /etc" as pamameters to store resulting trace in /etc instead of using the ringbuffer.

To reduce size, also filter on the IP of the client - for this particular issue other client accesses don't really matter.

It will create one file per given interface (or "all" interfaces) - the  largest file is likely the one to upload to the case.

Cheers,

O.

[avamaruser]

I checked the version and nfs export information, the /vol/vol0 which is where i want to create these files do have "anon=0"

fas2040> version
NetApp Release 8.0 7-Mode: Thu Mar 11 16:10:16 PST 2010
fas2040> exportfs
/vol/QA_data    -sec=sys,rw,anon=0
/vol/vol0/home  -sec=sys,rw,nosuid
/vol/vol0       -sec=sys,rw,anon=0,nosuid
/vol/vol1       -sec=sys,rw,nosuid

I am still getting the permission denied error when trying to create block files:

root@ads710-3:/mnt/fas2040-vol0/#: mknod blk1 b 0 6
mknod: `blk1': Permission denied

[avamaruser]

Yes, i tried changing the security style to UNIX but I still receieve the same errors.

[silvaconetapp]

We had the same problem with a new FAS2240-4 running 8.1.

Turns out setuid needs to be enabled for mknod to work so having nosuid in your exports may be the problem. Removing nosuid from our exports fixed this for us at least.