samba - Apr 2004 - How to share WIN partitions from SAMBA (Dual boot) Srvr to WIN clients?

Hi all. I am a pretty new user, but I now have two networked PC's, with
LINUX (current Slackware distro, kernel 2.4.22?) with dual boot with WINXP
(Prof),  and a networked WINXP (Home) client machine.
Here is my problem, stated as succinctly as possible:
"To state it in one sentence, what must one do to enable a WIN(XP) client
box to access WIN(XP) partitions on another  machine that is running UNIX
(Linux) with SAMBA? "
Recall that many folks (well, me anyway), have a machine with two (or more)
OS's, and might want to access the data on BOTH OS's.
Detailed discussion:
Win to Winn we have worked with for years..enable the directory for sharing,
give it a share name, and it can be browsed, and optionally mapped as a
network drive.
1)Now, On UNIX, you can MOUNT another file system, including , say, a WIN
partition (C: and D: in my case) to some mount point(s) on the UNIX file
system, and that box can easily read that local WIN data. Good
2)With SMB (SAMBA), I can  MOUNT the WIN data of that remote client. I use
MOUNT -t SMBFS, or SMBMOUNT command (which invokes the former, under the
hood). So I can access remote WIN data from UNIX. Good.
3) From the client, I can NET USE the UNIX shares defined on the UNIX box,
having defined such shares - using SAMBA - in the SMB.CONF file. So, from
WIN,  I can access remote UNIX partitions/data. Good.
4)And the last step, the problem? How can this client access WIN data on the
LINUX server? Not Linux data (3, above), but the WIN partitions, those that
the LOCAL box may (or may not have) have mounted for local use such as in 1)
above. When I define the path of the WIN share in the SMB.CONF file (the
path being the file system that was MOUNTED in 1) above...such as /dev/hda2,
or /mnt/hd/c...I have used both syntaxes)), I CAN access it on the remote
box, but it is empty!!!!!! the ls command shows 0 files!!!

I am missing something fundamental here...or am trying to do the
impossible......
I have sweated over this for 3 days now, I have looked at all the HOWTO"S,
etc...I need guidance from more experienced folks.
 Finally , booting LINUX mounts the NTFS file systems (from fstab file),
with a warning "W2K+, Read Only". I thought write to NTFS was possible
thru
SAMBA. Again, I must be missing something. SMB.CONF file appears to be
correct, defining the shares as writeable, etc....

What am I missing?
Thanks
George Peters

>  Finally , booting LINUX mounts the NTFS file systems (from fstab file),
> with a warning "W2K+, Read Only". 
Correct.  The ntfs filesystem on linux is still very early, and writing to
an NTFS volume will cause it to be damaged unless what+how you write is
carefully restricted.  For your purposes, it's useless for writing.
> I thought write to NTFS was possible thru SAMBA.
No.  All Samba does is allow remote clients to mount UNIX-accessible volumes
via SMB/CIFS.  These may be Windows, UNIX, or even MacOS (X|Classic) clients.
 
> Again, I must be missing something. SMB.CONF file appears to be
> correct, defining the shares as writeable, etc....
Samba can't even exceed the capabilities of the native operating system
under which it's running.

With or without samba, you cannot get Linux to (safely) write to NTFS
volumes on its local filesystems.

If what you're trying to do is re-export a mounted share via the samba
server, that will probably work, but you will cause a great deal of
redundant network traffic, and the performance will tank.

(In other words, you mount some remote WinXP share via smbmount, and then
use samba to share that volume...)

Good luck,

=R=

[Replying to list]

Quoting George Peters <wombat53@optonline.net>:
> Malcolm - thanks for the prompt reply.
> I don't think I am trying to share a remote smbmounted file. Rather, I
> AM trying to share a LOCAL  (and presumably MOUNTed) WIN partition.
OK.
> Why am I doing this? On my home network, the WIN client runs WIN apps 
> like MS OUTLOOK that share one common OUTLOOK data file (one user at a 
> time) with my "server" WINXP machine. I want to have this box in
Linux
> mode (not WIN).
You don't have many options then.

1) If you're stuck with using NTFS, you can only use read-only mode. Make
your smb.conf share those as read-only [you can enable fake oplocks on the
read-only shares for extra speed w/o risks].  You will need to mount the
share as ro.  Make sure you change the /mnt directory permissions to allow
browsing (+rx).

2) If you can reformat the partition to use FAT32 (note: despite Win2k's
protestations at FORMATTING a FAT32 larger than 32GB, the format DOES
support up to 127GB.  There are replacement tools for Win32 (which are
essentially ports of the Linux mkdosfs) to format FAT32's > 32GB.  Google
for them.
> How can I make it available? Is it even possible? I am prepared to
> forget about the Read-only constraint.
Sure it's possible.  It's very simple and straightforward.  Samba will
cheerfully share that read-only NTFS volume for you.

Cheers,
=MB=

> Malcolm
> Perhaps I am getting near the end ...)of this process, of my rope, or
> both)
Uh-oh.
> I ensured the fstab reeferenced the NTFS partitions as ro (read only)
Please zip up your /etc/fstab file and email this to me.
> I ensured  my smb.conF to declare the WIN shares as browseable=yes, and
> read only = yes.
You've restarted smbd since changing the smb.conf file?
> Paths are /mnt/hd/c and d, respectively, corresponding to
> two DOS/WIN partitions C: and D: (/dev/hda2 and /dev/hda5)
Both of these are mounted?

Paste the output of

cat /etc/mtab in an email to me.
> I chmod the actual /mnt directory to Octal 555 (r_x), and the
> sub-directories also.
> Both Linux Server and WIN client can access the shares, but there are no
> files there ...ls command returns nothing. That is my problem.
The ls command under which environment? The local Samba server's? (logged in
via SSH or console?)   

Firstly, please verify you can see the files from the SAMBA server locally,
i.e., login to its console or via SSH, and perform an ls /mnt/hd/c and make
sure you see the files there.

It's also possible that the file permissions the ntfs driver is passing back
are too restrictive.

Aha.  This is your problem.  I just peeked at the ntfs section of mount:

Mount options for ntfs:
[...]
   uid=value, gid=value and umask=value
   Set  the  file  permission on the filesystem.  The umask value is given
in octal.  By default, the files are owned by root and not readable by 
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
somebody else.
^^^^^^^^^^^^^^

In the options section of /etc/fstab for the two NTFS volumes, you will want
the following options:

uid=desired-uid-to-own-the-files,gid=desired-group-number,umask=770

So something like: 

/dev/hda2      /mnt/hd/c    ntfs   ro,uid=1000,gid=100,umask=770  0   0
/dev/hda5      /mnt/hd/d    ntfs   ro,uid=1000,gid=100,umask=770  0   0

Should do the trick.  Replace uid/gid with whatever values you deem
pertinent.  Keep in mind that ntfs permissions will be disregarded for the
most part [from a user/group perspective].

=MB=