Bug in smbmount?

[Urban Widmark]

On Thu, 6 Jul 2000, Christopher K. Johnson wrote:

> > Does specifying a mask for directories and files help?
> >
> > mount -t smbfs -o
> > username=mylinuxuser,password=something,uid=myntuser,dmask=0755,fmask=0755
> > //ntserver/myshare /mnt/test
> 
> I tried dmask=755 and it still forces 555 on the mount point.

Ok.

If you take a look at samba-2.0.7/source/client/smbmnt.c you can see that
it does:

        mount_fmask = umask(0);
        umask(mount_fmask);
        mount_fmask = ~mount_fmask;

... /* parse arguments here -> mount_fmask & mount_dmask */

        data.file_mode = (S_IRWXU|S_IRWXG|S_IRWXO) & mount_fmask;
        data.dir_mode  = (S_IRWXU|S_IRWXG|S_IRWXO) & mount_dmask;

        if (mount_dmask == 0) {
                data.dir_mode = data.file_mode;
                if ((data.dir_mode & S_IRUSR) != 0)
                        data.dir_mode |= S_IXUSR;
                if ((data.dir_mode & S_IRGRP) != 0)
                        data.dir_mode |= S_IXGRP;
                if ((data.dir_mode & S_IROTH) != 0)
                        data.dir_mode |= S_IXOTH;
        }

'data' is then passed to smbfs in the mount call. One thing to check is
that the modes are ok here (please do).


> More key info:
> The directories and files subordinate to the mount point are writeable.  i.e
[snip]
> Furthermore immediately below this smbmount in the same script is another one
> 
> for a samba share from a linux server and the mount point in this case has
> correct permissions:

Hmm, that makes it a little different. If things below the mountpoint are
ok it is perhaps just the root inode that is setup wrong.

The things involved in setting up the root inode are these routines in
smbfs:

smb_read_super (fs/smbfs/inode.c)
  - called with the data struct at mount time
smb_init_root_dirent (fs/smbfs/proc.c)
smb_init_dirent
smb_finish_dirent
  - sets this: fattr->f_mode = server->mnt->dir_mode
    (dir_mode would be the same value as smbmnt passes)
  - checks readonly flag (fattr->attr & aRONLY) and adjusts fmode. I don't
    see how that could be set, initially.
smb_iget (fs/smbfs/inode.c)
  - creates the inode for the filesystem root
    (only copies f_mode set earlier)

A few printk's here would show how the initial inode gets the mode set
(and that the data passed from the smbmnt wasn't "corrupted" somehow).
I can send you a patch with things I believe are interesting, if you want
to. But it may be so that it is setup ok and then later changed (that is
of course also possible to track).


That it works with a samba server could be interpreted as something with
how permissions are mapped, or some other communication thing that
smbclient gets right and smbfs gets wrong.

I don't have an NT4 to test with right now, but I have used it a lot and
never seen this so it doesn't always happen. How are the permissions set
on the share?

A simple thing to test might be to make a new share for testing and play
with permissions on that one. (full access - everyone, should work ...)

/Urban