Project

General

Profile

Bug #2884

rm: <file> not removed: Permission denied

Added by Richard PALO almost 9 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
OS/Net (Kernel and Userland)
Target version:
-
Start date:
2012-06-15
Due date:
2014-01-28
% Done:

100%

Estimated time:
1.00 h
Difficulty:
Medium
Tags:
rm

Description

Not sure if this could be related to https://www.illumos.org/issues/2644 but I'm finding a file that, to me, is undeleteable.

Because the file could not be opened RW any more, a copie was created locally and I wanted to delete the file in order to replace with the newly, updated copie.

Can't delete.
changed to be the owner, no deal.

/export/dossiers$ ls -laphv t.ods
-rwxrwxrwx   1 richard  staff       524K juin 15 15:18 t.ods
     0:owner@:read_data/write_data/append_data/read_xattr/write_xattr/execute
         /read_attributes/write_attributes/read_acl/write_acl/write_owner
         /synchronize:allow
     1:group@:read_data/write_data/append_data/read_xattr/execute
         /read_attributes/read_acl/synchronize:allow
     2:everyone@:read_data/write_data/append_data/read_xattr/execute
         /read_attributes/read_acl/synchronize:allow
/export/dossiers$
/export/dossiers$ ls -laphdv ../dossiers
drwxrwxrwx+  5 root     root           6 juin 15 15:22 ../dossiers/
     0:everyone@:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow
/export/dossiers$ 
/export/dossiers$ touch s.test
/export/dossiers$ ls -laphv s.test 
-rwxrwxrwx+  1 richard  staff          0 juin 15 15:51 s.test
     0:everyone@:read_data/write_data/append_data/read_xattr/write_xattr
         /execute/delete_child/read_attributes/write_attributes/delete
         /read_acl/write_acl/write_owner/synchronize:inherited:allow
richard@smicro:/export/dossiers$ rm s.test 

initially this file was in a subdirectory a couple of levels more deep. I could 'mv t.ods ..'
to the top of the zfs fileset rpool/export/dossiers.
but if I try mv to, for example, my home directory:

/export/dossiers$ mv t.ods ~/
mv: cannot unlink t.ods: Permission denied

this dataset has readonly=false, aclmode & aclinherit=passthrough

how to delete this file, and what might be the cause?

even tried to change to the same as the touched file but no dice:

/export/dossiers$ /usr/bin/chmod A=owner@:read_data/write_data/append_data/read_xattr/write_xattr/execute/delete_child/read_attributes/write_attributes/delete/read_acl/write_acl/write_owner/synchronize:inherited:allow t.ods
/export/dossiers$ ls -v t.ods
-rwx------+  1 richard  staff     536387 juin 15 15:18 t.ods
     0:owner@:read_data/write_data/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /write_acl/write_owner/synchronize:inherited:allow
/export/dossiers$ rm t.ods
rm: t.ods not removed: Permission denied

#1

Updated by Richard PALO almost 9 years ago

just for grins I trussed the rm command, seems unlink is where it becomes toxic:

