Does turnkey fileserver supports NTFS write (on SAMBA shares) out of the box

I don't use NTFS on any of my server systems and when mounted under a Linux desktop, all (Linux) users have full read/write access (ie it ignores existing Windows file permissions). AFAIK you can't apply Linux file permissions to an NTFS volume (although you'd need to test that to confirm) so all users will have full read/write (and delete) permissions.

Through experience I have noticed that if an NTFS volume is not cleanly unmounted (ie you just turn the PC off without properly shutting down or you remove the USB cable without unmounting the filesystem first) then often the drive will be flagged as 'dirty'. Drives with non-native Linux filesystem flagged as  being 'dirty' filesystem will be mounted read only (until you run chkdsk - under Windows). This can be overridden but it isn't advised if you want to maintain data integrity. Perhaps that is your problem?

If you wish to be able to just plug in and unplug the USB (without unmounting) then I suggest you use a native Linux filesystem for the drive or perhaps FAT (but I haven't tried it).

Because NTFS is a propriety FS the Linux support is not 100% reliable (although in fairness it's pretty good IMO). FAT works well in my experience but it's pretty limited (in that without journaling recovery can be limited) and it doesn't support large files. AFAIK it's propriety too (although perhaps opened now?) but has been around long enough that Linux support is as good as you'd need. IMO ext4 is a great filesystem but Windows support is very poor - there is a ext2 driver which works fine with XP and seems to generally work ok with ext3/4 too but can cause corruption and I wouldn't recommend mounting ext3/4 FSs as read/write (read only is fine). As for support with more recent Win OSs I don't even know if there is a driver available. It would be great if someone wrote a driver for Vista/7 but I guess all the Linux geeks with the knowhow are using Linux and so don't want/need support for their drives in Win.

Basically your setup sounds fair and reasonable but you'll just have to get in the habit of unmounting your USB HDD(s) prior to unplugging it(/them) - to avoid risk of corruption. I think that you can unmount drives via Webmin (although I haven't checked) and doing it via the commandline is pretty easy too.

Just in case you're interested, unmounting from the commandline:

Check where your USB is mounted (you probably know already but just in case) using the mount command. This example is from my netbook (which runs Bodhi Linux) but the OS is similar enough that it should be relevant.  I have replaced the irrelevant results from mount with '...' (I have lots of stuff mounted so don't want to confuse you):

mount
...
/dev/sdb1 on /media/MULTIBOOT type vfat (rw,nosuid,nodev,uhelper=udisks,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,flush)

My (FAT formatted) USB is mounted as /media/MULTIBOOT. Usually drives will be mounted in /media and yours should be easily identified as it will be an NTFS FS (ie from memory mount will report 'type NTFS' or something similar).

You could use grep to limit the results, assuming my memory is correct something like this will return just the NTFS drives:

mount|grep NTFS

Anyway, once you know where the USB is mounted, and assuming it's mounted in /media, unmounting it is as simple as:

umount /media/USB-volume-name

In my case:

umount /media/MULTIBOOT

Obviously it will fail if something is trying to read/write to the drive and remember file locations will be case sensative! To check that the FS has successfully unmounted you can run mount again.

Generally your device will auto mount to the same place everytime - assuming that the volume names remain the same and are different between the USB drives. That will mean that you shouldn't need to run mount everytiime to check (although probably worth it the first few times to ensure it is being mounted in the same spot). Also to make the typing easier use the <Tab> key for autocomplete, so to run the above command I type:

umo<Tab><space>/m<Tab>/M<Tab><Enter>
Easy!

Yeah I guess thats pretty much the usual answer I get from everyone running a *nix based NAS.

In my case I am running a 4TB+ media collection from two connected USB harddisks to be connected to the home media players (XBMC and Network Media Tank). My primary operating system is Windows 7 for most of the media management and moving tasks with an obvious choice of NTFS as the de facto filesystem.

It happens quite so often that even NTFS-3g make some mess of the media files when moved/copied over the network to the NAS connected harddisks. In such cases I usually have the Windows based CHKDSK to recue when I connect the harddisk directly to the PC for checking, or for even sharing media for faster copy times then NAS based 4MB/s copy.

If I use any other filesystem and due to any reason any filesystem based corruptions occurs on the NAS drives I would not be able to recover or restore lost data remaining in Windows environment and of course I know "fsck" is there, but I am not an expert in Linux CLI nor do I know how reliably it works.

Well my peronsal preference for a case I have, anyone else could be using it in the native linux flavours.

Thanks.