Can't remove a file with file mode bits a+rw
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
add a comment |
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
add a comment |
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
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
linux permissions rm chmod chown
asked 7 hours ago
haba713haba713
1617
1617
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
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".
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
add a comment |
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.
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 (asmvdoes) or unlinking it to a directory (asrmdoes). 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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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".
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
add a comment |
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".
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
add a comment |
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".
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".
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.
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
add a comment |
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
add a comment |
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.
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 (asmvdoes) or unlinking it to a directory (asrmdoes). 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
add a comment |
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.
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 (asmvdoes) or unlinking it to a directory (asrmdoes). 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
add a comment |
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.
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.
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 (asmvdoes) or unlinking it to a directory (asrmdoes). 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
add a comment |
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 (asmvdoes) or unlinking it to a directory (asrmdoes). 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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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