Can't remove a file with file mode bits a+rw












3















I have a file with the following file mode bits (a+rw):



[0] mypc<johndoe>:~>sudo touch /tmp/test    
[0] mypc<johndoe>:~>sudo chmod a+rw /tmp/test
[0] mypc<johndoe>:~>ls -l /tmp/test
-rw-rw-rw- 1 root root 0 Mar 13 11:09 /tmp/test


Why can't I remove the file?



[0] mypc<johndoe>:~>rm  /tmp/test
rm: cannot remove '/tmp/test': Operation not permitted









share|improve this question



























    3















    I have a file with the following file mode bits (a+rw):



    [0] mypc<johndoe>:~>sudo touch /tmp/test    
    [0] mypc<johndoe>:~>sudo chmod a+rw /tmp/test
    [0] mypc<johndoe>:~>ls -l /tmp/test
    -rw-rw-rw- 1 root root 0 Mar 13 11:09 /tmp/test


    Why can't I remove the file?



    [0] mypc<johndoe>:~>rm  /tmp/test
    rm: cannot remove '/tmp/test': Operation not permitted









    share|improve this question

























      3












      3








      3








      I have a file with the following file mode bits (a+rw):



      [0] mypc<johndoe>:~>sudo touch /tmp/test    
      [0] mypc<johndoe>:~>sudo chmod a+rw /tmp/test
      [0] mypc<johndoe>:~>ls -l /tmp/test
      -rw-rw-rw- 1 root root 0 Mar 13 11:09 /tmp/test


      Why can't I remove the file?



      [0] mypc<johndoe>:~>rm  /tmp/test
      rm: cannot remove '/tmp/test': Operation not permitted









      share|improve this question














      I have a file with the following file mode bits (a+rw):



      [0] mypc<johndoe>:~>sudo touch /tmp/test    
      [0] mypc<johndoe>:~>sudo chmod a+rw /tmp/test
      [0] mypc<johndoe>:~>ls -l /tmp/test
      -rw-rw-rw- 1 root root 0 Mar 13 11:09 /tmp/test


      Why can't I remove the file?



      [0] mypc<johndoe>:~>rm  /tmp/test
      rm: cannot remove '/tmp/test': Operation not permitted






      linux permissions rm chmod chown






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked 7 hours ago









      haba713haba713

      1617




      1617






















          2 Answers
          2






          active

          oldest

          votes


















          7














          The /tmp directory is conventionally marked with the restricted deletion flag, which appears as a permission letter t or T in ls output.



          Restricted deletion implies several things. In the general case, it implies that only the owner of the file, or the owner of /tmp itself, can delete a file/directory in /tmp.



          You can not delete the file, because you are not the owner, which is root. Try running rm with sudo which you probably forgot.



          sudo rm /tmp/test


          More specifically to Linux alone, the restricted deletion flag (on a world-writable directory such as /tmp) also enables the protected_symlinks, protected_hardlinks, protected_regular, and protected_fifos restrictions, which in such directories respectively prevent users from following symbolic links that they do not own, prevent users making hard links to files that they do not own, prevents users opening FIFOs that they do not own, and prevents users from open existing files that they do not own when they expected to create them.



          This will surprise you with permissions errors when doing various further things as root when you do use sudo.



          More on these at question like "Hard link permissions behavior different between CentOS 6 and CentOS 7" , "Symbolic link not working as expected when changes user", and "Group permissions for root not working in /tmp".






          share|improve this answer










          New contributor




          Samuel P. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.
















          • 1





            May also be worth stressing the fundamental point that deleting a file depends on its directory's permissions, not on the file's permissions?

            – gidds
            2 hours ago



















          3














          The problem seems to be the sticky bit of /tmp.




          $ ls -ld /tmp
          drwxrwxrwt⃝ 1 root root 1044 Mar 13 12:09 /tmp


          https://en.wikipedia.org/wiki/Sticky_bit




          When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root user can rename or delete the file. Without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of the file's owner. Typically this is set on the /tmp directory to prevent ordinary users from deleting or moving other users' files.







          share|improve this answer





















          • 1





            This is the point where one looks at the permissions of /tmp, observes that one already did have write access, and realizes that this is clearly not the right answer. (-:

            – JdeBP
            6 hours ago











          • Hi JdeBP! Thank you for the comment. I changed the answer now.

            – haba713
            6 hours ago






          • 3





            In any case, the permissions of the file itself are irrelevant when it comes to renaming it (as mv does) or unlinking it to a directory (as rm does). In both cases, it's the directory(ies) you modify, not the file.

            – Stéphane Chazelas
            6 hours ago











          • Stéphane Chazelas, thank you for the information! You have read your Stevens well. :-)

            – haba713
            6 hours ago











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "106"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f506039%2fcant-remove-a-file-with-file-mode-bits-arw%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          7














          The /tmp directory is conventionally marked with the restricted deletion flag, which appears as a permission letter t or T in ls output.



          Restricted deletion implies several things. In the general case, it implies that only the owner of the file, or the owner of /tmp itself, can delete a file/directory in /tmp.



          You can not delete the file, because you are not the owner, which is root. Try running rm with sudo which you probably forgot.



          sudo rm /tmp/test


          More specifically to Linux alone, the restricted deletion flag (on a world-writable directory such as /tmp) also enables the protected_symlinks, protected_hardlinks, protected_regular, and protected_fifos restrictions, which in such directories respectively prevent users from following symbolic links that they do not own, prevent users making hard links to files that they do not own, prevents users opening FIFOs that they do not own, and prevents users from open existing files that they do not own when they expected to create them.



          This will surprise you with permissions errors when doing various further things as root when you do use sudo.



          More on these at question like "Hard link permissions behavior different between CentOS 6 and CentOS 7" , "Symbolic link not working as expected when changes user", and "Group permissions for root not working in /tmp".






          share|improve this answer










          New contributor




          Samuel P. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.
















          • 1





            May also be worth stressing the fundamental point that deleting a file depends on its directory's permissions, not on the file's permissions?

            – gidds
            2 hours ago
















          7














          The /tmp directory is conventionally marked with the restricted deletion flag, which appears as a permission letter t or T in ls output.



          Restricted deletion implies several things. In the general case, it implies that only the owner of the file, or the owner of /tmp itself, can delete a file/directory in /tmp.



          You can not delete the file, because you are not the owner, which is root. Try running rm with sudo which you probably forgot.



          sudo rm /tmp/test


          More specifically to Linux alone, the restricted deletion flag (on a world-writable directory such as /tmp) also enables the protected_symlinks, protected_hardlinks, protected_regular, and protected_fifos restrictions, which in such directories respectively prevent users from following symbolic links that they do not own, prevent users making hard links to files that they do not own, prevents users opening FIFOs that they do not own, and prevents users from open existing files that they do not own when they expected to create them.



          This will surprise you with permissions errors when doing various further things as root when you do use sudo.



          More on these at question like "Hard link permissions behavior different between CentOS 6 and CentOS 7" , "Symbolic link not working as expected when changes user", and "Group permissions for root not working in /tmp".






          share|improve this answer










          New contributor




          Samuel P. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.
















          • 1





            May also be worth stressing the fundamental point that deleting a file depends on its directory's permissions, not on the file's permissions?

            – gidds
            2 hours ago














          7












          7








          7







          The /tmp directory is conventionally marked with the restricted deletion flag, which appears as a permission letter t or T in ls output.



          Restricted deletion implies several things. In the general case, it implies that only the owner of the file, or the owner of /tmp itself, can delete a file/directory in /tmp.



          You can not delete the file, because you are not the owner, which is root. Try running rm with sudo which you probably forgot.



          sudo rm /tmp/test


          More specifically to Linux alone, the restricted deletion flag (on a world-writable directory such as /tmp) also enables the protected_symlinks, protected_hardlinks, protected_regular, and protected_fifos restrictions, which in such directories respectively prevent users from following symbolic links that they do not own, prevent users making hard links to files that they do not own, prevents users opening FIFOs that they do not own, and prevents users from open existing files that they do not own when they expected to create them.



          This will surprise you with permissions errors when doing various further things as root when you do use sudo.



          More on these at question like "Hard link permissions behavior different between CentOS 6 and CentOS 7" , "Symbolic link not working as expected when changes user", and "Group permissions for root not working in /tmp".






          share|improve this answer










          New contributor




          Samuel P. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.










          The /tmp directory is conventionally marked with the restricted deletion flag, which appears as a permission letter t or T in ls output.



          Restricted deletion implies several things. In the general case, it implies that only the owner of the file, or the owner of /tmp itself, can delete a file/directory in /tmp.



          You can not delete the file, because you are not the owner, which is root. Try running rm with sudo which you probably forgot.



          sudo rm /tmp/test


          More specifically to Linux alone, the restricted deletion flag (on a world-writable directory such as /tmp) also enables the protected_symlinks, protected_hardlinks, protected_regular, and protected_fifos restrictions, which in such directories respectively prevent users from following symbolic links that they do not own, prevent users making hard links to files that they do not own, prevents users opening FIFOs that they do not own, and prevents users from open existing files that they do not own when they expected to create them.



          This will surprise you with permissions errors when doing various further things as root when you do use sudo.



          More on these at question like "Hard link permissions behavior different between CentOS 6 and CentOS 7" , "Symbolic link not working as expected when changes user", and "Group permissions for root not working in /tmp".







          share|improve this answer










          New contributor




          Samuel P. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.









          share|improve this answer



          share|improve this answer








          edited 6 hours ago









          JdeBP

          36.4k473173




          36.4k473173






          New contributor




          Samuel P. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.









          answered 7 hours ago









          Samuel P.Samuel P.

          1949




          1949




          New contributor




          Samuel P. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.





          New contributor





          Samuel P. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.






          Samuel P. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.








          • 1





            May also be worth stressing the fundamental point that deleting a file depends on its directory's permissions, not on the file's permissions?

            – gidds
            2 hours ago














          • 1





            May also be worth stressing the fundamental point that deleting a file depends on its directory's permissions, not on the file's permissions?

            – gidds
            2 hours ago








          1




          1





          May also be worth stressing the fundamental point that deleting a file depends on its directory's permissions, not on the file's permissions?

          – gidds
          2 hours ago





          May also be worth stressing the fundamental point that deleting a file depends on its directory's permissions, not on the file's permissions?

          – gidds
          2 hours ago













          3














          The problem seems to be the sticky bit of /tmp.




          $ ls -ld /tmp
          drwxrwxrwt⃝ 1 root root 1044 Mar 13 12:09 /tmp


          https://en.wikipedia.org/wiki/Sticky_bit




          When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root user can rename or delete the file. Without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of the file's owner. Typically this is set on the /tmp directory to prevent ordinary users from deleting or moving other users' files.







          share|improve this answer





















          • 1





            This is the point where one looks at the permissions of /tmp, observes that one already did have write access, and realizes that this is clearly not the right answer. (-:

            – JdeBP
            6 hours ago











          • Hi JdeBP! Thank you for the comment. I changed the answer now.

            – haba713
            6 hours ago






          • 3





            In any case, the permissions of the file itself are irrelevant when it comes to renaming it (as mv does) or unlinking it to a directory (as rm does). In both cases, it's the directory(ies) you modify, not the file.

            – Stéphane Chazelas
            6 hours ago











          • Stéphane Chazelas, thank you for the information! You have read your Stevens well. :-)

            – haba713
            6 hours ago
















          3














          The problem seems to be the sticky bit of /tmp.




          $ ls -ld /tmp
          drwxrwxrwt⃝ 1 root root 1044 Mar 13 12:09 /tmp


          https://en.wikipedia.org/wiki/Sticky_bit




          When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root user can rename or delete the file. Without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of the file's owner. Typically this is set on the /tmp directory to prevent ordinary users from deleting or moving other users' files.







          share|improve this answer





















          • 1





            This is the point where one looks at the permissions of /tmp, observes that one already did have write access, and realizes that this is clearly not the right answer. (-:

            – JdeBP
            6 hours ago











          • Hi JdeBP! Thank you for the comment. I changed the answer now.

            – haba713
            6 hours ago






          • 3





            In any case, the permissions of the file itself are irrelevant when it comes to renaming it (as mv does) or unlinking it to a directory (as rm does). In both cases, it's the directory(ies) you modify, not the file.

            – Stéphane Chazelas
            6 hours ago











          • Stéphane Chazelas, thank you for the information! You have read your Stevens well. :-)

            – haba713
            6 hours ago














          3












          3








          3







          The problem seems to be the sticky bit of /tmp.




          $ ls -ld /tmp
          drwxrwxrwt⃝ 1 root root 1044 Mar 13 12:09 /tmp


          https://en.wikipedia.org/wiki/Sticky_bit




          When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root user can rename or delete the file. Without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of the file's owner. Typically this is set on the /tmp directory to prevent ordinary users from deleting or moving other users' files.







          share|improve this answer















          The problem seems to be the sticky bit of /tmp.




          $ ls -ld /tmp
          drwxrwxrwt⃝ 1 root root 1044 Mar 13 12:09 /tmp


          https://en.wikipedia.org/wiki/Sticky_bit




          When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root user can rename or delete the file. Without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of the file's owner. Typically this is set on the /tmp directory to prevent ordinary users from deleting or moving other users' files.








          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 6 hours ago









          Stéphane Chazelas

          309k57584945




          309k57584945










          answered 7 hours ago









          haba713haba713

          1617




          1617








          • 1





            This is the point where one looks at the permissions of /tmp, observes that one already did have write access, and realizes that this is clearly not the right answer. (-:

            – JdeBP
            6 hours ago











          • Hi JdeBP! Thank you for the comment. I changed the answer now.

            – haba713
            6 hours ago






          • 3





            In any case, the permissions of the file itself are irrelevant when it comes to renaming it (as mv does) or unlinking it to a directory (as rm does). In both cases, it's the directory(ies) you modify, not the file.

            – Stéphane Chazelas
            6 hours ago











          • Stéphane Chazelas, thank you for the information! You have read your Stevens well. :-)

            – haba713
            6 hours ago














          • 1





            This is the point where one looks at the permissions of /tmp, observes that one already did have write access, and realizes that this is clearly not the right answer. (-:

            – JdeBP
            6 hours ago











          • Hi JdeBP! Thank you for the comment. I changed the answer now.

            – haba713
            6 hours ago






          • 3





            In any case, the permissions of the file itself are irrelevant when it comes to renaming it (as mv does) or unlinking it to a directory (as rm does). In both cases, it's the directory(ies) you modify, not the file.

            – Stéphane Chazelas
            6 hours ago











          • Stéphane Chazelas, thank you for the information! You have read your Stevens well. :-)

            – haba713
            6 hours ago








          1




          1





          This is the point where one looks at the permissions of /tmp, observes that one already did have write access, and realizes that this is clearly not the right answer. (-:

          – JdeBP
          6 hours ago





          This is the point where one looks at the permissions of /tmp, observes that one already did have write access, and realizes that this is clearly not the right answer. (-:

          – JdeBP
          6 hours ago













          Hi JdeBP! Thank you for the comment. I changed the answer now.

          – haba713
          6 hours ago





          Hi JdeBP! Thank you for the comment. I changed the answer now.

          – haba713
          6 hours ago




          3




          3





          In any case, the permissions of the file itself are irrelevant when it comes to renaming it (as mv does) or unlinking it to a directory (as rm does). In both cases, it's the directory(ies) you modify, not the file.

          – Stéphane Chazelas
          6 hours ago





          In any case, the permissions of the file itself are irrelevant when it comes to renaming it (as mv does) or unlinking it to a directory (as rm does). In both cases, it's the directory(ies) you modify, not the file.

          – Stéphane Chazelas
          6 hours ago













          Stéphane Chazelas, thank you for the information! You have read your Stevens well. :-)

          – haba713
          6 hours ago





          Stéphane Chazelas, thank you for the information! You have read your Stevens well. :-)

          – haba713
          6 hours ago


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Unix & Linux Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f506039%2fcant-remove-a-file-with-file-mode-bits-arw%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Callistus I

          Tabula Rosettana

          How to label and detect the document text images