hardware = sun cobalt raq550 server
OS = strongbolt (Centos 4.8)

I'm running a program on my raq550 called orkaudio that records ip phone calls and generates it's own folder tree to store the .wav recordings. The folder tree it generates goes like this /calls/2009/12/11/20...etc, which stands for year-2009/ December / 11th /20:00 hours...you get the picture. I created the 'calls' folder and the orkaudio program generates the '2009' folder and onwards. I've installed samba and I'm trying to access the recordings on another pc over the network, but I keep getting 'access denied'. The config of the orkaudio program has been set to create folders that are available to 'public'.
Here is the text of my smb.conf.
--------------
[global]
workgroup = workgroup
netbios name = DOCS_SRV
security = share
interfaces = lo eth0 172.16.1.43/16
hosts allow = 172.16.1.14 127.0.0.1

[data]
comment = raq550
path = /home/sites/mydomain.com/web/calls
read only = Yes
public = Yes
---------------

172.16.1.14 is the pc that's trying to access the .wav files over the network. I've tried lots of variations and always restart samba but when I try view the folders from another pc over the network the '2009' folder gives 'access denied'. I can view the .wav recordings via telnet, and I can also see them if I ftp into the server but not over the network. Thanks for any help.

Have you run smbpasswd?

Make sure that the account specified for "GUEST ACCOUNT" is defined in the password file. The default guest account is "nobody".

The file access permissions will depend on what account is used to access the DOCS_SRV share. For example, if no user name and password is specified then the GUEST ACCOUNT will be used (usually "nobody"). If someone logs in using "ted" with their password then they have the access permissions granted to "ted". In order for "ted" to log in to SAMBA the "ted" account has to be added using smbpasswd.

What owner and group is orkaudio setting for the directories and files? You can use "ls -l" to find out. Users must be granted permission to read the files, and traverse (execute) the directories in order to access the files. The group permissions are usually the best way to grant access to multiple users. If a user is not the owner of the files and not a member of the group owning the files, then they get the access permissions of "O" (other or world). You can set O=rx permissions but that will allow anyone to access the files when they log in to the shell as well as when they use SAMBA.

You can control the group for files and directories in a few different ways.

• Set the SETGID bit for the directory
• Primary group of user creating the files
• Use "chown" after the files or directories are created

If you set the group for a directory and also set the SETGID bit then all directories and files created in that directory will inherit the group. Directories will also inherit the SETGID bit.

For example, to make a directory called "mp3s" assign the group "music" to any new directories or files you can do this.

chown :music /mp3s
chmod g+s /mp3s

That does not change the group or permissions of any existing directories or files, only new ones that are created.

The permissions for the group are NOT inherited and those depend on the "umask" setting for the account creating the files. The default for group permissions is usually "rx".

When the SETGID bit is not set for a directory, then the group is set to the primary group for the account creating the files.

You can use "chown" to set the group of directories and files. You either have to be root, or you have to both own the directories/files and belong to the group being set.

You can't set the group of files that you don't own. You can't set a file to a group unless you also belong to that group. Of course the root account has neither of those restrictions.

To give users access to the files, you can make those users members of the group. It does not have to be their primary group.

You can also make ALL users accessing a SAMBA share temporarily be members of a group using this option.

FORCE GROUP = +groupname

The "+" is really only important if users can create files. Adding "+" means that the user's primary group will not be set to "groupname" unless they also belong to "groupname". All users will temporarily belong to "groupname" when accessing files through the share. Only users permanently in that group can create files owned by the group. Without the "+" any files created by any users will be owned by the group.

If you are going to use "FORCE GROUP" then I recommend not using "groupname" for anything else except access to the files. It's usually better to just add users to the group in the normal way instead of using "FORCE GROUP" in "smb.conf".

I generally try to use each group name for only one specific purpose and then add users to the groups as necessary. I use the SETGID bit when I want to force group ownership since a user can only belong to one primary group. The SETGID bit works with all the groups even if the user creating the file doesn't belong to the group.