Inadvertently nuked my disk permission structure - why?Directory permissionRevert permission of /usr back to...

In a script how can I signal who's winning the argument?

Sextortion with actual password not found in leaks

Articles with professions

What kind of world would drive brains to evolve high-throughput sensory?

Who controls a summoned steed’s familiar?

What is an Eternal Word™?

Why are there not any MRI machines available in Interstellar?

Idioms: Should it be " the internet is a seemingly infinite well of information" or "the internet is a seemingly infinite wealth of information"

What is "ass door"?

Tensor Product with Trivial Vector Space

Why is a dedicated QA team member necessary?

Short story where a flexible reality hardens to an unchanging one

Considerations when providing money to one child now, and the other later?

Company requiring me to let them review research from before I was hired

Inadvertently nuked my disk permission structure - why?

Character Frequency in a String

How to extract only values greater than a threshold

what to say when a company asks you why someone (a friend) who was fired left?

What is the meaning of "you has the wind of me"?

Why is DC so, so, so Democratic?

What's the 1 inch size square knob sticking out of wall?

What was the rationale behind 36 bit computer architectures?

Can 々 stand for a duplicated kanji with a different reading?

What does the Find Familiar spell target?



Inadvertently nuked my disk permission structure - why?


Directory permissionRevert permission of /usr back to rootHow to change read-only permission under 501 user?Restore permission default of /usr folderPartitioned drive PermissionWhy chown command can't take effect?Restrict permission “write to disk” of a particular userPermission denied during deletion of folder in UBUNTUsimplescreenrecorder: Permission deniedView group/permissions structure






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







3















I was trying to chown within /opt and for some reason chown jumped up to the parent and chowned everything.



Can anyone suggest why/how this might happened, and how to avoid doing it in future? It's a bit concerning that running a command in a given dir can effectively jump up and run it in root dir.



ubuntu: /opt > sudo chown -R root:www-data .*
chown: changing ownership of '../var/lib/lxcfs/proc/cpuinfo': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/meminfo': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/stat': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/uptime': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/diskstats': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/swaps': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/devices': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/blkio': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/hugetlb': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/rdma': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/pids': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/freezer': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/cpuset': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/memory': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/perf_event': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/cpu,cpuacct': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/net_cls,net_prio': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/name=systemd': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/unified': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs': No such file or directory
^C
:ubuntu: /opt >









share|improve this question

























  • I would have done it like this: sudo chown -R root:wwwdata /opt as per the --help dialog... perhaps using that pipe caused some issue???

    – Joshua Besneatte
    8 hours ago











  • I figure it's something to do with me specifying dotstar .*

    – Duke Dougal
    8 hours ago






  • 1





    .* matches .. (the parent directory, which is /) - see Does “chmod 777 .* -R” chmod parent directories (..)?

    – steeldriver
    8 hours ago











  • dotStar... too close to a deathStar to be safe :/

    – Joshua Besneatte
    8 hours ago






  • 1





    @steeldriver that sounds like it should be posted as an answer ;)

    – Joshua Besneatte
    8 hours ago


















3















I was trying to chown within /opt and for some reason chown jumped up to the parent and chowned everything.



Can anyone suggest why/how this might happened, and how to avoid doing it in future? It's a bit concerning that running a command in a given dir can effectively jump up and run it in root dir.



ubuntu: /opt > sudo chown -R root:www-data .*
chown: changing ownership of '../var/lib/lxcfs/proc/cpuinfo': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/meminfo': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/stat': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/uptime': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/diskstats': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/swaps': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/devices': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/blkio': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/hugetlb': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/rdma': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/pids': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/freezer': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/cpuset': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/memory': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/perf_event': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/cpu,cpuacct': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/net_cls,net_prio': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/name=systemd': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/unified': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs': No such file or directory
^C
:ubuntu: /opt >









share|improve this question

























  • I would have done it like this: sudo chown -R root:wwwdata /opt as per the --help dialog... perhaps using that pipe caused some issue???

    – Joshua Besneatte
    8 hours ago











  • I figure it's something to do with me specifying dotstar .*

    – Duke Dougal
    8 hours ago






  • 1





    .* matches .. (the parent directory, which is /) - see Does “chmod 777 .* -R” chmod parent directories (..)?

    – steeldriver
    8 hours ago











  • dotStar... too close to a deathStar to be safe :/

    – Joshua Besneatte
    8 hours ago






  • 1





    @steeldriver that sounds like it should be posted as an answer ;)

    – Joshua Besneatte
    8 hours ago