/export/dossiers$ truss rm t.ods
execve("/usr/bin/rm", 0x08047D80, 0x08047D8C)  argc = 2
sysinfo(SI_MACHINE, "i86pc", 257)        = 6
mmap(0x00000000, 32, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEFB0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEFA0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEF90000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEF80000
memcntl(0xFEFB7000, 32112, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
memcntl(0x08050000, 4552, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
resolvepath("/usr/lib/ld.so.1", "/lib/ld.so.1", 1023) = 12
resolvepath("/usr/bin/rm", "/usr/bin/rm", 1023)    = 11
sysconfig(_CONFIG_PAGESIZE)            = 4096
stat64("/usr/bin/rm", 0x080479C4)        = 0
open("/var/ld/ld.config", O_RDONLY)        Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08047174)        = 0
resolvepath("/lib/libc.so.1", "/lib/libc.so.1", 1023) = 14
open("/lib/libc.so.1", O_RDONLY)        = 3
mmapobj(3, MMOBJ_INTERPRET, 0xFEFA0D90, 0x080471E0, 0x00000000) = 0
close(3)                    = 0
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEE30000
memcntl(0xFEE40000, 179060, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
mmap(0x00010000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEE20000
getcontext(0x08047824)
getrlimit(RLIMIT_STACK, 0x0804781C)        = 0
getpid()                    = 10960 [10959]
lwp_private(0, 1, 0xFEE22A40)            = 0x000001C3
setustack(0xFEE22AA0)
sysi86(SI86FPSTART, 0xFEF79C24, 0x0000133F, 0x00001F80) = 0x00000001
open("/usr/lib/locale//fr_FR.UTF-8/LC_CTYPE/LCL_DATA", O_RDONLY) = 3
fstat(3, 0x08047740)                = 0
brk(0x08063788)                    = 0
brk(0x0806B788)                    = 0
llseek(3, 0, SEEK_CUR)                = 0
llseek(3, 0, SEEK_SET)                = 0
fstat64(3, 0x080475D0)                = 0
brk(0x0806B788)                    = 0
brk(0x08073788)                    = 0
fstat64(3, 0x080474E0)                = 0
ioctl(3, TCGETA, 0x08047580)            Err#25 ENOTTY
read(3, " R u n e M a g 1 U T F -".., 30208)    = 30188
brk(0x08073788)                    = 0
brk(0x0807D788)                    = 0
llseek(3, 0, SEEK_CUR)                = 30188
close(3)                    = 0
open("/usr/lib/locale//fr_FR.UTF-8/LC_NUMERIC/LCL_DATA", O_RDONLY) = 3
fstat(3, 0x08047B90)                = 0
read(3, " ,\nC2A0\n 3\n", 7)            = 7
close(3)                    = 0
open("/usr/lib/locale//fr_FR.UTF-8/LC_TIME/LCL_DATA", O_RDONLY) = 3
fstat(3, 0x08047BA0)                = 0
read(3, " j a n v .\n fC3A9 v r .".., 319)    = 319
close(3)                    = 0
open("/usr/lib/locale//fr_FR.UTF-8/LC_COLLATE/LCL_DATA", O_RDONLY) = 3
fstat(3, 0x08047BD0)                = 0
mmap(0x00000000, 75408, PROT_READ, MAP_PRIVATE, 3, 0) = 0xFEE0C000
close(3)                    = 0
open("/usr/lib/locale//fr_FR.UTF-8/LC_MONETARY/LCL_DATA", O_RDONLY) = 3
fstat(3, 0x08047B90)                = 0
read(3, " E U R  \nE282AC\n ,\nC2".., 47)    = 47
close(3)                    = 0
open("/usr/lib/locale//fr_FR.UTF-8/LC_MESSAGES/LCL_DATA", O_RDONLY) = 3
fstat(3, 0x08047BA0)                = 0
read(3, " ^ ( ( [ o O ] ( [ u U ]".., 82)    = 82
close(3)                    = 0
sysconfig(_CONFIG_PAGESIZE)            = 4096
ioctl(0, TCGETA, 0x08047CE0)            = 0
lstat64("t.ods", 0x08047C30)            = 0
faccessat(AT_FDCWD, "t.ods", W_OK, AT_EACCESS)    = 0
unlink("t.ods")                    Err#13 EACCES
open("/usr/lib/locale/fr_FR.UTF-8/LC_MESSAGES/SUNW_OST_OSCMD.mo", O_RDONLY) Err#2 ENOENT
open("/usr/lib/locale/fr_FR.UTF-8/LC_MESSAGES/SUNW_OST_OSLIB.mo", O_RDONLY) Err#2 ENOENT
fstat64(2, 0x08046C60)                = 0
rm: write(2, " r m :  ", 4)                = 4
t.odswrite(2, " t . o d s", 5)            = 5
 not removed: write(2, "   n o t   r e m o v e d".., 14)    = 14
Permission deniedwrite(2, " P e r m i s s i o n   d".., 17)    = 17

write(2, "\n", 1)                = 1
_exit(2)
#2

Updated by Jim Klimov almost 9 years ago

This sounds like an "immutable" or "nounlink" or similar flag is set on the file, most of the symptoms match - except that in my tests an immutable file can't be moved/renamed either - while you could move yours; so there may be some similar flags in play. Or a ZFS corruption :)
Here's my test; note that immutability is not seen via ACLs, and note that GNU chmod does not modify these flags:

# touch A
# ls -v A
-rw-r--r--   1 root     root           0 Jun 15 22:48 A
     0:owner@:read_data/write_data/append_data/read_xattr/write_xattr
         /read_attributes/write_attributes/read_acl/write_acl/write_owner
         /synchronize:allow
     1:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
     2:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

# /usr/bin/chmod S+ci A
# ls -v A              
-rw-r--r--   1 root     root           0 Jun 15 22:48 A
     0:owner@:read_data/write_data/append_data/read_xattr/write_xattr
         /read_attributes/write_attributes/read_acl/write_acl/write_owner
         /synchronize:allow
     1:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
     2:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

# rm A
rm: A: override protection 644 (yes/no)? y
rm: A not removed: Not owner

# mkdir tmp
# mv A tmp
mv: cannot rename A to tmp/A: Not owner

# ln A tmp/B
# rm -f tmp/B
### NOTE that this visibly seems to succeed - but it silently doesn't

# rm -f tmp/B; echo $?
2
# ln A tmp/B
ln: tmp/B: File exists
# rm tmp/B; echo $?   
rm: tmp/B: override protection 644 (yes/no)? y
rm: tmp/B not removed: Not owner
2

# /usr/bin/chmod S-ci A
# mv A tmp
# rm tmp/A
# rm tmp/B; echo $?    
0
# rm -rf tmp

# uname -a
SunOS openindiana 5.11 oi_151a4 i86pc i386 i86pc

#3

Updated by Richard PALO almost 9 years ago

Hmm, not so sure. Here is a comparison with the [deletable] touched file...
nb , /usr/gnu/bin is not in my path .... $PATH = /usr/bin:/usr/sbin:/sbin)

/export/dossiers$ /usr/bin/ls -dV t.ods
-rwxrwxrwx+  1 richard  staff     536387 juin 15 15:18 t.ods
              everyone@:rwxpdDaARWcCos:------I:allow
/export/dossiers$ /usr/bin/ls -dV t.t
-rwxrwxrwx+  1 richard  staff          0 juin 15 16:38 t.t
              everyone@:rwxpdDaARWcCos:------I:allow
/export/dossiers$ /usr/bin/ls -/ v t.ods
-rwxrwxrwx+  1 richard  staff     536387 juin 15 15:18 t.ods
                {archive,nohidden,noreadonly,nosystem,noappendonly,nonodump,noimmutable,noav_modified,noav_quarantined,nonounlink,nooffline,nosparse}
/export/dossiers$ /usr/bin/ls -/ v t.t
-rwxrwxrwx+  1 richard  staff          0 juin 15 16:38 t.t
                {archive,nohidden,noreadonly,nosystem,noappendonly,nonodump,noimmutable,av_modified,noav_quarantined,nonounlink,nooffline,nosparse}

(note, I previously set the acl to 'owner' and not 'everyone' for t.ods, this should make it easier to compare)

the only difference is av_modified which, if I understand correctly, means simply that the antivirus should perhaps check a modified file, and this file was modified with OOO calc previously.

What is strange, is that afterwords I tried your example:

/export/dossiers$ /usr/bin/chmod S-ci t.ods
/export/dossiers$ /usr/bin/ls -/ v t.ods
-rwxrwxrwx+  1 richard  staff     536387 juin 15 15:18 t.ods
                {archive,nohidden,noreadonly,nosystem,noappendonly,nonodump,noimmutable,noav_modified,noav_quarantined,nonounlink,nooffline,nosparse}
/export/dossiers$ /usr/bin/ls -/ v t.t
-rwxrwxrwx+  1 richard  staff          0 juin 15 16:38 t.t
                {archive,nohidden,noreadonly,nosystem,noappendonly,nonodump,noimmutable,av_modified,noav_quarantined,nonounlink,nooffline,nosparse}
/export/dossiers$ /usr/bin/ls -dV t.t
-rwxrwxrwx+  1 richard  staff          0 juin 15 16:38 t.t
              everyone@:rwxpdDaARWcCos:------I:allow
/export/dossiers$ /usr/bin/ls -dV t.ods
-rwxrwxrwx+  1 richard  staff     536387 juin 15 15:18 t.ods
              everyone@:rwxpdDaARWcCos:------I:allow
/export/dossiers$ rm t.ods
/export/dossiers$ rm t.t
/export/dossiers$ ls
Documents  test

In summary,

1. THANKS, I could finally delete my file
2. I must be dense, because I seem to be able to display mutability with 'ls -/ v', and it seems ok. perhaps the bug is with ls displaying the flags? then naturally it would be trial and miss to guess what the real state is.

so I recreated the test like you and it does give different results:

/export/dossiers$ touch t.t
/export/dossiers$ /usr/bin/chmod S+ci t.t
chmod: ERROR: cannot set the following attributes on t.t: not privileged
        {immutable}
/export/dossiers$ pfexec /usr/bin/chmod S+ci t.t
/export/dossiers$ /usr/bin/ls -dV t.t
-rwxrwxrwx+  1 richard  staff          0 juin 16 07:14 t.t
              everyone@:rwxpdDaARWcCos:------I:allow
/export/dossiers$ /usr/bin/ls -/ v t.t
-rwxrwxrwx+  1 richard  staff          0 juin 16 07:14 t.t
                {archive,nohidden,noreadonly,nosystem,noappendonly,nonodump,immutable,av_modified,noav_quarantined,nonounlink,nooffline,nosparse}
/export/dossiers$ rm t.t
rm: t.t: override protection 777 (oui/non)? oui
rm: t.t not removed: Not owner
/export/dossiers$ ls
Documents  t.t        test
/export/dossiers$ pfexec rm t.t
rm: t.t: override protection 777 (oui/non)? oui
rm: t.t not removed: Not owner
/export/dossiers$ pfexec /usr/bin/chmod S-ci t.t
/export/dossiers$ rm t.t

notice that the immutable bit is displayed correctly therefore I don't believe it is exactly the case I had, but definitely related.. If memory serves, was there not some ACL work done in illumos, is it possible that some boundary condition is triggered around there?

#4

Updated by Ryo Murakawa over 8 years ago

  • Assignee set to Ryo Murakawa
  • Tags changed from needs-triage to rm
#5

Updated by Ken Mays about 7 years ago

  • Due date set to 2014-01-28
  • Category set to OS/Net (Kernel and Userland)
  • Assignee changed from Ryo Murakawa to OI illumos
  • % Done changed from 0 to 100
  • Estimated time set to 1.00 h

Seems fixed according to user. We've updated coreutils for hipster as well. Closing ticket.

#6

Updated by Ken Mays about 7 years ago

  • Status changed from New to Closed

Also available in: Atom PDF