How do I find out which process is preventing a umount?












24















When I do



sudo umount /media/KINGSTON


I got



umount: /media/KINGSTON: device is busy.


I close all the windows and make sure all shell are pointing to other directories. How can I find which process is preventing the umount?










share|improve this question




















  • 3





    I think you've got a typo here, I doubt that command returned "How do I find out which process is eating up my bandwidth?"... ;) any chance you could edit the question please?

    – 8128
    Nov 6 '10 at 7:52
















24















When I do



sudo umount /media/KINGSTON


I got



umount: /media/KINGSTON: device is busy.


I close all the windows and make sure all shell are pointing to other directories. How can I find which process is preventing the umount?










share|improve this question




















  • 3





    I think you've got a typo here, I doubt that command returned "How do I find out which process is eating up my bandwidth?"... ;) any chance you could edit the question please?

    – 8128
    Nov 6 '10 at 7:52














24












24








24


9






When I do



sudo umount /media/KINGSTON


I got



umount: /media/KINGSTON: device is busy.


I close all the windows and make sure all shell are pointing to other directories. How can I find which process is preventing the umount?










share|improve this question
















When I do



sudo umount /media/KINGSTON


I got



umount: /media/KINGSTON: device is busy.


I close all the windows and make sure all shell are pointing to other directories. How can I find which process is preventing the umount?







umount






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 6 '10 at 19:05







Guillaume Coté

















asked Nov 6 '10 at 7:25









Guillaume CotéGuillaume Coté

1,80662336




1,80662336








  • 3





    I think you've got a typo here, I doubt that command returned "How do I find out which process is eating up my bandwidth?"... ;) any chance you could edit the question please?

    – 8128
    Nov 6 '10 at 7:52














  • 3





    I think you've got a typo here, I doubt that command returned "How do I find out which process is eating up my bandwidth?"... ;) any chance you could edit the question please?

    – 8128
    Nov 6 '10 at 7:52








3




3





I think you've got a typo here, I doubt that command returned "How do I find out which process is eating up my bandwidth?"... ;) any chance you could edit the question please?

– 8128
Nov 6 '10 at 7:52





I think you've got a typo here, I doubt that command returned "How do I find out which process is eating up my bandwidth?"... ;) any chance you could edit the question please?

– 8128
Nov 6 '10 at 7:52










4 Answers
4






active

oldest

votes


















23














open a terminal:



fuser -c /media/KINGSTON


It will output something like this:



/media/KINGSTON/: 3106c 11086


This will give you the pid of the processes using this volume. The extra character at the end of pid will give some extra info. ( c in 3106c)



c - the process is using the file as its current working directory

m - the file is mapped with mmap

o - the process is using it as an open file

r - the file is the root directory of the process

t - the process is accessing the file as a text file

y - this file is the controlling terminal for the process



So to unmount just kill that pids and re-try the unmount



sudo kill -9 3106 11086
sudo umount /media/KINGSTON


Note: To find the exact application name of these pids you may use this command



cat /proc/<pid>/cmdline


For example : cat /proc/11086/cmdline



this will output something like below.



    evince^@/media/KINGSTON/Ubuntu-guide.pdf^@


Hope this will help






share|improve this answer





















  • 2





    fuser -ck would also kill it.

    – João Pinto
    Nov 6 '10 at 8:05






  • 3





    I would suggest killing them without the -9 option first, to give those applications the chance to cleanly shut down. And I would suggest using ps <pid> instead of editing files in /proc to see the command name and arguments.

    – Marius Gedminas
    Nov 6 '10 at 14:55











  • I follow your procedure to find the process, it is Thunar--deamon. There are no extra character giving extra info. I have not kill it yet, I am worring about the impact it could have on other thing running.

    – Guillaume Coté
    Nov 6 '10 at 18:53



















7














The most useful tool is lsof Install lsof. It shows what files are in used by what processes. If /media/KINGSTON is a mount point (the device name would also work), the following command shows all files that are in use on this mount point:



lsof /media/KINGSTON


If you run this command as an ordinary user, it will only show your own processes¹. Run sudo lsof /media/KINGSTON to see all users' processes.



The output from lsof looks like this:



COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
zsh4 31421 gilles cwd DIR 8,1 4096 130498 /var/tmp
zsh4 31421 gilles txt REG 8,1 550804 821292 /bin/zsh4
zsh4 31421 gilles mem REG 8,1 55176 821326 /usr/lib/zsh/4.3.10/zsh/complist.so
zsh4 31421 gilles 12r REG 8,1 175224 822276 /usr/share/zsh/functions/Completion.zwc


The COMMAND column shows the name of the program executable and the PID column shows the process ID. The NAME column shows the file name; you might see (deleted) if the file was deleted while open (when a file is deleted, it no longer has a name, but it still exists until the last process using it closes the file). USER should be self-explanatory. The other columns don't matter here except perhaps FD, which shows how the file is used by the process:





  • cwd: current working directory


  • txt: the program executable²


  • mem: a memory-mapped file (here, think of it as an open file)

  • a number: an actual open file; a subsequent letter indicates the opening mode, such as r for reading and w for writing


There is no mechanical way to locate the window where a file is open (this is in fact not technically meaningful: if a process has several windows, a file is not particularly associated with one window or another), nor even any simple way of identifying a process's window (and of course a process doesn't have to have any windows). But usually the command name and file name are enough to locate the offender and close the file properly.



If you can't close the file and just want to end it all, you can kill the process with kill 31421 (where 31421 is the process ID) or kill -HUP 31421 (“hang up”). If plain killing doesn't do the trick, kill with extreme prejudice: kill -KILL 31421.



There is a GUI for lsof, glsof, but it's not quite ready for prime time yet, and isn't packaged for Ubuntu so far.



¹
Lsof can list some information about other users's processes, but it doesn't detect the mount point so won't list them if you specify a mount point.


²
Executable code is often called text in discussions of executable formats.