3












3








3








I was trying to chown within /opt and for some reason chown jumped up to the parent and chowned everything.



Can anyone suggest why/how this might happened, and how to avoid doing it in future? It's a bit concerning that running a command in a given dir can effectively jump up and run it in root dir.



ubuntu: /opt > sudo chown -R root:www-data .*
chown: changing ownership of '../var/lib/lxcfs/proc/cpuinfo': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/meminfo': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/stat': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/uptime': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/diskstats': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/swaps': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/devices': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/blkio': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/hugetlb': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/rdma': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/pids': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/freezer': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/cpuset': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/memory': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/perf_event': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/cpu,cpuacct': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/net_cls,net_prio': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/name=systemd': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/unified': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs': No such file or directory
^C
:ubuntu: /opt >









share|improve this question
















I was trying to chown within /opt and for some reason chown jumped up to the parent and chowned everything.



Can anyone suggest why/how this might happened, and how to avoid doing it in future? It's a bit concerning that running a command in a given dir can effectively jump up and run it in root dir.



ubuntu: /opt > sudo chown -R root:www-data .*
chown: changing ownership of '../var/lib/lxcfs/proc/cpuinfo': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/meminfo': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/stat': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/uptime': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/diskstats': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc/swaps': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/proc': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/devices': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/blkio': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/hugetlb': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/rdma': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/pids': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/freezer': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/cpuset': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/memory': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/perf_event': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/cpu,cpuacct': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/net_cls,net_prio': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/name=systemd': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup/unified': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs/cgroup': Operation not permitted
chown: changing ownership of '../var/lib/lxcfs': No such file or directory
^C
:ubuntu: /opt >






permissions chown






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 8 hours ago







Duke Dougal

















asked 8 hours ago









Duke DougalDuke Dougal

6031 gold badge5 silver badges12 bronze badges




6031 gold badge5 silver badges12 bronze badges













  • I would have done it like this: sudo chown -R root:wwwdata /opt as per the --help dialog... perhaps using that pipe caused some issue???

    – Joshua Besneatte
    8 hours ago











  • I figure it's something to do with me specifying dotstar .*

    – Duke Dougal
    8 hours ago






  • 1





    .* matches .. (the parent directory, which is /) - see Does “chmod 777 .* -R” chmod parent directories (..)?

    – steeldriver
    8 hours ago











  • dotStar... too close to a deathStar to be safe :/

    – Joshua Besneatte
    8 hours ago






  • 1





    @steeldriver that sounds like it should be posted as an answer ;)

    – Joshua Besneatte
    8 hours ago



















  • I would have done it like this: sudo chown -R root:wwwdata /opt as per the --help dialog... perhaps using that pipe caused some issue???

    – Joshua Besneatte
    8 hours ago











  • I figure it's something to do with me specifying dotstar .*

    – Duke Dougal
    8 hours ago






  • 1





    .* matches .. (the parent directory, which is /) - see Does “chmod 777 .* -R” chmod parent directories (..)?

    – steeldriver
    8 hours ago











  • dotStar... too close to a deathStar to be safe :/

    – Joshua Besneatte
    8 hours ago






  • 1





    @steeldriver that sounds like it should be posted as an answer ;)

    – Joshua Besneatte
    8 hours ago

















I would have done it like this: sudo chown -R root:wwwdata /opt as per the --help dialog... perhaps using that pipe caused some issue???

– Joshua Besneatte
8 hours ago





I would have done it like this: sudo chown -R root:wwwdata /opt as per the --help dialog... perhaps using that pipe caused some issue???

– Joshua Besneatte
8 hours ago













I figure it's something to do with me specifying dotstar .*

– Duke Dougal
8 hours ago





I figure it's something to do with me specifying dotstar .*

– Duke Dougal
8 hours ago




1




1





.* matches .. (the parent directory, which is /) - see Does “chmod 777 .* -R” chmod parent directories (..)?

– steeldriver
8 hours ago





.* matches .. (the parent directory, which is /) - see Does “chmod 777 .* -R” chmod parent directories (..)?

– steeldriver
8 hours ago













dotStar... too close to a deathStar to be safe :/

– Joshua Besneatte
8 hours ago





dotStar... too close to a deathStar to be safe :/

– Joshua Besneatte
8 hours ago




1




1





