Bug #2884
rm: <file> not removed: Permission denied
100%
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
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)
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
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?
Updated by Ryo Murakawa over 8 years ago
- Assignee set to Ryo Murakawa
- Tags changed from needs-triage to rm
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.