How to mount partition with ntfs file system

* Purpose of Title step by step guide of, how to mount partition with NTFS file system on the Linux operating system. This title having two parts:)
* mount NTFS file system read only access
* mount NTFS file system with read write access

Mount NTFS file system with read only access
2.1. NTFS kernel support

Majority of current Linux distributions supports NTFS file system out of the box. To be more specific, support for NTFS file system is more feature of Linux kernel modules rather than Linux distributions. First verify if we have NTFS modules installed on our system.

# ls /lib/modules/2.6.18-5-686/kernel/fs/ | grep ntfs

check for NTFS kernel support


NTFS module is presented. Let's identify NTFS partition.
2.2. Identifying partition with NTFS file system

One simple way to identify NTFS partition is:

fdisk -l | grep NTFS

Identifying partition with NTFS file system

There it is: /dev/sdbX
2.3. Mount NTFS partition

First create a mount point:

mkdir /mnt/windows

Then simply use mount command to mount it:

mount -t ntfs /dev/sdb1 /mnt/windows

Mount NTFS partition using linux
Now we can access NTFS partition and its files with read write access.

Mount NTFS file system with read write access

Mounting NTFS file system with read write access permissions is a bit more complicated. This involves installation of addition software such as fuse and ntfs-3g. In both cases you probably need to use your package management tool such as yum, apt-get, synaptic etc.. and install it from your standard distribution repository. Check for packages ntfs-3g and fuse. We take the other path which consists of manual compilation and installation fuse and ntfs-3g from source code.
3.1. Install addition software
3.1.1. Fuse Install

Download source code from: http://fuse.sourceforge.net/

# wget http://easynews.dl.sourceforge.net/sourceforge/fuse/fuse-2.7.1.tar.gz

Compile and install fuse source code:
Extract source file:

# tar xzf fuse-2.7.1.tar.gz

Compile and install

# cd fuse-2.7.1
./configure --exec-prefix=/; make; make install

Compile and install fuse source code
3.1.2. ntfs-3g install

Download source code from: http://www.ntfs-3g.org/index.html#download

# wget http://www.ntfs-3g.org/ntfs-3g-1.1120.tgz

Extract source file:

# tar xzf ntfs-3g-1.1120.tgz

Compile and install ntfs-3g source code
NOTE: Make sure that you have pkg-config package installed, otherwise you get this error message:

checking for pkg-config... no
checking for FUSE_MODULE... configure: error: FUSE >= 2.6.0 was not found. Either it's not fully
installed (e.g. fuse, fuse-utils, libfuse, libfuse2, libfuse-dev, etc packages) or files from an old
version are still present. See FUSE at http://fuse.sf.net/

# cd ntfs-3g-1.1120
./configure; make; make install

Compile and install ntfs-3g source code
3.2. Mount ntfs partition with read write access

# mount -t ntfs-3g /dev/sdb1 /mnt/windows

NOTE: ntfs-3g recommends to have at least kernel version 2.6.20 and higher.

# mount -t ntfs-3g /dev/sdb1 /mnt/windows
WARNING: Deficient Linux kernel detected. Some driver features are
not available (swap file on NTFS, boot from NTFS by LILO), and
unmount is not safe unless it's made sure the ntfs-3g process
naturally terminates after calling 'umount'. If you wish this
message to disappear then you should upgrade to at least kernel
version 2.6.20, or request help from your distribution to fix
the kernel problem. The below web page has more information:
http://ntfs-3g.org/support.html#fuse26

==================================================================================

How To recover deleted files using 'rm -rf' command in ext3fs

Let's jump into mini-user guide to recover a deleted file from ext3FS.
I'm having a file called 'giis.txt'
$ls -il giis.txt
15 -rw-rw-r-- 2 root root 20 Apr 17 12:08 giis.txt

note: "-il" option displays the files inode number.(which is 15)

