12.6 Common Errors

File, directory and share access problems are common on the mailing list. The following are examples taken from the mailing list in recent times.

12.6.1 Users Cannot Write to a Public Share

" We are facing some troubles with file/directory permissions. I can log on the domain as admin user (root), and there's a public share on which everyone needs to have permission to create/modify files, but only root can change the file, no one else can. We need to constantly go to the server to chgrp -R users * and chown -R nobody * to allow others users to change the file ".

There are many ways to solve this problem and here are a few hints:

  1. Go to the top of the directory that is shared.

  2. Set the ownership to what ever public owner and group you want

      $ find 'directory_name' -type d -exec chown user.group {}\; $ find 'directory_name' -type d -exec chmod 6775 'directory_name' $ find 'directory_name' -type f -exec chmod 0775 {} \; $ find 'directory_name' -type f - exec chown user.group {}\;  

    N OTE


    The above will set the sticky bit on all directories. Read your UNIX/Linux man page on what that does. It causes the OS to assign to all files created in the directories the ownership of the directory.

  3. Directory is: /foodbar

     $ chown jack.engr /foodbar 

    N OTE


    This is the same as doing:

     $ chown jack /foodbar $ chgrp engr /foodbar 

  4. Now type:

      $ chmod 6775 /foodbar $ ls -al /foodbar/..  

    You should see:

      drwsrwsr-x 2 jack engr 48 2003-02-04 09:55 foodbar  
  5. Now type:

      $ su - jill $ cd /foodbar $ touch Afile $ ls -al  

    You should see that the file Afile created by Jill will have ownership and permissions of Jack, as follows :

      -rw-r--r-- 1 jack engr 0 2003-02-04 09:57 Afile  
  6. Now in your smb.conf for the share add:

       force create mode = 0775   force direcrtory mode = 6775   

    N OTE


    These procedures are needed only if your users are not members of the group you have used. That is if within the OS do not have write permission on the directory.

    An alternative is to set in the smb.conf entry for the share:

      force user = jack   force group = engr  

12.6.2 File Operations Done as root with force user Set

When you have a user in admin users , Samba will always do file operations for this user as root , even if force user has been set.

12.6.3 MS Word with Samba Changes Owner of File

Question: "When user B saves a word document that is owned by user A the updated file is now owned by user B. Why is Samba doing this? How do I fix this? "

Answer: Word does the following when you modify/change a Word document: MS Word creates a NEW document with a temporary name , Word then closes the old document and deletes it, Word then renames the new document to the original document name. There is no mechanism by which Samba can in any way know that the new document really should be owned by the owners of the original file. Samba has no way of knowing that the file will be renamed by MS Word. As far as Samba is able to tell, the file that gets created is a NEW file, not one that the application (Word) is updating.

There is a work-around to solve the permissions problem. That work-around involves understanding how you can manage file system behavior from within the smb.conf file, as well as understanding how UNIX file systems work. Set on the directory in which you are changing Word documents: chmod g+s 'directory_name' This ensures that all files will be created with the group that owns the directory. In smb.conf share declaration section set:

  force create mode = 0660   force directory mode = 0770  

These two settings will ensure that all directories and files that get created in the share will be read/writable by the owner and group set on the directory itself.

Official Samba-3 HOWTO and Reference Guide
The Official Samba-3 HOWTO and Reference Guide, 2nd Edition
ISBN: 0131882228
EAN: 2147483647
Year: 2005
Pages: 297

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net