Portable Ubuntu with ability to create, mount and remove without traces encrypted virtual disks on any HDD












3















I will be on vacations and where I go, there will be a computer in my room. I don't know what type of computer, how old, what specs, nothing. But probably it will have Windows installed and probably I will only be able to login as restricted user.



Both are things I don't like.



So I thought I could bring my own portable Ubuntu on a bootable 8GB USB stick with me. But you see that 8GB is not really much and USB is also not the fastest thing on the world, especially if the computer might only have 2.0 ports.



Therefore I would love if I could outsource swap and probably even some data or system parts to the HDD of this computer, but I don't want to modify the existing system in any way, so repartitioning is not an option.



I think creating a virtual file system image file inside the existing file system and mounting that one would be best. It should be encrypted though.



And no, a simple live USB is not enough, it has at least to be persistent. However, the HDD using feature should be there too.



So how could I best set this up, a system installed on a USB stick that can create and mount an encrypted virtual disk on an existing file system without irreversibly modifying it? Detailed step-by-step guides appreciated, wherever the installation differs from a normal desktop installation.










share|improve this question





























    3















    I will be on vacations and where I go, there will be a computer in my room. I don't know what type of computer, how old, what specs, nothing. But probably it will have Windows installed and probably I will only be able to login as restricted user.



    Both are things I don't like.



    So I thought I could bring my own portable Ubuntu on a bootable 8GB USB stick with me. But you see that 8GB is not really much and USB is also not the fastest thing on the world, especially if the computer might only have 2.0 ports.



    Therefore I would love if I could outsource swap and probably even some data or system parts to the HDD of this computer, but I don't want to modify the existing system in any way, so repartitioning is not an option.



    I think creating a virtual file system image file inside the existing file system and mounting that one would be best. It should be encrypted though.



    And no, a simple live USB is not enough, it has at least to be persistent. However, the HDD using feature should be there too.



    So how could I best set this up, a system installed on a USB stick that can create and mount an encrypted virtual disk on an existing file system without irreversibly modifying it? Detailed step-by-step guides appreciated, wherever the installation differs from a normal desktop installation.










    share|improve this question



























      3












      3








      3








      I will be on vacations and where I go, there will be a computer in my room. I don't know what type of computer, how old, what specs, nothing. But probably it will have Windows installed and probably I will only be able to login as restricted user.



      Both are things I don't like.



      So I thought I could bring my own portable Ubuntu on a bootable 8GB USB stick with me. But you see that 8GB is not really much and USB is also not the fastest thing on the world, especially if the computer might only have 2.0 ports.



      Therefore I would love if I could outsource swap and probably even some data or system parts to the HDD of this computer, but I don't want to modify the existing system in any way, so repartitioning is not an option.



      I think creating a virtual file system image file inside the existing file system and mounting that one would be best. It should be encrypted though.



      And no, a simple live USB is not enough, it has at least to be persistent. However, the HDD using feature should be there too.



      So how could I best set this up, a system installed on a USB stick that can create and mount an encrypted virtual disk on an existing file system without irreversibly modifying it? Detailed step-by-step guides appreciated, wherever the installation differs from a normal desktop installation.










      share|improve this question
















      I will be on vacations and where I go, there will be a computer in my room. I don't know what type of computer, how old, what specs, nothing. But probably it will have Windows installed and probably I will only be able to login as restricted user.



      Both are things I don't like.



      So I thought I could bring my own portable Ubuntu on a bootable 8GB USB stick with me. But you see that 8GB is not really much and USB is also not the fastest thing on the world, especially if the computer might only have 2.0 ports.



      Therefore I would love if I could outsource swap and probably even some data or system parts to the HDD of this computer, but I don't want to modify the existing system in any way, so repartitioning is not an option.



      I think creating a virtual file system image file inside the existing file system and mounting that one would be best. It should be encrypted though.



      And no, a simple live USB is not enough, it has at least to be persistent. However, the HDD using feature should be there too.



      So how could I best set this up, a system installed on a USB stick that can create and mount an encrypted virtual disk on an existing file system without irreversibly modifying it? Detailed step-by-step guides appreciated, wherever the installation differs from a normal desktop installation.







      partitioning system-installation encryption disk-image






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jul 23 '18 at 21:12









      David Foerster

      27.9k1364110




      27.9k1364110










      asked Aug 10 '15 at 21:17









      Byte CommanderByte Commander

      63.6k26173292




      63.6k26173292






















          1 Answer
          1






          active

          oldest

          votes


















          8














          Regular file systems





          1. Create a file on the existing file system on the internal drive of the computer (probably NTFS) for each (encrypted) partition, that you want to create, assuming the internal file system is mounted at /mnt/internal-drive and 1 GiB as the desired size of the resulting partition:



            head -c 1G < /dev/zero > /mnt/internal-drive/some/arbitrary/path/partition.img


            If you want a nice progress indicator you can use pv:



            head -c 1G < /dev/zero | pv -s 1g -pterab > .../partition.img


            If you want to create a partition based on a sparse file instead, use truncate(1) with the --size (shorthand: -s) option to specify the size in bytes:



            truncate -s 1073741824 .../partition.img


            Sparse files are fast to create and only occupy as much space as needed on the underlying file systems, but can become slow to access due to fragmentation. Some older file systems like FAT don't support sparse files. NTFS does.




          2. Initialise the desired file system in the just created file, e. g. ext4:



            mkfs -t ext4 [FS-OPTIONS...] .../partition.img


            The file system initialiser may ask you to confirm to create a file system inside a regular file or may even refuse to do so, unless you set a --force flag or similar.




          3. Create a loop device backed by the partition file and mount it. Reasonably recent versions of mount(8), can do this in one step with the loop option:



            mount -t ext4 -o defaults,loop[,FS-OPTIONS...] .../partition.img /mnt/my-partition


          4. Enjoy!



          Swap partitions




          1. Like step 1 above, but you probably want to avoid the sparse option.



          2. Initialize the swap file:



            mkswap /mnt/internal-drive/some/arbitrary/path/swap.img



          3. Swap-on:



            swapon [OPTIONS...] /mnt/internal-drive/some/arbitrary/path/swap.img



          Block-level encryption



          Just like in the previous sections, regular files can be used pretty much like block devices. So you can use cryptsetup(8), crypttab(5), cryptdisks_start(8) and cryptdisks_stop(8) as you normally would, since they create loop devices for regular files automatically:




          1. Like step 1 in the above sections.



          2. If you want to use LUKS to manage your encrypted partition, initialize it:



            cryptsetup luksFormat .../partition.img [OPTIONS...]



          3. Open the partition with your chosen encryption type and options:



            cryptsetup open .../partition.img <NAME> --type <DEVICE_TYPE> [OPTIONS...]


            Where <NAME> is the name of the dm-crypt mapping to create for the partition and <DEVICE_TYPE> is luks, if you have created a LUKS wrapper in step 2, or plain for a plain dm-crypt partition. (cryptsetup supports other device types, but they're either legacy or for TrueCrypt compatibility.)




          4. The encrypted partition is now available at /dev/mapper/<NAME>.




            • You can create and mount file systems on it like on any block device as outlined in the above sections starting in step 2, or



            • you can create a partition table inside it with your favourite partition manager, if you want to wrap multiple partitions inside it without having to supply the same passphrase multiple times for them individually:



              fdisk /dev/mapper/<NAME>


              Ask the kernel to re-read the partition table and to repopulate the device node files in /dev:



              partprobe /dev/mapper/<NAME>


              You now have the individual partitions available at /dev/mapper/<NAME>1 and so forth.






          Mounting at boot



          You can create fstab (and crypttab) entries for theses partitions just like you would normally, but with the loop option like above. File-based swap spaces don't need special mount options. You just need to take care to mount the underlying filesystem on the internal drive before these new partitions. E. g.:



          LABEL=Windows    /mnt/internal-drive    ntfs    defaults    0  2
          /mnt/internal-drive/some/arbitrary/path/home.img /home ext4 defaults,loop 0 3
          /mnt/internal-drive/some/arbitrary/path/swap.bin none swap sw 0 0


          Destroying the file system afterwards



          Short version: Don't! Use encryption and destroy the key.



          Long version: Overwriting or "shredding" of individual files works under the assumption, that the file never occupied other drive sectors than it currently does (e. g. because the file system or one of its maintenance tools (e. g. de-fragmentation) decided to relocate them) and that no file data ever leaks into file system meta-data section (e. g. like during journalling). These assumptions may hold under most circumstances for older, non-journalling file systems (FAT, ext2). For NTFS, ext3/4 and HFS+ they don't hold reliably except under rare, impractical/unrealistic conditions.



          You can go as far as to overwrite all unallocated sectors in addition to the sector currently occupied by the drive image file. Microsoft's cipher.exe can do this for NTFS, which supposedly catches almost all sectors, that may still contain left-overs of your precious file system image.






          share|improve this answer





















          • 1





            Wonderful! That was the answer I waited for for over two months. :D Unfortunately my personal use case has faded away - but it's great to know how it would be done when I need that once again. Thanks very much.

            – Byte Commander
            Oct 23 '15 at 11:03






          • 1





            What you might add if you have time is how to create encrypted partitions instead and how to safely shred them from the host machine's disk later.

            – Byte Commander
            Oct 23 '15 at 11:05











          • Oh yeah, I forgot about encryption, since that's basically the same as for block devices. I'll add that in a moment.

            – David Foerster
            Oct 24 '15 at 10:15











          • @DavidFoerster : WOW - BRILLIANT - if I could give +10 I would - so only +1 ... keep up your good work ! :)

            – cl-netbox
            Oct 30 '15 at 17:24











          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%2f659911%2fportable-ubuntu-with-ability-to-create-mount-and-remove-without-traces-encrypte%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









          8














          Regular file systems





          1. Create a file on the existing file system on the internal drive of the computer (probably NTFS) for each (encrypted) partition, that you want to create, assuming the internal file system is mounted at /mnt/internal-drive and 1 GiB as the desired size of the resulting partition:



            head -c 1G < /dev/zero > /mnt/internal-drive/some/arbitrary/path/partition.img


            If you want a nice progress indicator you can use pv:



            head -c 1G < /dev/zero | pv -s 1g -pterab > .../partition.img


            If you want to create a partition based on a sparse file instead, use truncate(1) with the --size (shorthand: -s) option to specify the size in bytes:



            truncate -s 1073741824 .../partition.img


            Sparse files are fast to create and only occupy as much space as needed on the underlying file systems, but can become slow to access due to fragmentation. Some older file systems like FAT don't support sparse files. NTFS does.




          2. Initialise the desired file system in the just created file, e. g. ext4:



            mkfs -t ext4 [FS-OPTIONS...] .../partition.img


            The file system initialiser may ask you to confirm to create a file system inside a regular file or may even refuse to do so, unless you set a --force flag or similar.




          3. Create a loop device backed by the partition file and mount it. Reasonably recent versions of mount(8), can do this in one step with the loop option:



            mount -t ext4 -o defaults,loop[,FS-OPTIONS...] .../partition.img /mnt/my-partition


          4. Enjoy!



          Swap partitions




          1. Like step 1 above, but you probably want to avoid the sparse option.



          2. Initialize the swap file:



            mkswap /mnt/internal-drive/some/arbitrary/path/swap.img



          3. Swap-on:



            swapon [OPTIONS...] /mnt/internal-drive/some/arbitrary/path/swap.img



          Block-level encryption



          Just like in the previous sections, regular files can be used pretty much like block devices. So you can use cryptsetup(8), crypttab(5), cryptdisks_start(8) and cryptdisks_stop(8) as you normally would, since they create loop devices for regular files automatically:




          1. Like step 1 in the above sections.



          2. If you want to use LUKS to manage your encrypted partition, initialize it:



            cryptsetup luksFormat .../partition.img [OPTIONS...]



          3. Open the partition with your chosen encryption type and options:



            cryptsetup open .../partition.img <NAME> --type <DEVICE_TYPE> [OPTIONS...]


            Where <NAME> is the name of the dm-crypt mapping to create for the partition and <DEVICE_TYPE> is luks, if you have created a LUKS wrapper in step 2, or plain for a plain dm-crypt partition. (cryptsetup supports other device types, but they're either legacy or for TrueCrypt compatibility.)




          4. The encrypted partition is now available at /dev/mapper/<NAME>.




            • You can create and mount file systems on it like on any block device as outlined in the above sections starting in step 2, or



            • you can create a partition table inside it with your favourite partition manager, if you want to wrap multiple partitions inside it without having to supply the same passphrase multiple times for them individually:



              fdisk /dev/mapper/<NAME>


              Ask the kernel to re-read the partition table and to repopulate the device node files in /dev:



              partprobe /dev/mapper/<NAME>


              You now have the individual partitions available at /dev/mapper/<NAME>1 and so forth.






          Mounting at boot



          You can create fstab (and crypttab) entries for theses partitions just like you would normally, but with the loop option like above. File-based swap spaces don't need special mount options. You just need to take care to mount the underlying filesystem on the internal drive before these new partitions. E. g.:



          LABEL=Windows    /mnt/internal-drive    ntfs    defaults    0  2
          /mnt/internal-drive/some/arbitrary/path/home.img /home ext4 defaults,loop 0 3
          /mnt/internal-drive/some/arbitrary/path/swap.bin none swap sw 0 0


          Destroying the file system afterwards



          Short version: Don't! Use encryption and destroy the key.



          Long version: Overwriting or "shredding" of individual files works under the assumption, that the file never occupied other drive sectors than it currently does (e. g. because the file system or one of its maintenance tools (e. g. de-fragmentation) decided to relocate them) and that no file data ever leaks into file system meta-data section (e. g. like during journalling). These assumptions may hold under most circumstances for older, non-journalling file systems (FAT, ext2). For NTFS, ext3/4 and HFS+ they don't hold reliably except under rare, impractical/unrealistic conditions.



          You can go as far as to overwrite all unallocated sectors in addition to the sector currently occupied by the drive image file. Microsoft's cipher.exe can do this for NTFS, which supposedly catches almost all sectors, that may still contain left-overs of your precious file system image.






          share|improve this answer





















          • 1





            Wonderful! That was the answer I waited for for over two months. :D Unfortunately my personal use case has faded away - but it's great to know how it would be done when I need that once again. Thanks very much.

            – Byte Commander
            Oct 23 '15 at 11:03






          • 1





            What you might add if you have time is how to create encrypted partitions instead and how to safely shred them from the host machine's disk later.

            – Byte Commander
            Oct 23 '15 at 11:05











          • Oh yeah, I forgot about encryption, since that's basically the same as for block devices. I'll add that in a moment.

            – David Foerster
            Oct 24 '15 at 10:15











          • @DavidFoerster : WOW - BRILLIANT - if I could give +10 I would - so only +1 ... keep up your good work ! :)

            – cl-netbox
            Oct 30 '15 at 17:24
















          8














          Regular file systems





          1. Create a file on the existing file system on the internal drive of the computer (probably NTFS) for each (encrypted) partition, that you want to create, assuming the internal file system is mounted at /mnt/internal-drive and 1 GiB as the desired size of the resulting partition:



            head -c 1G < /dev/zero > /mnt/internal-drive/some/arbitrary/path/partition.img


            If you want a nice progress indicator you can use pv:



            head -c 1G < /dev/zero | pv -s 1g -pterab > .../partition.img


            If you want to create a partition based on a sparse file instead, use truncate(1) with the --size (shorthand: -s) option to specify the size in bytes:



            truncate -s 1073741824 .../partition.img


            Sparse files are fast to create and only occupy as much space as needed on the underlying file systems, but can become slow to access due to fragmentation. Some older file systems like FAT don't support sparse files. NTFS does.




          2. Initialise the desired file system in the just created file, e. g. ext4:



            mkfs -t ext4 [FS-OPTIONS...] .../partition.img


            The file system initialiser may ask you to confirm to create a file system inside a regular file or may even refuse to do so, unless you set a --force flag or similar.




          3. Create a loop device backed by the partition file and mount it. Reasonably recent versions of mount(8), can do this in one step with the loop option:



            mount -t ext4 -o defaults,loop[,FS-OPTIONS...] .../partition.img /mnt/my-partition


          4. Enjoy!



          Swap partitions




          1. Like step 1 above, but you probably want to avoid the sparse option.



          2. Initialize the swap file:



            mkswap /mnt/internal-drive/some/arbitrary/path/swap.img



          3. Swap-on:



            swapon [OPTIONS...] /mnt/internal-drive/some/arbitrary/path/swap.img



          Block-level encryption



          Just like in the previous sections, regular files can be used pretty much like block devices. So you can use cryptsetup(8), crypttab(5), cryptdisks_start(8) and cryptdisks_stop(8) as you normally would, since they create loop devices for regular files automatically:




          1. Like step 1 in the above sections.



          2. If you want to use LUKS to manage your encrypted partition, initialize it:



            cryptsetup luksFormat .../partition.img [OPTIONS...]



          3. Open the partition with your chosen encryption type and options:



            cryptsetup open .../partition.img <NAME> --type <DEVICE_TYPE> [OPTIONS...]


            Where <NAME> is the name of the dm-crypt mapping to create for the partition and <DEVICE_TYPE> is luks, if you have created a LUKS wrapper in step 2, or plain for a plain dm-crypt partition. (cryptsetup supports other device types, but they're either legacy or for TrueCrypt compatibility.)




          4. The encrypted partition is now available at /dev/mapper/<NAME>.




            • You can create and mount file systems on it like on any block device as outlined in the above sections starting in step 2, or



            • you can create a partition table inside it with your favourite partition manager, if you want to wrap multiple partitions inside it without having to supply the same passphrase multiple times for them individually:



              fdisk /dev/mapper/<NAME>


              Ask the kernel to re-read the partition table and to repopulate the device node files in /dev:



              partprobe /dev/mapper/<NAME>


              You now have the individual partitions available at /dev/mapper/<NAME>1 and so forth.






          Mounting at boot



          You can create fstab (and crypttab) entries for theses partitions just like you would normally, but with the loop option like above. File-based swap spaces don't need special mount options. You just need to take care to mount the underlying filesystem on the internal drive before these new partitions. E. g.:



          LABEL=Windows    /mnt/internal-drive    ntfs    defaults    0  2
          /mnt/internal-drive/some/arbitrary/path/home.img /home ext4 defaults,loop 0 3
          /mnt/internal-drive/some/arbitrary/path/swap.bin none swap sw 0 0


          Destroying the file system afterwards



          Short version: Don't! Use encryption and destroy the key.



          Long version: Overwriting or "shredding" of individual files works under the assumption, that the file never occupied other drive sectors than it currently does (e. g. because the file system or one of its maintenance tools (e. g. de-fragmentation) decided to relocate them) and that no file data ever leaks into file system meta-data section (e. g. like during journalling). These assumptions may hold under most circumstances for older, non-journalling file systems (FAT, ext2). For NTFS, ext3/4 and HFS+ they don't hold reliably except under rare, impractical/unrealistic conditions.



          You can go as far as to overwrite all unallocated sectors in addition to the sector currently occupied by the drive image file. Microsoft's cipher.exe can do this for NTFS, which supposedly catches almost all sectors, that may still contain left-overs of your precious file system image.






          share|improve this answer





















          • 1





            Wonderful! That was the answer I waited for for over two months. :D Unfortunately my personal use case has faded away - but it's great to know how it would be done when I need that once again. Thanks very much.

            – Byte Commander
            Oct 23 '15 at 11:03






          • 1





            What you might add if you have time is how to create encrypted partitions instead and how to safely shred them from the host machine's disk later.

            – Byte Commander
            Oct 23 '15 at 11:05











          • Oh yeah, I forgot about encryption, since that's basically the same as for block devices. I'll add that in a moment.

            – David Foerster
            Oct 24 '15 at 10:15











          • @DavidFoerster : WOW - BRILLIANT - if I could give +10 I would - so only +1 ... keep up your good work ! :)

            – cl-netbox
            Oct 30 '15 at 17:24














          8












          8








          8







          Regular file systems





          1. Create a file on the existing file system on the internal drive of the computer (probably NTFS) for each (encrypted) partition, that you want to create, assuming the internal file system is mounted at /mnt/internal-drive and 1 GiB as the desired size of the resulting partition:



            head -c 1G < /dev/zero > /mnt/internal-drive/some/arbitrary/path/partition.img


            If you want a nice progress indicator you can use pv:



            head -c 1G < /dev/zero | pv -s 1g -pterab > .../partition.img


            If you want to create a partition based on a sparse file instead, use truncate(1) with the --size (shorthand: -s) option to specify the size in bytes:



            truncate -s 1073741824 .../partition.img


            Sparse files are fast to create and only occupy as much space as needed on the underlying file systems, but can become slow to access due to fragmentation. Some older file systems like FAT don't support sparse files. NTFS does.




          2. Initialise the desired file system in the just created file, e. g. ext4:



            mkfs -t ext4 [FS-OPTIONS...] .../partition.img


            The file system initialiser may ask you to confirm to create a file system inside a regular file or may even refuse to do so, unless you set a --force flag or similar.




          3. Create a loop device backed by the partition file and mount it. Reasonably recent versions of mount(8), can do this in one step with the loop option:



            mount -t ext4 -o defaults,loop[,FS-OPTIONS...] .../partition.img /mnt/my-partition


          4. Enjoy!



          Swap partitions




          1. Like step 1 above, but you probably want to avoid the sparse option.



          2. Initialize the swap file:



            mkswap /mnt/internal-drive/some/arbitrary/path/swap.img



          3. Swap-on:



            swapon [OPTIONS...] /mnt/internal-drive/some/arbitrary/path/swap.img



          Block-level encryption



          Just like in the previous sections, regular files can be used pretty much like block devices. So you can use cryptsetup(8), crypttab(5), cryptdisks_start(8) and cryptdisks_stop(8) as you normally would, since they create loop devices for regular files automatically:




          1. Like step 1 in the above sections.



          2. If you want to use LUKS to manage your encrypted partition, initialize it:



            cryptsetup luksFormat .../partition.img [OPTIONS...]



          3. Open the partition with your chosen encryption type and options:



            cryptsetup open .../partition.img <NAME> --type <DEVICE_TYPE> [OPTIONS...]


            Where <NAME> is the name of the dm-crypt mapping to create for the partition and <DEVICE_TYPE> is luks, if you have created a LUKS wrapper in step 2, or plain for a plain dm-crypt partition. (cryptsetup supports other device types, but they're either legacy or for TrueCrypt compatibility.)




          4. The encrypted partition is now available at /dev/mapper/<NAME>.




            • You can create and mount file systems on it like on any block device as outlined in the above sections starting in step 2, or



            • you can create a partition table inside it with your favourite partition manager, if you want to wrap multiple partitions inside it without having to supply the same passphrase multiple times for them individually:



              fdisk /dev/mapper/<NAME>


              Ask the kernel to re-read the partition table and to repopulate the device node files in /dev:



              partprobe /dev/mapper/<NAME>


              You now have the individual partitions available at /dev/mapper/<NAME>1 and so forth.






          Mounting at boot



          You can create fstab (and crypttab) entries for theses partitions just like you would normally, but with the loop option like above. File-based swap spaces don't need special mount options. You just need to take care to mount the underlying filesystem on the internal drive before these new partitions. E. g.:



          LABEL=Windows    /mnt/internal-drive    ntfs    defaults    0  2
          /mnt/internal-drive/some/arbitrary/path/home.img /home ext4 defaults,loop 0 3
          /mnt/internal-drive/some/arbitrary/path/swap.bin none swap sw 0 0


          Destroying the file system afterwards



          Short version: Don't! Use encryption and destroy the key.



          Long version: Overwriting or "shredding" of individual files works under the assumption, that the file never occupied other drive sectors than it currently does (e. g. because the file system or one of its maintenance tools (e. g. de-fragmentation) decided to relocate them) and that no file data ever leaks into file system meta-data section (e. g. like during journalling). These assumptions may hold under most circumstances for older, non-journalling file systems (FAT, ext2). For NTFS, ext3/4 and HFS+ they don't hold reliably except under rare, impractical/unrealistic conditions.



          You can go as far as to overwrite all unallocated sectors in addition to the sector currently occupied by the drive image file. Microsoft's cipher.exe can do this for NTFS, which supposedly catches almost all sectors, that may still contain left-overs of your precious file system image.






          share|improve this answer















          Regular file systems





          1. Create a file on the existing file system on the internal drive of the computer (probably NTFS) for each (encrypted) partition, that you want to create, assuming the internal file system is mounted at /mnt/internal-drive and 1 GiB as the desired size of the resulting partition:



            head -c 1G < /dev/zero > /mnt/internal-drive/some/arbitrary/path/partition.img


            If you want a nice progress indicator you can use pv:



            head -c 1G < /dev/zero | pv -s 1g -pterab > .../partition.img


            If you want to create a partition based on a sparse file instead, use truncate(1) with the --size (shorthand: -s) option to specify the size in bytes:



            truncate -s 1073741824 .../partition.img


            Sparse files are fast to create and only occupy as much space as needed on the underlying file systems, but can become slow to access due to fragmentation. Some older file systems like FAT don't support sparse files. NTFS does.




          2. Initialise the desired file system in the just created file, e. g. ext4:



            mkfs -t ext4 [FS-OPTIONS...] .../partition.img


            The file system initialiser may ask you to confirm to create a file system inside a regular file or may even refuse to do so, unless you set a --force flag or similar.




          3. Create a loop device backed by the partition file and mount it. Reasonably recent versions of mount(8), can do this in one step with the loop option:



            mount -t ext4 -o defaults,loop[,FS-OPTIONS...] .../partition.img /mnt/my-partition


          4. Enjoy!



          Swap partitions




          1. Like step 1 above, but you probably want to avoid the sparse option.



          2. Initialize the swap file:



            mkswap /mnt/internal-drive/some/arbitrary/path/swap.img



          3. Swap-on:



            swapon [OPTIONS...] /mnt/internal-drive/some/arbitrary/path/swap.img



          Block-level encryption



          Just like in the previous sections, regular files can be used pretty much like block devices. So you can use cryptsetup(8), crypttab(5), cryptdisks_start(8) and cryptdisks_stop(8) as you normally would, since they create loop devices for regular files automatically:




          1. Like step 1 in the above sections.



          2. If you want to use LUKS to manage your encrypted partition, initialize it:



            cryptsetup luksFormat .../partition.img [OPTIONS...]



          3. Open the partition with your chosen encryption type and options:



            cryptsetup open .../partition.img <NAME> --type <DEVICE_TYPE> [OPTIONS...]


            Where <NAME> is the name of the dm-crypt mapping to create for the partition and <DEVICE_TYPE> is luks, if you have created a LUKS wrapper in step 2, or plain for a plain dm-crypt partition. (cryptsetup supports other device types, but they're either legacy or for TrueCrypt compatibility.)




          4. The encrypted partition is now available at /dev/mapper/<NAME>.




            • You can create and mount file systems on it like on any block device as outlined in the above sections starting in step 2, or



            • you can create a partition table inside it with your favourite partition manager, if you want to wrap multiple partitions inside it without having to supply the same passphrase multiple times for them individually:



              fdisk /dev/mapper/<NAME>


              Ask the kernel to re-read the partition table and to repopulate the device node files in /dev:



              partprobe /dev/mapper/<NAME>


              You now have the individual partitions available at /dev/mapper/<NAME>1 and so forth.






          Mounting at boot



          You can create fstab (and crypttab) entries for theses partitions just like you would normally, but with the loop option like above. File-based swap spaces don't need special mount options. You just need to take care to mount the underlying filesystem on the internal drive before these new partitions. E. g.:



          LABEL=Windows    /mnt/internal-drive    ntfs    defaults    0  2
          /mnt/internal-drive/some/arbitrary/path/home.img /home ext4 defaults,loop 0 3
          /mnt/internal-drive/some/arbitrary/path/swap.bin none swap sw 0 0


          Destroying the file system afterwards



          Short version: Don't! Use encryption and destroy the key.



          Long version: Overwriting or "shredding" of individual files works under the assumption, that the file never occupied other drive sectors than it currently does (e. g. because the file system or one of its maintenance tools (e. g. de-fragmentation) decided to relocate them) and that no file data ever leaks into file system meta-data section (e. g. like during journalling). These assumptions may hold under most circumstances for older, non-journalling file systems (FAT, ext2). For NTFS, ext3/4 and HFS+ they don't hold reliably except under rare, impractical/unrealistic conditions.



          You can go as far as to overwrite all unallocated sectors in addition to the sector currently occupied by the drive image file. Microsoft's cipher.exe can do this for NTFS, which supposedly catches almost all sectors, that may still contain left-overs of your precious file system image.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Jan 6 at 20:13

























          answered Oct 23 '15 at 10:47









          David FoersterDavid Foerster

          27.9k1364110




          27.9k1364110








          • 1





            Wonderful! That was the answer I waited for for over two months. :D Unfortunately my personal use case has faded away - but it's great to know how it would be done when I need that once again. Thanks very much.

            – Byte Commander
            Oct 23 '15 at 11:03






          • 1





            What you might add if you have time is how to create encrypted partitions instead and how to safely shred them from the host machine's disk later.

            – Byte Commander
            Oct 23 '15 at 11:05











          • Oh yeah, I forgot about encryption, since that's basically the same as for block devices. I'll add that in a moment.

            – David Foerster
            Oct 24 '15 at 10:15











          • @DavidFoerster : WOW - BRILLIANT - if I could give +10 I would - so only +1 ... keep up your good work ! :)

            – cl-netbox
            Oct 30 '15 at 17:24














          • 1





            Wonderful! That was the answer I waited for for over two months. :D Unfortunately my personal use case has faded away - but it's great to know how it would be done when I need that once again. Thanks very much.

            – Byte Commander
            Oct 23 '15 at 11:03






          • 1





            What you might add if you have time is how to create encrypted partitions instead and how to safely shred them from the host machine's disk later.

            – Byte Commander
            Oct 23 '15 at 11:05











          • Oh yeah, I forgot about encryption, since that's basically the same as for block devices. I'll add that in a moment.

            – David Foerster
            Oct 24 '15 at 10:15











          • @DavidFoerster : WOW - BRILLIANT - if I could give +10 I would - so only +1 ... keep up your good work ! :)

            – cl-netbox
            Oct 30 '15 at 17:24








          1




          1





          Wonderful! That was the answer I waited for for over two months. :D Unfortunately my personal use case has faded away - but it's great to know how it would be done when I need that once again. Thanks very much.

          – Byte Commander
          Oct 23 '15 at 11:03





          Wonderful! That was the answer I waited for for over two months. :D Unfortunately my personal use case has faded away - but it's great to know how it would be done when I need that once again. Thanks very much.

          – Byte Commander
          Oct 23 '15 at 11:03




          1




          1





          What you might add if you have time is how to create encrypted partitions instead and how to safely shred them from the host machine's disk later.

          – Byte Commander
          Oct 23 '15 at 11:05





          What you might add if you have time is how to create encrypted partitions instead and how to safely shred them from the host machine's disk later.

          – Byte Commander
          Oct 23 '15 at 11:05













          Oh yeah, I forgot about encryption, since that's basically the same as for block devices. I'll add that in a moment.

          – David Foerster
          Oct 24 '15 at 10:15





          Oh yeah, I forgot about encryption, since that's basically the same as for block devices. I'll add that in a moment.

          – David Foerster
          Oct 24 '15 at 10:15













          @DavidFoerster : WOW - BRILLIANT - if I could give +10 I would - so only +1 ... keep up your good work ! :)

          – cl-netbox
          Oct 30 '15 at 17:24





          @DavidFoerster : WOW - BRILLIANT - if I could give +10 I would - so only +1 ... keep up your good work ! :)

          – cl-netbox
          Oct 30 '15 at 17:24


















          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%2f659911%2fportable-ubuntu-with-ability-to-create-mount-and-remove-without-traces-encrypte%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

          Human spaceflight

          Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

          張江高科駅