Why did an rm command executed from a pwd NOT / remove directories from it? Unicorn Meta Zoo...
What to do with someone that cheated their way through university and a PhD program?
Can you stand up from being prone using Skirmisher outside of your turn?
What ability score does a Hexblade's Pact Weapon use for attack and damage when wielded by another character?
Seek and ye shall find
Multiple fireplaces in an apartment building?
"Rubric" as meaning "signature" or "personal mark" -- is this accepted usage?
Is Electric Central Heating worth it if using Solar Panels?
How to avoid introduction cliches
Is a 5 watt UHF/VHF handheld considered QRP?
Are there moral objections to a life motivated purely by money? How to sway a person from this lifestyle?
Married in secret, can marital status in passport be changed at a later date?
Is Diceware more secure than a long passphrase?
What's parked in Mil Moscow helicopter plant?
Is Bran literally the world's memory?
Does Feeblemind produce an ongoing magical effect that can be dispelled?
Israeli soda type drink
What is this word supposed to be?
Could Neutrino technically as side-effect, incentivize centralization of the bitcoin network?
Mistake in years of experience in resume?
Are all CP/M-80 implementations binary compatible?
Additive group of local rings
I preordered a game on my Xbox while on the home screen of my friend's account. Which of us owns the game?
What is the best way to deal with NPC-NPC combat?
What’s with the clanks in Endgame?
Why did an rm command executed from a pwd NOT / remove directories from it?
Unicorn Meta Zoo #1: Why another podcast?
Announcing the arrival of Valued Associate #679: Cesar ManaraRun sudo command within directoryHow do I remove PWD from terminal?Why did Ubuntu try to self-destruct?List all non system usersWhy does redirecting sed output to same input file make my machine unresponsive?What is the command to remove all files but not directories?alias “nautilus $(pwd)” does not open in pwd directoryRemove subdirectories with same name from different directories at same levelFind directory and replace with symlinkPATH=$PATH:`pwd` - What happens when this command is executed?Search folder, find and copy files to new folder corresponding file ending
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
OK, so I've been doing different levels of sysadmin for almost a decade and yet I fell victim to an age old mistake; though I do not understand why it happened.
I was in my server sorting through almost 15 years worth of .tar.gz files uncompressing them and then sorting through the data.
I even always used a new folder as a sandbox.
I was in a folder (/DATA/RAID1/ROOT/SORTME/BACKOPEN) containing an uncompressed archive of a previous Ubuntu installation when I decided to remove the more obvious system folders I knew I wouldn't need.
When I ran my rm it ran to completion but when it was done I had no /bin, /sbin, or any of the other root associated folders named like the ones I tried to remove.
THE OFFENDING COMMAND:
root@dev1:/DATA/RAID1/ROOT/SORTME/BACKOPEN# rm -rfv cdrom/ boot/ bin/ calpp/ dev/ etc/ ldconfig icd-registration.tgz lib/ lib32/ lib64/ opt/ sbin/ selinux/ share/ srv/ usr/ var/
Now, I certainly realize in retrospect that I SHOULD have had ./ before those directories to account for relative path but I am still confused as to why /bin or /sbin would get removed when i specifically designated bin/ sbin/ and was NOT in / at the time.
It seems to me like if I was operating in my pwd and didn't have a preceding forward slash to specify root it should have only deleted the dirs in the directory i was in.
Thank god I didn't have a lone / or any of the names of my ZFS pools in the rm and so I'm fine but I would very much prefer to never make this mistake again.
The idea of botching an OS like this is embarrassing and I can't help but think something other than ./ would be the answer.
What am I failing to notice here?
Thank you in advance for your efforts.
UPDATE:
OK, so I got home and reinstalled 14.04 from the exact same ISO ive been using since release. I re imported my ZFS pools (/DATA/RAID1|/DATA/RAID2) and checked /DATA/RAID1/ROOT/SORTME/BACKOPEN only to find ALL of the dirs/files I specified in the offending command still existed. Not wanting to screw myself all over i copy and pasted the offending command in my post BUT in prepended ./ to each path/file argument. IT WORKED and DID NOT botch my OS. I also redirected the output of the rm -rfv to a file for later examination. No part of my OS got removed, all was well. I am guessing that if hard or symbolic links were the issue I would have had the same issue but did not this time. The plot thickens. I'm getting the feeling I may never get an answer but it seems like maybe this is just one of those things that happened as a freak accident. I can certainly say I will be much more careful in the future...
command-line bash delete rm
asked Mar 21 '18 at 3:53
user809476user809476
312
|
show 2 more comments
OK, so I've been doing different levels of sysadmin for almost a decade and yet I fell victim to an age old mistake; though I do not understand why it happened.
I was in my server sorting through almost 15 years worth of .tar.gz files uncompressing them and then sorting through the data.
I even always used a new folder as a sandbox.
I was in a folder (/DATA/RAID1/ROOT/SORTME/BACKOPEN) containing an uncompressed archive of a previous Ubuntu installation when I decided to remove the more obvious system folders I knew I wouldn't need.
When I ran my rm it ran to completion but when it was done I had no /bin, /sbin, or any of the other root associated folders named like the ones I tried to remove.
THE OFFENDING COMMAND:
root@dev1:/DATA/RAID1/ROOT/SORTME/BACKOPEN# rm -rfv cdrom/ boot/ bin/ calpp/ dev/ etc/ ldconfig icd-registration.tgz lib/ lib32/ lib64/ opt/ sbin/ selinux/ share/ srv/ usr/ var/
Now, I certainly realize in retrospect that I SHOULD have had ./ before those directories to account for relative path but I am still confused as to why /bin or /sbin would get removed when i specifically designated bin/ sbin/ and was NOT in / at the time.
It seems to me like if I was operating in my pwd and didn't have a preceding forward slash to specify root it should have only deleted the dirs in the directory i was in.
Thank god I didn't have a lone / or any of the names of my ZFS pools in the rm and so I'm fine but I would very much prefer to never make this mistake again.
The idea of botching an OS like this is embarrassing and I can't help but think something other than ./ would be the answer.
What am I failing to notice here?
Thank you in advance for your efforts.
UPDATE:
OK, so I got home and reinstalled 14.04 from the exact same ISO ive been using since release. I re imported my ZFS pools (/DATA/RAID1|/DATA/RAID2) and checked /DATA/RAID1/ROOT/SORTME/BACKOPEN only to find ALL of the dirs/files I specified in the offending command still existed. Not wanting to screw myself all over i copy and pasted the offending command in my post BUT in prepended ./ to each path/file argument. IT WORKED and DID NOT botch my OS. I also redirected the output of the rm -rfv to a file for later examination. No part of my OS got removed, all was well. I am guessing that if hard or symbolic links were the issue I would have had the same issue but did not this time. The plot thickens. I'm getting the feeling I may never get an answer but it seems like maybe this is just one of those things that happened as a freak accident. I can certainly say I will be much more careful in the future...
command-line bash delete rm
asked Mar 21 '18 at 3:53
user809476user809476
312
3
My first guess was thatrm -rremoves symlink targets, but after some research it looks like it doesn't.
– wjandrea
Mar 21 '18 at 4:18
Yea, Iv'e been asking other much more experienced men than myself in the field and all I'm getting are question marks above heads and jokes at my expense... :)
– user809476
Mar 21 '18 at 4:48
2
Since you used-v, the output would include the files deleted. Examine those.
– muru
Mar 21 '18 at 6:06
2
Sorry, my explanation was wrong. When you remove a hardlink to /bin, the link counter of its inode its decreased by one, /bin itself is not removed.
– muclux
Mar 21 '18 at 15:13
1
@user809476 I don't expect to see /bin in the output either. What you should look for is unexpected paths that may indicate it is following through to the root directory (via a bind mount or something) for example a srv directory showing up deeper in the directory hierarchy
– muru
Mar 22 '18 at 3:49
|
show 2 more comments
OK, so I've been doing different levels of sysadmin for almost a decade and yet I fell victim to an age old mistake; though I do not understand why it happened.
I was in my server sorting through almost 15 years worth of .tar.gz files uncompressing them and then sorting through the data.
I even always used a new folder as a sandbox.
I was in a folder (/DATA/RAID1/ROOT/SORTME/BACKOPEN) containing an uncompressed archive of a previous Ubuntu installation when I decided to remove the more obvious system folders I knew I wouldn't need.
When I ran my rm it ran to completion but when it was done I had no /bin, /sbin, or any of the other root associated folders named like the ones I tried to remove.
THE OFFENDING COMMAND:
root@dev1:/DATA/RAID1/ROOT/SORTME/BACKOPEN# rm -rfv cdrom/ boot/ bin/ calpp/ dev/ etc/ ldconfig icd-registration.tgz lib/ lib32/ lib64/ opt/ sbin/ selinux/ share/ srv/ usr/ var/
Now, I certainly realize in retrospect that I SHOULD have had ./ before those directories to account for relative path but I am still confused as to why /bin or /sbin would get removed when i specifically designated bin/ sbin/ and was NOT in / at the time.
It seems to me like if I was operating in my pwd and didn't have a preceding forward slash to specify root it should have only deleted the dirs in the directory i was in.
Thank god I didn't have a lone / or any of the names of my ZFS pools in the rm and so I'm fine but I would very much prefer to never make this mistake again.
The idea of botching an OS like this is embarrassing and I can't help but think something other than ./ would be the answer.
What am I failing to notice here?
Thank you in advance for your efforts.
UPDATE:
OK, so I got home and reinstalled 14.04 from the exact same ISO ive been using since release. I re imported my ZFS pools (/DATA/RAID1|/DATA/RAID2) and checked /DATA/RAID1/ROOT/SORTME/BACKOPEN only to find ALL of the dirs/files I specified in the offending command still existed. Not wanting to screw myself all over i copy and pasted the offending command in my post BUT in prepended ./ to each path/file argument. IT WORKED and DID NOT botch my OS. I also redirected the output of the rm -rfv to a file for later examination. No part of my OS got removed, all was well. I am guessing that if hard or symbolic links were the issue I would have had the same issue but did not this time. The plot thickens. I'm getting the feeling I may never get an answer but it seems like maybe this is just one of those things that happened as a freak accident. I can certainly say I will be much more careful in the future...
command-line bash delete rm
asked Mar 21 '18 at 3:53
user809476user809476
312
OK, so I've been doing different levels of sysadmin for almost a decade and yet I fell victim to an age old mistake; though I do not understand why it happened.
I was in my server sorting through almost 15 years worth of .tar.gz files uncompressing them and then sorting through the data.
I even always used a new folder as a sandbox.
I was in a folder (/DATA/RAID1/ROOT/SORTME/BACKOPEN) containing an uncompressed archive of a previous Ubuntu installation when I decided to remove the more obvious system folders I knew I wouldn't need.
When I ran my rm it ran to completion but when it was done I had no /bin, /sbin, or any of the other root associated folders named like the ones I tried to remove.
THE OFFENDING COMMAND:
root@dev1:/DATA/RAID1/ROOT/SORTME/BACKOPEN# rm -rfv cdrom/ boot/ bin/ calpp/ dev/ etc/ ldconfig icd-registration.tgz lib/ lib32/ lib64/ opt/ sbin/ selinux/ share/ srv/ usr/ var/
Now, I certainly realize in retrospect that I SHOULD have had ./ before those directories to account for relative path but I am still confused as to why /bin or /sbin would get removed when i specifically designated bin/ sbin/ and was NOT in / at the time.
It seems to me like if I was operating in my pwd and didn't have a preceding forward slash to specify root it should have only deleted the dirs in the directory i was in.
Thank god I didn't have a lone / or any of the names of my ZFS pools in the rm and so I'm fine but I would very much prefer to never make this mistake again.
The idea of botching an OS like this is embarrassing and I can't help but think something other than ./ would be the answer.
What am I failing to notice here?
Thank you in advance for your efforts.
UPDATE:
OK, so I got home and reinstalled 14.04 from the exact same ISO ive been using since release. I re imported my ZFS pools (/DATA/RAID1|/DATA/RAID2) and checked /DATA/RAID1/ROOT/SORTME/BACKOPEN only to find ALL of the dirs/files I specified in the offending command still existed. Not wanting to screw myself all over i copy and pasted the offending command in my post BUT in prepended ./ to each path/file argument. IT WORKED and DID NOT botch my OS. I also redirected the output of the rm -rfv to a file for later examination. No part of my OS got removed, all was well. I am guessing that if hard or symbolic links were the issue I would have had the same issue but did not this time. The plot thickens. I'm getting the feeling I may never get an answer but it seems like maybe this is just one of those things that happened as a freak accident. I can certainly say I will be much more careful in the future...
command-line bash delete rm
command-line bash delete rm
asked Mar 21 '18 at 3:53
user809476user809476
312
asked Mar 21 '18 at 3:53
user809476user809476
312
edited Mar 25 '18 at 3:12
user809476
asked Mar 21 '18 at 3:53
user809476user809476
312
asked Mar 21 '18 at 3:53
user809476user809476
312
asked Mar 21 '18 at 3:53
user809476user809476
312
312
3
My first guess was thatrm -rremoves symlink targets, but after some research it looks like it doesn't.
– wjandrea
Mar 21 '18 at 4:18
Yea, Iv'e been asking other much more experienced men than myself in the field and all I'm getting are question marks above heads and jokes at my expense... :)
– user809476
Mar 21 '18 at 4:48
2
Since you used-v, the output would include the files deleted. Examine those.
– muru
Mar 21 '18 at 6:06
2
Sorry, my explanation was wrong. When you remove a hardlink to /bin, the link counter of its inode its decreased by one, /bin itself is not removed.
– muclux
Mar 21 '18 at 15:13
1
@user809476 I don't expect to see /bin in the output either. What you should look for is unexpected paths that may indicate it is following through to the root directory (via a bind mount or something) for example a srv directory showing up deeper in the directory hierarchy
– muru
Mar 22 '18 at 3:49
|
show 2 more comments
3
My first guess was thatrm -rremoves symlink targets, but after some research it looks like it doesn't.
– wjandrea
Mar 21 '18 at 4:18
Yea, Iv'e been asking other much more experienced men than myself in the field and all I'm getting are question marks above heads and jokes at my expense... :)
– user809476
Mar 21 '18 at 4:48
2
Since you used-v, the output would include the files deleted. Examine those.
– muru
Mar 21 '18 at 6:06
2
Sorry, my explanation was wrong. When you remove a hardlink to /bin, the link counter of its inode its decreased by one, /bin itself is not removed.
– muclux
Mar 21 '18 at 15:13
1
@user809476 I don't expect to see /bin in the output either. What you should look for is unexpected paths that may indicate it is following through to the root directory (via a bind mount or something) for example a srv directory showing up deeper in the directory hierarchy
– muru
Mar 22 '18 at 3:49
3
3
My first guess was that
rm -r removes symlink targets, but after some research it looks like it doesn't.– wjandrea
Mar 21 '18 at 4:18
My first guess was that
rm -r removes symlink targets, but after some research it looks like it doesn't.– wjandrea
Mar 21 '18 at 4:18
Yea, Iv'e been asking other much more experienced men than myself in the field and all I'm getting are question marks above heads and jokes at my expense... :)
– user809476
Mar 21 '18 at 4:48
Yea, Iv'e been asking other much more experienced men than myself in the field and all I'm getting are question marks above heads and jokes at my expense... :)
– user809476
Mar 21 '18 at 4:48
2
2
Since you used
-v, the output would include the files deleted. Examine those.– muru
Mar 21 '18 at 6:06
Since you used
-v, the output would include the files deleted. Examine those.– muru
Mar 21 '18 at 6:06
2
2
Sorry, my explanation was wrong. When you remove a hardlink to /bin, the link counter of its inode its decreased by one, /bin itself is not removed.
– muclux
Mar 21 '18 at 15:13
Sorry, my explanation was wrong. When you remove a hardlink to /bin, the link counter of its inode its decreased by one, /bin itself is not removed.
– muclux
Mar 21 '18 at 15:13
1
1
@user809476 I don't expect to see /bin in the output either. What you should look for is unexpected paths that may indicate it is following through to the root directory (via a bind mount or something) for example a srv directory showing up deeper in the directory hierarchy
– muru
Mar 22 '18 at 3:49
@user809476 I don't expect to see /bin in the output either. What you should look for is unexpected paths that may indicate it is following through to the root directory (via a bind mount or something) for example a srv directory showing up deeper in the directory hierarchy
– muru
Mar 22 '18 at 3:49
|
show 2 more comments
1 Answer
1
active
oldest
votes
This is by design.
while rm doesn't remove directories by default, when you specify the -r switch it does. Here's an excerpt from the man page.
-r, -R, --recursive
remove directories and their contents recursively
Neither the -f force nor the -v verbose switch changes this behavior.
Since --preserve-root is the default you shouldn't need to worry about a lone /
It would appear that you weren't in the pwd you thought you were. Based on the results you must have been in /. Note that if you launch something with sudo your environment changes and the pwd along with it by default to /root. You can avoid this by specifying it on the command line like sudo -i PWD=/target/dir command as described in the accepted answer here.
Sources:
man rm on Ubuntu 16.04.6 LTS
https://linux.die.net/man/1/rm
Run sudo command within directory
answered 12 hours ago
Elder GeekElder Geek
27.6k1055131
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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%2faskubuntu.com%2fquestions%2f1017808%2fwhy-did-an-rm-command-executed-from-a-pwd-not-remove-directories-from-it%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is by design.
while rm doesn't remove directories by default, when you specify the -r switch it does. Here's an excerpt from the man page.
-r, -R, --recursive
remove directories and their contents recursively
Neither the -f force nor the -v verbose switch changes this behavior.
Since --preserve-root is the default you shouldn't need to worry about a lone /
It would appear that you weren't in the pwd you thought you were. Based on the results you must have been in /. Note that if you launch something with sudo your environment changes and the pwd along with it by default to /root. You can avoid this by specifying it on the command line like sudo -i PWD=/target/dir command as described in the accepted answer here.
Sources:
man rm on Ubuntu 16.04.6 LTS
https://linux.die.net/man/1/rm
Run sudo command within directory
answered 12 hours ago
Elder GeekElder Geek
27.6k1055131
add a comment |
This is by design.
while rm doesn't remove directories by default, when you specify the -r switch it does. Here's an excerpt from the man page.
-r, -R, --recursive
remove directories and their contents recursively
Neither the -f force nor the -v verbose switch changes this behavior.
Since --preserve-root is the default you shouldn't need to worry about a lone /
It would appear that you weren't in the pwd you thought you were. Based on the results you must have been in /. Note that if you launch something with sudo your environment changes and the pwd along with it by default to /root. You can avoid this by specifying it on the command line like sudo -i PWD=/target/dir command as described in the accepted answer here.
Sources:
man rm on Ubuntu 16.04.6 LTS
https://linux.die.net/man/1/rm
Run sudo command within directory
answered 12 hours ago
Elder GeekElder Geek
27.6k1055131
add a comment |
This is by design.
while rm doesn't remove directories by default, when you specify the -r switch it does. Here's an excerpt from the man page.
-r, -R, --recursive
remove directories and their contents recursively
Neither the -f force nor the -v verbose switch changes this behavior.
Since --preserve-root is the default you shouldn't need to worry about a lone /
It would appear that you weren't in the pwd you thought you were. Based on the results you must have been in /. Note that if you launch something with sudo your environment changes and the pwd along with it by default to /root. You can avoid this by specifying it on the command line like sudo -i PWD=/target/dir command as described in the accepted answer here.
Sources:
man rm on Ubuntu 16.04.6 LTS
https://linux.die.net/man/1/rm
Run sudo command within directory
answered 12 hours ago
Elder GeekElder Geek
27.6k1055131
This is by design.
while rm doesn't remove directories by default, when you specify the -r switch it does. Here's an excerpt from the man page.
-r, -R, --recursive
remove directories and their contents recursively
Neither the -f force nor the -v verbose switch changes this behavior.
Since --preserve-root is the default you shouldn't need to worry about a lone /
It would appear that you weren't in the pwd you thought you were. Based on the results you must have been in /. Note that if you launch something with sudo your environment changes and the pwd along with it by default to /root. You can avoid this by specifying it on the command line like sudo -i PWD=/target/dir command as described in the accepted answer here.
Sources:
man rm on Ubuntu 16.04.6 LTS
https://linux.die.net/man/1/rm
Run sudo command within directory
answered 12 hours ago
Elder GeekElder Geek
27.6k1055131
edited 12 hours ago
answered 12 hours ago
Elder GeekElder Geek
27.6k1055131
answered 12 hours ago
Elder GeekElder Geek
27.6k1055131
answered 12 hours ago
Elder GeekElder Geek
27.6k1055131
27.6k1055131
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- 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%2faskubuntu.com%2fquestions%2f1017808%2fwhy-did-an-rm-command-executed-from-a-pwd-not-remove-directories-from-it%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
3
My first guess was that
rm -rremoves symlink targets, but after some research it looks like it doesn't.– wjandrea
Mar 21 '18 at 4:18
Yea, Iv'e been asking other much more experienced men than myself in the field and all I'm getting are question marks above heads and jokes at my expense... :)
– user809476
Mar 21 '18 at 4:48
2
Since you used
-v, the output would include the files deleted. Examine those.– muru
Mar 21 '18 at 6:06
2
Sorry, my explanation was wrong. When you remove a hardlink to /bin, the link counter of its inode its decreased by one, /bin itself is not removed.
– muclux
Mar 21 '18 at 15:13
1
@user809476 I don't expect to see /bin in the output either. What you should look for is unexpected paths that may indicate it is following through to the root directory (via a bind mount or something) for example a srv directory showing up deeper in the directory hierarchy
– muru
Mar 22 '18 at 3:49