share|improve this answer

































    2














    Also this can help:



    lsof | grep /media/KINGSTON





    share|improve this answer





















    • 3





      There's no need to escape the slashes.

      – Marius Gedminas
      Nov 6 '10 at 14:56











    • When you're unsure, grep with quotes e.g. grep "media/KINGSTON"

      – Adam Matan
      Dec 16 '10 at 13:55



















    2














    Meanwhile the fuser command has much improved. You can do the full job with a single command:



    $ sudo fuser -ickv /"mountpoint"


    Where:




    • parameter k kills the offending process,

    • while v shows in advance the process and its user

    • and i asks you for confirmation.


    If some process resists, then try again with fuser -ickv -9 (or more generally with -SIGNAL) that kills the most stubborn ones.

    But you will always find some "immortal" process...!



    In this cases I lately learned to use



    $ sudo umount --lazy --force <mountpoint>


    as a last resource, that up to now worked for me every time.






    share|improve this answer


























    • I found the immortal process, my failed attempt to use vboxmanage. -_-

      – sudo
      Sep 8 '17 at 0:04












    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%2f11713%2fhow-do-i-find-out-which-process-is-preventing-a-umount%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    4 Answers
    4






    active

    oldest

    votes








    4 Answers
    4






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    23














    open a terminal:



    fuser -c /media/KINGSTON


    It will output something like this:



    /media/KINGSTON/: 3106c 11086


    This will give you the pid of the processes using this volume. The extra character at the end of pid will give some extra info. ( c in 3106c)



    c - the process is using the file as its current working directory

    m - the file is mapped with mmap

    o - the process is using it as an open file

    r - the file is the root directory of the process

    t - the process is accessing the file as a text file

    y - this file is the controlling terminal for the process



    So to unmount just kill that pids and re-try the unmount



    sudo kill -9 3106 11086
    sudo umount /media/KINGSTON


    Note: To find the exact application name of these pids you may use this command



    cat /proc/<pid>/cmdline


    For example : cat /proc/11086/cmdline



    this will output something like below.



        evince^@/media/KINGSTON/Ubuntu-guide.pdf^@


    Hope this will help






    share|improve this answer





















    • 2





      fuser -ck would also kill it.

      – João Pinto
      Nov 6 '10 at 8:05






    • 3





      I would suggest killing them without the -9 option first, to give those applications the chance to cleanly shut down. And I would suggest using ps <pid> instead of editing files in /proc to see the command name and arguments.

      – Marius Gedminas
      Nov 6 '10 at 14:55











    • I follow your procedure to find the process, it is Thunar--deamon. There are no extra character giving extra info. I have not kill it yet, I am worring about the impact it could have on other thing running.

      – Guillaume Coté
      Nov 6 '10 at 18:53
















    23














    open a terminal:



    fuser -c /media/KINGSTON


    It will output something like this:



    /media/KINGSTON/: 3106c 11086


    This will give you the pid of the processes using this volume. The extra character at the end of pid will give some extra info. ( c in 3106c)



    c - the process is using the file as its current working directory

    m - the file is mapped with mmap

    o - the process is using it as an open file

    r - the file is the root directory of the process

    t - the process is accessing the file as a text file

    y - this file is the controlling terminal for the process



    So to unmount just kill that pids and re-try the unmount



    sudo kill -9 3106 11086
    sudo umount /media/KINGSTON


    Note: To find the exact application name of these pids you may use this command



    cat /proc/<pid>/cmdline


    For example : cat /proc/11086/cmdline



    this will output something like below.



        evince^@/media/KINGSTON/Ubuntu-guide.pdf^@


    Hope this will help






    share|improve this answer





















    • 2





      fuser -ck would also kill it.

      – João Pinto
      Nov 6 '10 at 8:05






    • 3





      I would suggest killing them without the -9 option first, to give those applications the chance to cleanly shut down. And I would suggest using ps <pid> instead of editing files in /proc to see the command name and arguments.

      – Marius Gedminas
      Nov 6 '10 at 14:55











    • I follow your procedure to find the process, it is Thunar--deamon. There are no extra character giving extra info. I have not kill it yet, I am worring about the impact it could have on other thing running.

      – Guillaume Coté
      Nov 6 '10 at 18:53














    23












    23








    23







    open a terminal:



    fuser -c /media/KINGSTON


    It will output something like this:



    /media/KINGSTON/: 3106c 11086


    This will give you the pid of the processes using this volume. The extra character at the end of pid will give some extra info. ( c in 3106c)



    c - the process is using the file as its current working directory

    m - the file is mapped with mmap

    o - the process is using it as an open file

    r - the file is the root directory of the process

    t - the process is accessing the file as a text file

    y - this file is the controlling terminal for the process



    So to unmount just kill that pids and re-try the unmount



    sudo kill -9 3106 11086
    sudo umount /media/KINGSTON


    Note: To find the exact application name of these pids you may use this command



    cat /proc/<pid>/cmdline


    For example : cat /proc/11086/cmdline



    this will output something like below.



        evince^@/media/KINGSTON/Ubuntu-guide.pdf^@


    Hope this will help






    share|improve this answer















    open a terminal:



    fuser -c /media/KINGSTON


    It will output something like this:



    /media/KINGSTON/: 3106c 11086


    This will give you the pid of the processes using this volume. The extra character at the end of pid will give some extra info. ( c in 3106c)



    c - the process is using the file as its current working directory

    m - the file is mapped with mmap

    o - the process is using it as an open file

    r - the file is the root directory of the process

    t - the process is accessing the file as a text file

    y - this file is the controlling terminal for the process



    So to unmount just kill that pids and re-try the unmount



    sudo kill -9 3106 11086
    sudo umount /media/KINGSTON


    Note: To find the exact application name of these pids you may use this command



    cat /proc/<pid>/cmdline


    For example : cat /proc/11086/cmdline



    this will output something like below.



        evince^@/media/KINGSTON/Ubuntu-guide.pdf^@


    Hope this will help







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Nov 6 '10 at 15:27

























    answered Nov 6 '10 at 8:01









    aneeshepaneeshep

    22.5k115574




    22.5k115574








    • 2





      fuser -ck would also kill it.

      – João Pinto
      Nov 6 '10 at 8:05






    • 3





      I would suggest killing them without the -9 option first, to give those applications the chance to cleanly shut down. And I would suggest using ps <pid> instead of editing files in /proc to see the command name and arguments.

      – Marius Gedminas
      Nov 6 '10 at 14:55











    • I follow your procedure to find the process, it is Thunar--deamon. There are no extra character giving extra info. I have not kill it yet, I am worring about the impact it could have on other thing running.

      – Guillaume Coté
      Nov 6 '10 at 18:53














    • 2





      fuser -ck would also kill it.

      – João Pinto
      Nov 6 '10 at 8:05






    • 3





      I would suggest killing them without the -9 option first, to give those applications the chance to cleanly shut down. And I would suggest using ps <pid> instead of editing files in /proc to see the command name and arguments.

      – Marius Gedminas
      Nov 6 '10 at 14:55











    • I follow your procedure to find the process, it is Thunar--deamon. There are no extra character giving extra info. I have not kill it yet, I am worring about the impact it could have on other thing running.

      – Guillaume Coté
      Nov 6 '10 at 18:53








    2




    2





    fuser -ck would also kill it.

    – João Pinto
    Nov 6 '10 at 8:05





    fuser -ck would also kill it.

    – João Pinto
    Nov 6 '10 at 8:05




    3




    3





    I would suggest killing them without the -9 option first, to give those applications the chance to cleanly shut down. And I would suggest using ps <pid> instead of editing files in /proc to see the command name and arguments.

    – Marius Gedminas
    Nov 6 '10 at 14:55





    I would suggest killing them without the -9 option first, to give those applications the chance to cleanly shut down. And I would suggest using ps <pid> instead of editing files in /proc to see the command name and arguments.

    – Marius Gedminas
    Nov 6 '10 at 14:55













    I follow your procedure to find the process, it is Thunar--deamon. There are no extra character giving extra info. I have not kill it yet, I am worring about the impact it could have on other thing running.

    – Guillaume Coté
    Nov 6 '10 at 18:53





    I follow your procedure to find the process, it is Thunar--deamon. There are no extra character giving extra info. I have not kill it yet, I am worring about the impact it could have on other thing running.

    – Guillaume Coté
    Nov 6 '10 at 18:53













    7














    The most useful tool is lsof Install lsof. It shows what files are in used by what processes. If /media/KINGSTON is a mount point (the device name would also work), the following command shows all files that are in use on this mount point:



    lsof /media/KINGSTON


    If you run this command as an ordinary user, it will only show your own processes¹. Run sudo lsof /media/KINGSTON to see all users' processes.



    The output from lsof looks like this:



    COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
    zsh4 31421 gilles cwd DIR 8,1 4096 130498 /var/tmp
    zsh4 31421 gilles txt REG 8,1 550804 821292 /bin/zsh4
    zsh4 31421 gilles mem REG 8,1 55176 821326 /usr/lib/zsh/4.3.10/zsh/complist.so
    zsh4 31421 gilles 12r REG 8,1 175224 822276 /usr/share/zsh/functions/Completion.zwc


    The COMMAND column shows the name of the program executable and the PID column shows the process ID. The NAME column shows the file name; you might see (deleted) if the file was deleted while open (when a file is deleted, it no longer has a name, but it still exists until the last process using it closes the file). USER should be self-explanatory. The other columns don't matter here except perhaps FD, which shows how the file is used by the process:





    • cwd: current working directory


    • txt: the program executable²


    • mem: a memory-mapped file (here, think of it as an open file)

    • a number: an actual open file; a subsequent letter indicates the opening mode, such as r for reading and w for writing


    There is no mechanical way to locate the window where a file is open (this is in fact not technically meaningful: if a process has several windows, a file is not particularly associated with one window or another), nor even any simple way of identifying a process's window (and of course a process doesn't have to have any windows). But usually the command name and file name are enough to locate the offender and close the file properly.



    If you can't close the file and just want to end it all, you can kill the process with kill 31421 (where 31421 is the process ID) or kill -HUP 31421 (“hang up”). If plain killing doesn't do the trick, kill with extreme prejudice: kill -KILL 31421.



    There is a GUI for lsof, glsof, but it's not quite ready for prime time yet, and isn't packaged for Ubuntu so far.



    ¹
    Lsof can list some information about other users's processes, but it doesn't detect the mount point so won't list them if you specify a mount point.


    ²
    Executable code is often called text in discussions of executable formats.






    share|improve this answer






























      7














      The most useful tool is lsof Install lsof. It shows what files are in used by what processes. If /media/KINGSTON is a mount point (the device name would also work), the following command shows all files that are in use on this mount point:



      lsof /media/KINGSTON


      If you run this command as an ordinary user, it will only show your own processes¹. Run sudo lsof /media/KINGSTON to see all users' processes.



      The output from lsof looks like this:



      COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
      zsh4 31421 gilles cwd DIR 8,1 4096 130498 /var/tmp
      zsh4 31421 gilles txt REG 8,1 550804 821292 /bin/zsh4
      zsh4 31421 gilles mem REG 8,1 55176 821326 /usr/lib/zsh/4.3.10/zsh/complist.so
      zsh4 31421 gilles 12r REG 8,1 175224 822276 /usr/share/zsh/functions/Completion.zwc


      The COMMAND column shows the name of the program executable and the PID column shows the process ID. The NAME column shows the file name; you might see (deleted) if the file was deleted while open (when a file is deleted, it no longer has a name, but it still exists until the last process using it closes the file). USER should be self-explanatory. The other columns don't matter here except perhaps FD, which shows how the file is used by the process:





      • cwd: current working directory


      • txt: the program executable²


      • mem: a memory-mapped file (here, think of it as an open file)

      • a number: an actual open file; a subsequent letter indicates the opening mode, such as r for reading and w for writing


      There is no mechanical way to locate the window where a file is open (this is in fact not technically meaningful: if a process has several windows, a file is not particularly associated with one window or another), nor even any simple way of identifying a process's window (and of course a process doesn't have to have any windows). But usually the command name and file name are enough to locate the offender and close the file properly.



      If you can't close the file and just want to end it all, you can kill the process with kill 31421 (where 31421 is the process ID) or kill -HUP 31421 (“hang up”). If plain killing doesn't do the trick, kill with extreme prejudice: kill -KILL 31421.



      There is a GUI for lsof, glsof, but it's not quite ready for prime time yet, and isn't packaged for Ubuntu so far.



      ¹
      Lsof can list some information about other users's processes, but it doesn't detect the mount point so won't list them if you specify a mount point.


      ²
      Executable code is often called text in discussions of executable formats.






      share|improve this answer




























        7












        7








        7







        The most useful tool is lsof Install lsof. It shows what files are in used by what processes. If /media/KINGSTON is a mount point (the device name would also work), the following command shows all files that are in use on this mount point:



        lsof /media/KINGSTON


        If you run this command as an ordinary user, it will only show your own processes¹. Run sudo lsof /media/KINGSTON to see all users' processes.



        The output from lsof looks like this:



        COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
        zsh4 31421 gilles cwd DIR 8,1 4096 130498 /var/tmp
        zsh4 31421 gilles txt REG 8,1 550804 821292 /bin/zsh4
        zsh4 31421 gilles mem REG 8,1 55176 821326 /usr/lib/zsh/4.3.10/zsh/complist.so
        zsh4 31421 gilles 12r REG 8,1 175224 822276 /usr/share/zsh/functions/Completion.zwc


        The COMMAND column shows the name of the program executable and the PID column shows the process ID. The NAME column shows the file name; you might see (deleted) if the file was deleted while open (when a file is deleted, it no longer has a name, but it still exists until the last process using it closes the file). USER should be self-explanatory. The other columns don't matter here except perhaps FD, which shows how the file is used by the process:





        • cwd: current working directory


        • txt: the program executable²


        • mem: a memory-mapped file (here, think of it as an open file)

        • a number: an actual open file; a subsequent letter indicates the opening mode, such as r for reading and w for writing


        There is no mechanical way to locate the window where a file is open (this is in fact not technically meaningful: if a process has several windows, a file is not particularly associated with one window or another), nor even any simple way of identifying a process's window (and of course a process doesn't have to have any windows). But usually the command name and file name are enough to locate the offender and close the file properly.



        If you can't close the file and just want to end it all, you can kill the process with kill 31421 (where 31421 is the process ID) or kill -HUP 31421 (“hang up”). If plain killing doesn't do the trick, kill with extreme prejudice: kill -KILL 31421.



        There is a GUI for lsof, glsof, but it's not quite ready for prime time yet, and isn't packaged for Ubuntu so far.



        ¹
        Lsof can list some information about other users's processes, but it doesn't detect the mount point so won't list them if you specify a mount point.


        ²
        Executable code is often called text in discussions of executable formats.






        share|improve this answer















        The most useful tool is lsof Install lsof. It shows what files are in used by what processes. If /media/KINGSTON is a mount point (the device name would also work), the following command shows all files that are in use on this mount point:



        lsof /media/KINGSTON


        If you run this command as an ordinary user, it will only show your own processes¹. Run sudo lsof /media/KINGSTON to see all users' processes.



        The output from lsof looks like this:



        COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
        zsh4 31421 gilles cwd DIR 8,1 4096 130498 /var/tmp
        zsh4 31421 gilles txt REG 8,1 550804 821292 /bin/zsh4
        zsh4 31421 gilles mem REG 8,1 55176 821326 /usr/lib/zsh/4.3.10/zsh/complist.so
        zsh4 31421 gilles 12r REG 8,1 175224 822276 /usr/share/zsh/functions/Completion.zwc


        The COMMAND column shows the name of the program executable and the PID column shows the process ID. The NAME column shows the file name; you might see (deleted) if the file was deleted while open (when a file is deleted, it no longer has a name, but it still exists until the last process using it closes the file). USER should be self-explanatory. The other columns don't matter here except perhaps FD, which shows how the file is used by the process:





        • cwd: current working directory


        • txt: the program executable²


        • mem: a memory-mapped file (here, think of it as an open file)

        • a number: an actual open file; a subsequent letter indicates the opening mode, such as r for reading and w for writing


        There is no mechanical way to locate the window where a file is open (this is in fact not technically meaningful: if a process has several windows, a file is not particularly associated with one window or another), nor even any simple way of identifying a process's window (and of course a process doesn't have to have any windows). But usually the command name and file name are enough to locate the offender and close the file properly.



        If you can't close the file and just want to end it all, you can kill the process with kill 31421 (where 31421 is the process ID) or kill -HUP 31421 (“hang up”). If plain killing doesn't do the trick, kill with extreme prejudice: kill -KILL 31421.



        There is a GUI for lsof, glsof, but it's not quite ready for prime time yet, and isn't packaged for Ubuntu so far.



        ¹
        Lsof can list some information about other users's processes, but it doesn't detect the mount point so won't list them if you specify a mount point.


        ²
        Executable code is often called text in discussions of executable formats.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Mar 11 '17 at 21:21









        Zanna

        51.1k13139242




        51.1k13139242










        answered Nov 6 '10 at 12:59









        GillesGilles

        45.4k13102141




        45.4k13102141























            2














            Also this can help:



            lsof | grep /media/KINGSTON





            share|improve this answer





















            • 3





              There's no need to escape the slashes.

              – Marius Gedminas
              Nov 6 '10 at 14:56











            • When you're unsure, grep with quotes e.g. grep "media/KINGSTON"

              – Adam Matan
              Dec 16 '10 at 13:55
















            2














            Also this can help:



            lsof | grep /media/KINGSTON





            share|improve this answer





















            • 3





              There's no need to escape the slashes.

              – Marius Gedminas
              Nov 6 '10 at 14:56











            • When you're unsure, grep with quotes e.g. grep "media/KINGSTON"

              – Adam Matan
              Dec 16 '10 at 13:55














            2












            2








            2







            Also this can help:



            lsof | grep /media/KINGSTON





            share|improve this answer















            Also this can help:



            lsof | grep /media/KINGSTON






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jan 14 '16 at 3:01









            muru

            1




            1










            answered Nov 6 '10 at 8:02









            Hashem MasoudHashem Masoud

            292




            292








            • 3





              There's no need to escape the slashes.

              – Marius Gedminas
              Nov 6 '10 at 14:56











            • When you're unsure, grep with quotes e.g. grep "media/KINGSTON"

              – Adam Matan
              Dec 16 '10 at 13:55














            • 3





              There's no need to escape the slashes.

              – Marius Gedminas
              Nov 6 '10 at 14:56











            • When you're unsure, grep with quotes e.g. grep "media/KINGSTON"

              – Adam Matan
              Dec 16 '10 at 13:55








            3




            3





            There's no need to escape the slashes.

            – Marius Gedminas
            Nov 6 '10 at 14:56





            There's no need to escape the slashes.

            – Marius Gedminas
            Nov 6 '10 at 14:56













            When you're unsure, grep with quotes e.g. grep "media/KINGSTON"

            – Adam Matan
            Dec 16 '10 at 13:55





            When you're unsure, grep with quotes e.g. grep "media/KINGSTON"

            – Adam Matan
            Dec 16 '10 at 13:55











            2














            Meanwhile the fuser command has much improved. You can do the full job with a single command:



            $ sudo fuser -ickv /"mountpoint"


            Where:




            • parameter k kills the offending process,

            • while v shows in advance the process and its user

            • and i asks you for confirmation.


            If some process resists, then try again with fuser -ickv -9 (or more generally with -SIGNAL) that kills the most stubborn ones.

            But you will always find some "immortal" process...!



            In this cases I lately learned to use



            $ sudo umount --lazy --force <mountpoint>


            as a last resource, that up to now worked for me every time.






            share|improve this answer


























            • I found the immortal process, my failed attempt to use vboxmanage. -_-

              – sudo
              Sep 8 '17 at 0:04
















            2














            Meanwhile the fuser command has much improved. You can do the full job with a single command:



            $ sudo fuser -ickv /"mountpoint"


            Where:




            • parameter k kills the offending process,

            • while v shows in advance the process and its user

            • and i asks you for confirmation.


            If some process resists, then try again with fuser -ickv -9 (or more generally with -SIGNAL) that kills the most stubborn ones.

            But you will always find some "immortal" process...!



            In this cases I lately learned to use



            $ sudo umount --lazy --force <mountpoint>


            as a last resource, that up to now worked for me every time.






            share|improve this answer


























            • I found the immortal process, my failed attempt to use vboxmanage. -_-

              – sudo
              Sep 8 '17 at 0:04














            2












            2








            2







            Meanwhile the fuser command has much improved. You can do the full job with a single command:



            $ sudo fuser -ickv /"mountpoint"


            Where:




            • parameter k kills the offending process,

            • while v shows in advance the process and its user

            • and i asks you for confirmation.


            If some process resists, then try again with fuser -ickv -9 (or more generally with -SIGNAL) that kills the most stubborn ones.

            But you will always find some "immortal" process...!



            In this cases I lately learned to use



            $ sudo umount --lazy --force <mountpoint>


            as a last resource, that up to now worked for me every time.






            share|improve this answer















            Meanwhile the fuser command has much improved. You can do the full job with a single command:



            $ sudo fuser -ickv /"mountpoint"


            Where:




            • parameter k kills the offending process,

            • while v shows in advance the process and its user

            • and i asks you for confirmation.


            If some process resists, then try again with fuser -ickv -9 (or more generally with -SIGNAL) that kills the most stubborn ones.

            But you will always find some "immortal" process...!



            In this cases I lately learned to use



            $ sudo umount --lazy --force <mountpoint>


            as a last resource, that up to now worked for me every time.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Mar 17 at 23:46

























            answered Jan 14 '16 at 0:56









            prometheosprometheos

            81119




            81119













            • I found the immortal process, my failed attempt to use vboxmanage. -_-

              – sudo
              Sep 8 '17 at 0:04



















            • I found the immortal process, my failed attempt to use vboxmanage. -_-

              – sudo
              Sep 8 '17 at 0:04

















            I found the immortal process, my failed attempt to use vboxmanage. -_-

            – sudo
            Sep 8 '17 at 0:04





            I found the immortal process, my failed attempt to use vboxmanage. -_-

            – sudo
            Sep 8 '17 at 0:04


















            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%2f11713%2fhow-do-i-find-out-which-process-is-preventing-a-umount%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

            數位音樂下載

            When can things happen in Etherscan, such as the picture below?

            格利澤436b