Re: cp failure to NetApp directory with CIFS security model

[Clarence Donath]

On Thu, 2007-11-01 at 08:36 +0100, Jim Meyering wrote:
> Fixing this for you may be tricky, since it sounds like
> your file system cannot be POSIX-compliant.
> 
> But first, have you tried a recent snapshot?
> 
>   http://meyering.net/cu/coreutils-6.9-ss.tar.gz
>   http://meyering.net/cu/coreutils-6.9-ss.tar.gz.sig
> 
> There have been changes in this area since 6.9.
> If that still fails, I suggest you run cp under strace or
> a debugger to see precisely which syscall is failing.  Let us know.
> The changes that I think are giving you trouble
> were required to eliminate some race conditions


Hello,

Thank you for investigating our issue.

This destination location is certainly not fully POSIX compliant.  It's
a method NetApp has developed to allow UNIX user access to be controlled
by Windows ACLs.

Using the recent snapshot exhibits the same behavior.


Running strace using cp v6.9-354-68c33a produces the following...

address@hidden:/p/inet->strace /usr/local/bin/cp /root/cron /p/inet
[snip]
stat64("/p/inet", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
stat64("/root/cron", {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
stat64("/p/inet/cron", 0xbfb66bf4)      = -1 ENOENT (No such file or
directory)
open("/root/cron", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
open("/p/inet/cron", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = -1
EPERM (Operation not permitted)
write(2, "/usr/local/bin/cp: ", 19/usr/local/bin/cp: )     = 19
write(2, "cannot create regular file `/p/i"..., 41cannot create regular
file `/p/inet/cron') = 41
write(2, ": Operation not permitted", 25: Operation not permitted) = 25
write(2, "\n", 1
)                       = 1
close(3)                                = 0
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(1)                           = ?

The resultant destination file is created, but left empty by 'cp'.
A second 'cp' will succeed since the file was created by the first 'cp'.


Running strace using cp v6.6 successfully copies the file, and produces
the following...

address@hidden:/p/inet->strace /usr/local/bin/cp /root/cron /p/inet
[snip]
stat64("/p/inet", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
stat64("/root/cron", {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
stat64("/p/inet/cron", 0xbf8e5954)      = -1 ENOENT (No such file or
directory)
open("/root/cron", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
open("/p/inet/cron", O_WRONLY|O_CREAT|O_LARGEFILE, 0644) = 4
fstat64(4, {st_mode=S_IFREG|0777, st_size=0, ...}) = 0
read(3, "address@hidden"..., 32768) = 486
write(4, "address@hidden"..., 486) = 486
close(4)                                = 0
close(3)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?

The new open() call causes cp to terminate.  Is it the O_EXCL causing
this?

What concerns me is the following from the open() man page...

        O_EXCL is broken on  NFS  file  systems; programs which rely on
it for performing
        locking tasks will contain a race condition.


Best regards,
Clarence Donath