@steeldriver that sounds like it should be posted as an answer ;)

– Joshua Besneatte
8 hours ago





@steeldriver that sounds like it should be posted as an answer ;)

– Joshua Besneatte
8 hours ago










2 Answers
2






active

oldest

votes


















4














This happened because you used:



sudo chown -R root:www-data .*


when you should have used this instead:



sudo chown -R root:www-data ./*


First, ./* is recursive for all directories under the current directory.



Additionally, * is also recursive for all directories under the current directory.



Next, .* is recursive for all directories, one directory above the current directory.



Finally ../* is also recursive for all directories one directory above the current directory.



To avoid this in the future, you can use the ls command to verify the path before you execute the chown command like in these examples:



ls -a ./*
ls -a *
ls -a .*
ls -a ../*


Another way to avoid this is to always use the full path to the directory you wish to run a command to.



Here is an example:



sudo chown -R root:www-data /opt/*




Edit:



You can use the following command to chmod all hidden files directly under /opt This will not apply to directories.



for i in $(ls -a /opt | grep -P "^.[A-Z,a-z]"); do sudo chmod root:www-data $i; done


You can verify what files this will chmod by running the following command:



ls -a /opt | grep -P "^.[A-Z,a-z]"




The first part of the command: for i in $(ls -a /opt | grep -P "^.[A-Z,a-z]") says that, for all the results of the command ls -a /opt | grep -P "^.[A-Z,a-z]" assign each result to the variable "i".



Also, grep -P "^.[A-Z,a-z]" uses the -P option which I think stands for perl and this allows us to use regex to match the result.



The regex here says that the first matching character ^. must be . and that the next character [A-Z,a-z] must be any character that is A-Z or a-z.



This will exclude the results . and .. which represent the current directory and the directory above the current directory and will only include hidden.



The second part of the command: do sudo chmod root:www-data $i says to run the command for all variables that match "i".



The third part of the command: done says that I am finished.





Additionally, you used the -R option with chmod and the -R option is recursive and will apply to all directories.



Because chmod is such a dangerous command sometimes, the -R option is added to apply to directories and files.



When you only only use the chmod command with no options, the command will only apply to files and will not apply recursively to directories.






share|improve this answer


























  • My intent was to target hidden files. I mistakenly assumed that the syntax used for grepping hidden files as described here stackoverflow.com/questions/10375689/… is generally valid syntax for hidden files. Seems not.

    – Duke Dougal
    8 hours ago













  • @DukeDougal The problem with that answer you have is that it also matches . and .. which represent the current directory and the directory above your current directory as well as hidden files.

    – mchid
    8 hours ago











  • @DukeDougal I changed ls to ls -a to list all files including hidden files.

    – mchid
    7 hours ago



















2














The shell glob .* matches .. (the parent directory) in this case unfortunately that's /:



steeldriver@t400s:/opt$ ls .*
.:

..:
bin boot cdrom dev etc home initrd.img initrd.img.old lib lib32 lib64
libx32 lost+found media mnt opt proc root run sbin snap srv swapfile sys
tmp usr var vmlinuz vmlinuz.old


For additional discussion see:




  • Does “chmod 777 .* -R” chmod parent directories (..)?

  • how to glob every hidden file except current and parent directory






share|improve this answer


























    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
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1160828%2finadvertently-nuked-my-disk-permission-structure-why%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









    4














    This happened because you used:



    sudo chown -R root:www-data .*


    when you should have used this instead:



    sudo chown -R root:www-data ./*


    First, ./* is recursive for all directories under the current directory.



    Additionally, * is also recursive for all directories under the current directory.



    Next, .* is recursive for all directories, one directory above the current directory.



    Finally ../* is also recursive for all directories one directory above the current directory.



    To avoid this in the future, you can use the ls command to verify the path before you execute the chown command like in these examples:



    ls -a ./*
    ls -a *
    ls -a .*
    ls -a ../*


    Another way to avoid this is to always use the full path to the directory you wish to run a command to.



    Here is an example:



    sudo chown -R root:www-data /opt/*




    Edit:



    You can use the following command to chmod all hidden files directly under /opt This will not apply to directories.



    for i in $(ls -a /opt | grep -P "^.[A-Z,a-z]"); do sudo chmod root:www-data $i; done


    You can verify what files this will chmod by running the following command:



    ls -a /opt | grep -P "^.[A-Z,a-z]"




    The first part of the command: for i in $(ls -a /opt | grep -P "^.[A-Z,a-z]") says that, for all the results of the command ls -a /opt | grep -P "^.[A-Z,a-z]" assign each result to the variable "i".



    Also, grep -P "^.[A-Z,a-z]" uses the -P option which I think stands for perl and this allows us to use regex to match the result.



    The regex here says that the first matching character ^. must be . and that the next character [A-Z,a-z] must be any character that is A-Z or a-z.



    This will exclude the results . and .. which represent the current directory and the directory above the current directory and will only include hidden.



    The second part of the command: do sudo chmod root:www-data $i says to run the command for all variables that match "i".



    The third part of the command: done says that I am finished.





    Additionally, you used the -R option with chmod and the -R option is recursive and will apply to all directories.



    Because chmod is such a dangerous command sometimes, the -R option is added to apply to directories and files.



    When you only only use the chmod command with no options, the command will only apply to files and will not apply recursively to directories.






    share|improve this answer


























    • My intent was to target hidden files. I mistakenly assumed that the syntax used for grepping hidden files as described here stackoverflow.com/questions/10375689/… is generally valid syntax for hidden files. Seems not.

      – Duke Dougal
      8 hours ago













    • @DukeDougal The problem with that answer you have is that it also matches . and .. which represent the current directory and the directory above your current directory as well as hidden files.

      – mchid
      8 hours ago











    • @DukeDougal I changed ls to ls -a to list all files including hidden files.

      – mchid
      7 hours ago
















    4














    This happened because you used:



    sudo chown -R root:www-data .*


    when you should have used this instead:



    sudo chown -R root:www-data ./*


    First, ./* is recursive for all directories under the current directory.



    Additionally, * is also recursive for all directories under the current directory.



    Next, .* is recursive for all directories, one directory above the current directory.



    Finally ../* is also recursive for all directories one directory above the current directory.



    To avoid this in the future, you can use the ls command to verify the path before you execute the chown command like in these examples:



    ls -a ./*
    ls -a *
    ls -a .*
    ls -a ../*


    Another way to avoid this is to always use the full path to the directory you wish to run a command to.



    Here is an example:



    sudo chown -R root:www-data /opt/*




    Edit:



    You can use the following command to chmod all hidden files directly under /opt This will not apply to directories.



    for i in $(ls -a /opt | grep -P "^.[A-Z,a-z]"); do sudo chmod root:www-data $i; done


    You can verify what files this will chmod by running the following command:



    ls -a /opt | grep -P "^.[A-Z,a-z]"




    The first part of the command: for i in $(ls -a /opt | grep -P "^.[A-Z,a-z]") says that, for all the results of the command ls -a /opt | grep -P "^.[A-Z,a-z]" assign each result to the variable "i".



    Also, grep -P "^.[A-Z,a-z]" uses the -P option which I think stands for perl and this allows us to use regex to match the result.



    The regex here says that the first matching character ^. must be . and that the next character [A-Z,a-z] must be any character that is A-Z or a-z.



    This will exclude the results . and .. which represent the current directory and the directory above the current directory and will only include hidden.



    The second part of the command: do sudo chmod root:www-data $i says to run the command for all variables that match "i".



    The third part of the command: done says that I am finished.





    Additionally, you used the -R option with chmod and the -R option is recursive and will apply to all directories.



    Because chmod is such a dangerous command sometimes, the -R option is added to apply to directories and files.



    When you only only use the chmod command with no options, the command will only apply to files and will not apply recursively to directories.






    share|improve this answer


























    • My intent was to target hidden files. I mistakenly assumed that the syntax used for grepping hidden files as described here stackoverflow.com/questions/10375689/… is generally valid syntax for hidden files. Seems not.

      – Duke Dougal
      8 hours ago













    • @DukeDougal The problem with that answer you have is that it also matches . and .. which represent the current directory and the directory above your current directory as well as hidden files.

      – mchid
      8 hours ago











    • @DukeDougal I changed ls to ls -a to list all files including hidden files.

      – mchid
      7 hours ago














    4












    4








    4







    This happened because you used:



    sudo chown -R root:www-data .*


    when you should have used this instead:



    sudo chown -R root:www-data ./*


    First, ./* is recursive for all directories under the current directory.



    Additionally, * is also recursive for all directories under the current directory.



    Next, .* is recursive for all directories, one directory above the current directory.



    Finally ../* is also recursive for all directories one directory above the current directory.



    To avoid this in the future, you can use the ls command to verify the path before you execute the chown command like in these examples:



    ls -a ./*
    ls -a *
    ls -a .*
    ls -a ../*


    Another way to avoid this is to always use the full path to the directory you wish to run a command to.



    Here is an example:



    sudo chown -R root:www-data /opt/*




    Edit:



    You can use the following command to chmod all hidden files directly under /opt This will not apply to directories.



    for i in $(ls -a /opt | grep -P "^.[A-Z,a-z]"); do sudo chmod root:www-data $i; done


    You can verify what files this will chmod by running the following command:



    ls -a /opt | grep -P "^.[A-Z,a-z]"




    The first part of the command: for i in $(ls -a /opt | grep -P "^.[A-Z,a-z]") says that, for all the results of the command ls -a /opt | grep -P "^.[A-Z,a-z]" assign each result to the variable "i".



    Also, grep -P "^.[A-Z,a-z]" uses the -P option which I think stands for perl and this allows us to use regex to match the result.



    The regex here says that the first matching character ^. must be . and that the next character [A-Z,a-z] must be any character that is A-Z or a-z.



    This will exclude the results . and .. which represent the current directory and the directory above the current directory and will only include hidden.



    The second part of the command: do sudo chmod root:www-data $i says to run the command for all variables that match "i".



    The third part of the command: done says that I am finished.





    Additionally, you used the -R option with chmod and the -R option is recursive and will apply to all directories.



    Because chmod is such a dangerous command sometimes, the -R option is added to apply to directories and files.



    When you only only use the chmod command with no options, the command will only apply to files and will not apply recursively to directories.






    share|improve this answer















    This happened because you used:



    sudo chown -R root:www-data .*


    when you should have used this instead:



    sudo chown -R root:www-data ./*


    First, ./* is recursive for all directories under the current directory.



    Additionally, * is also recursive for all directories under the current directory.



    Next, .* is recursive for all directories, one directory above the current directory.



    Finally ../* is also recursive for all directories one directory above the current directory.



    To avoid this in the future, you can use the ls command to verify the path before you execute the chown command like in these examples:



    ls -a ./*
    ls -a *
    ls -a .*
    ls -a ../*


    Another way to avoid this is to always use the full path to the directory you wish to run a command to.



    Here is an example:



    sudo chown -R root:www-data /opt/*




    Edit:



    You can use the following command to chmod all hidden files directly under /opt This will not apply to directories.



    for i in $(ls -a /opt | grep -P "^.[A-Z,a-z]"); do sudo chmod root:www-data $i; done


    You can verify what files this will chmod by running the following command:



    ls -a /opt | grep -P "^.[A-Z,a-z]"




    The first part of the command: for i in $(ls -a /opt | grep -P "^.[A-Z,a-z]") says that, for all the results of the command ls -a /opt | grep -P "^.[A-Z,a-z]" assign each result to the variable "i".



    Also, grep -P "^.[A-Z,a-z]" uses the -P option which I think stands for perl and this allows us to use regex to match the result.



    The regex here says that the first matching character ^. must be . and that the next character [A-Z,a-z] must be any character that is A-Z or a-z.



    This will exclude the results . and .. which represent the current directory and the directory above the current directory and will only include hidden.



    The second part of the command: do sudo chmod root:www-data $i says to run the command for all variables that match "i".



    The third part of the command: done says that I am finished.





    Additionally, you used the -R option with chmod and the -R option is recursive and will apply to all directories.



    Because chmod is such a dangerous command sometimes, the -R option is added to apply to directories and files.



    When you only only use the chmod command with no options, the command will only apply to files and will not apply recursively to directories.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 7 hours ago

























    answered 8 hours ago









    mchidmchid

    24.6k2 gold badges56 silver badges93 bronze badges




    24.6k2 gold badges56 silver badges93 bronze badges













    • My intent was to target hidden files. I mistakenly assumed that the syntax used for grepping hidden files as described here stackoverflow.com/questions/10375689/… is generally valid syntax for hidden files. Seems not.

      – Duke Dougal
      8 hours ago













    • @DukeDougal The problem with that answer you have is that it also matches . and .. which represent the current directory and the directory above your current directory as well as hidden files.

      – mchid
      8 hours ago











    • @DukeDougal I changed ls to ls -a to list all files including hidden files.

      – mchid
      7 hours ago



















    • My intent was to target hidden files. I mistakenly assumed that the syntax used for grepping hidden files as described here stackoverflow.com/questions/10375689/… is generally valid syntax for hidden files. Seems not.

      – Duke Dougal
      8 hours ago













    • @DukeDougal The problem with that answer you have is that it also matches . and .. which represent the current directory and the directory above your current directory as well as hidden files.

      – mchid
      8 hours ago











    • @DukeDougal I changed ls to ls -a to list all files including hidden files.

      – mchid
      7 hours ago

















    My intent was to target hidden files. I mistakenly assumed that the syntax used for grepping hidden files as described here stackoverflow.com/questions/10375689/… is generally valid syntax for hidden files. Seems not.

    – Duke Dougal
    8 hours ago







    My intent was to target hidden files. I mistakenly assumed that the syntax used for grepping hidden files as described here stackoverflow.com/questions/10375689/… is generally valid syntax for hidden files. Seems not.

    – Duke Dougal
    8 hours ago















    @DukeDougal The problem with that answer you have is that it also matches . and .. which represent the current directory and the directory above your current directory as well as hidden files.

    – mchid
    8 hours ago





    @DukeDougal The problem with that answer you have is that it also matches . and .. which represent the current directory and the directory above your current directory as well as hidden files.

    – mchid
    8 hours ago













    @DukeDougal I changed ls to ls -a to list all files including hidden files.

    – mchid
    7 hours ago





    @DukeDougal I changed ls to ls -a to list all files including hidden files.

    – mchid
    7 hours ago













    2














    The shell glob .* matches .. (the parent directory) in this case unfortunately that's /:



    steeldriver@t400s:/opt$ ls .*
    .:

    ..:
    bin boot cdrom dev etc home initrd.img initrd.img.old lib lib32 lib64
    libx32 lost+found media mnt opt proc root run sbin snap srv swapfile sys
    tmp usr var vmlinuz vmlinuz.old


    For additional discussion see:




    • Does “chmod 777 .* -R” chmod parent directories (..)?

    • how to glob every hidden file except current and parent directory






    share|improve this answer




























      2














      The shell glob .* matches .. (the parent directory) in this case unfortunately that's /:



      steeldriver@t400s:/opt$ ls .*
      .:

      ..:
      bin boot cdrom dev etc home initrd.img initrd.img.old lib lib32 lib64
      libx32 lost+found media mnt opt proc root run sbin snap srv swapfile sys
      tmp usr var vmlinuz vmlinuz.old


      For additional discussion see:




      • Does “chmod 777 .* -R” chmod parent directories (..)?

      • how to glob every hidden file except current and parent directory






      share|improve this answer


























        2












        2








        2







        The shell glob .* matches .. (the parent directory) in this case unfortunately that's /:



        steeldriver@t400s:/opt$ ls .*
        .:

        ..:
        bin boot cdrom dev etc home initrd.img initrd.img.old lib lib32 lib64
        libx32 lost+found media mnt opt proc root run sbin snap srv swapfile sys
        tmp usr var vmlinuz vmlinuz.old


        For additional discussion see:




        • Does “chmod 777 .* -R” chmod parent directories (..)?

        • how to glob every hidden file except current and parent directory






        share|improve this answer













        The shell glob .* matches .. (the parent directory) in this case unfortunately that's /:



        steeldriver@t400s:/opt$ ls .*
        .:

        ..:
        bin boot cdrom dev etc home initrd.img initrd.img.old lib lib32 lib64
        libx32 lost+found media mnt opt proc root run sbin snap srv swapfile sys
        tmp usr var vmlinuz vmlinuz.old


        For additional discussion see:




        • Does “chmod 777 .* -R” chmod parent directories (..)?

        • how to glob every hidden file except current and parent directory







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 8 hours ago









        steeldriversteeldriver

        76k11 gold badges125 silver badges203 bronze badges




        76k11 gold badges125 silver badges203 bronze badges






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1160828%2finadvertently-nuked-my-disk-permission-structure-why%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

            Taj Mahal Inhaltsverzeichnis Aufbau | Geschichte | 350-Jahr-Feier | Heutige Bedeutung | Siehe auch |...

            Baia Sprie Cuprins Etimologie | Istorie | Demografie | Politică și administrație | Arii naturale...

            Nicolae Petrescu-Găină Cuprins Biografie | Opera | In memoriam | Varia | Controverse, incertitudini...