smbfs

TheLinuxRevolution · 12-23-2005, 01:48 PM

Greetings, I'm hoping someone can help...

I have a Slackware 10.2 server running Samba 3.0.20b. When I mount a share with
"mount -t smbfs -o username=user,pass=pass,fmask=777,dmask=777 //server/share /mount/point" (on another 10.2 PC) the mount completes successfully.

Logged in as a user, I can access the mount point and create files and
directories in the root of the mount point. I can also cd into the directories I've created.

But, I cannot create additional files or directories within the directories I created. My problem is that I cannot create anything within subdirectories on my Samba smbmount filesystem while running as a normal user. Creating files and directories within the root of the mount point (as a normal user) works fine.

Logged in as root, I can create subdirectories and subfolders to my heart's content.

Please, if anyone has any ideas on what to do / try, please reply!

Thank you in advance,
John
samba1@thelinuxrevolution.net

Emerson · 12-23-2005, 09:07 PM

NFS is the natural way to share volumes between UNIX computers. In case you have Windows boxes on your LAN, keep Samba running. Just export the very same directory via NFS for *nix boxes.

jschiwal · 12-23-2005, 11:23 PM

You have the permissions for new files masked out.

From the info page for "umask":

Quote:

14.9.7 Assigning File Permissions
---------------------------------

The primitive functions for creating files (for example, `open' or
`mkdir') take a MODE argument, which specifies the file permissions to
give the newly created file. This mode is modified by the process's
"file creation mask", or "umask", before it is used.

The bits that are set in the file creation mask identify permissions
that are always to be disabled for newly created files. For example, if
you set all the "other" access bits in the mask, then newly created
files are not accessible at all to processes in the "other" category,
even if the MODE argument passed to the create function would permit
such access. In other words, the file creation mask is the complement
of the ordinary access permissions you want to grant.

From the man 8 mount manpage:

Quote:

dmask=value
Set the umask applied to directories only. The default is the
umask of the current process. The value is given in octal.

fmask=value
Set the umask applied to regular files only. The default is the
umask of the current process. The value is given in octal.

fmask and dmask are similar to umask, but allow you to set different default permissions for files than for directories. For a world writable network share, it is common to not set the execution bit for files. However, for directories, the "x" bit serves a different purpose. It allows directories to be entered, so you want to have the "x" bit se]t for directories. In other words, it is overloaded.

Also, check that the username/password that your server uses matches your mount command entries.
The [i]man 8 smbpasswd[/i man-page can give you more information on adding users and changing passwords.
Much depends on how samba is configured. You may need to have phony accounts on the server that matches the users on the remote machines.

centauricw · 12-23-2005, 11:43 PM

This is not correct for smbmount, which is what mount uses for SMB file shares:

From the smbmount man page:

Quote:

fmask=<arg>

sets the file mask. This determines the permissions that remote files have in the local filesystem. This is not a umask, but the actual permissions for the files. The default is based on the current umask.

dmask=<arg>

Sets the directory mask. This determines the permissions that remote directories have in the local filesystem. This is not a umask, but the actual permissions for the directories. The default is based on the current umask.

The other thing to keep in mind is that Samba obeys the Linux file permissions. If the regular user can't create files in the subdirectory from the shell, they won't be able to do it from Samba either. Setting the dmask and fmask options on the mount command doesn't change this.

jschiwal · 12-27-2005, 12:12 PM

I stand corrected. Sorry for any confusion caused.