And it's contents are :
$ cat giis.txt
this is giis file
Now i'm going to delete that file.
$rm giis.txt
rm: remove write-protected regular file `giis.txt'? y

Using Journal and Inode number

Remember if the system is reboot the journal entries will be lost. So you can recover a file from Journal as long as system is /NOT/ shutdown or restarted.

Recovering from journal using file Inode number

Since we know that giis.txt files inode number is 15,use that debugfs.

debugfs: logdump -i <15>
FS block 1006 logged at sequence 404351, journal block 7241
(inode block for inode 15):
Inode: 15 Type: regular Mode: 0664 Flags: 0x0 Generation: 0
User: 0 Group: 0 Size: 20
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x48159f2d -- Mon Apr 28 15:25:57 2008
atime: 0x48159f27 -- Mon Apr 28 15:25:51 2008
mtime: 0x4806f070 -- Thu Apr 17 12:08:40 2008
Blocks: (0+1): 10234
No magic number at block 7247: end of journal.

Look carefully you can see the line
Blocks: (0+1): 10234
That's the address (data block) where the content of inode 15 is stored.
So now we know the block address too.
Then what are you waiting for?Go ahead and just use dd commad to extract data from that address.(block number)
dd if=/dev/sda5 of=/opt/giis_R/txt bs=4096 count=1 skip= 10234
1+0 records in
1+0 records out
if refers to input device.
of refers to output device.
bs refers to block size.
count indicates 'how many no.of blocks you want to dump?'[we need only one block]
skip tells to skip 10234 blocks from start and dump the next block.
Now let's check the content of the txt file
$cat txt
this is giis file

Yes....we got it :-)

Ok..we recovered a file based on it's inode number. I know what's in your mind,
"Is it possible to recover a file if we don't know it's inode number?" yes...it's a very good question.Actually you can recover...but how?
Using Journal and Filename

So you want to know about how to recover a file ,if we don't know it's inode number????
Sadly that's not possible.You should know the file's inode number.Yes.I can hear you saying "How to remeber file's inode number?".It's simple run ls -i command and it will display inode number and filename.Some thing like below output
4243207 133708_id 3698526 inotify-tools-3.12
3698256 133708.tgz 4373821 ipc.pdf
3698265 16px-Feed-icon.svg.png 3767366 james
3698357 5-Oct-2001.ppt 4373815 journal-api.pdf
3762755 apache_sh 3698376 JSJr
3697893 arabia 3762748 kamal
3697869 bach 3700575 Kernel book-Daniel P. Bovet. Marco Cesati
3697836 bach.zip 3698675 lan.html
3697971 bb 3698427 lecture23.ppt
3764000 cartMail.php 3703871 Lin
2678038 childshell 3697802 link to payment
3701078 cms-fixes 3893379 linux-cmd.txt

Can you see the number in front of file names ?.They are inode numbers :)
Read the list 10 times loudly and just memorize it ;-)
Just kidding ;-)..No one can remember inode number of all files...huhhh...relaxed now?
then how to recover a file if we don't know it's inode number????Sadly that's not possible... :-) [back to line number1.It's an recursive doc :-) ]

Let's start exploring.
I'm deleting a file called exthide2.txt.
$rm exthide2.txt
rm: remove write-protected regular file `exthide2.txt'? y
I don't know it's number.Let's check the debugfs command.
Use debugfs to list files -d option
debugfs: ls -d
2 (12) . 2 (12) .. 11 (20) lost+found 2347777 (20) oss
<2121567> (20) exthide2.txt
you can see the deleted file exthide2.txt it's different from others It's inode number
2121567 is surrounded by < and > . Deleted files inode are surrounded by < and >. Now got a chance to recover the file :-)

So we can use this inode number with logdump:
debugfs: logdump -i <2121567>
Inode 2121567 is at group 65, block 2129985, offset 3840
Journal starts at block 1, transaction 405642
FS block 2129985 logged at sequence 405644, journal block 9
(inode block for inode 2121567):
Inode: 2121567 Type: bad type Mode: 0000 Flags: 0x0 Generation: 0
User: 0 Group: 0 Size: 0
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x00000000 -- Thu Jan 1 05:30:00 1970
atime: 0x00000000 -- Thu Jan 1 05:30:00 1970
mtime: 0x00000000 -- Thu Jan 1 05:30:00 1970
Blocks:
FS block 2129985 logged at sequence 405648, journal block 64
(inode block for inode 2121567):
Inode: 2121567 Type: regular Mode: 0664 Flags: 0x0 Generation: 913772093
User: 100 Group: 0 Size: 31
File ACL: 2130943 Directory ACL: 0
Links: 1 Blockcount: 16
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x4821d5d0 -- Wed May 7 21:46:16 2008
atime: 0x4821d8be -- Wed May 7 21:58:46 2008
mtime: 0x4821d5d0 -- Wed May 7 21:46:16 2008
Blocks: (0+1): 2142216

Let's explore this result carefully.You could see a entry like this -
FS block 2129985 logged at sequence 405644, journal block 9
and it's displayed the type as
Type: bad type
(inode block for inode 2121567):
parse the entries carefully,you can see timestamps and then we reach
Blocks:
nothing is specified against blocks.Let's parse the next journal block:
FS block 2129985 logged at sequence 405648, journal block 64
(inode block for inode 2121567):
yes.here you can see an entry like this :
Blocks: (0+1): 2142216
This data address of deleted file. Let's try and dump data using dd command.
$sudo dd if=/dev/sda5 of=/home/oss/exthide_recovered.txt bs=4096 skip=2142216 count=1
Now see what's in that file -- i'm curious
$ cat exthide_recovered.txt
this is exthide file added now

wow shocking output but that's what we wanted :-) ...now we recovered a file with it's name..
Refresh the steps involved in this process :
1)Find inode number of file using debugfs: ls -d
2)Find data block of inode using debugfs:logdump
3)Finally use data block number with dd command to exact the contents.

======================you are done==================================================