DOS was never intended to be a multiuser, networked operating system. Unix, on the other hand, was designed that way from the start. Consequently, there are inconsistencies and gaps in coverage between the two filesystems that Samba must not only be aware of, but also provide solutions for. One of the biggest gaps is how Unix and DOS handle permissions with files.
Let's take a look at how Unix assigns permissions. All Unix files have read, write, and execute bits for three classifications of users: owner, group, and world. These permissions can be seen at the extreme left-hand side when a
ls
-al command is issued in a Unix directory. For example:
-rwxr--r-- 1 tom users 2014 Apr 13 14:11 access.conf
Windows, on the other hand, has four principal bits that it uses with any file: read-only, system, hidden, and archive. You can view these bits by right-clicking on the file and choosing the Properties menu item. You should see a dialog similar to
Figure 5.6.[]
The definition of each of those bits follows:
- Read-only
-
The file's contents can be read by a user but cannot be written to.
- System
-
This file has a specific purpose required by the operating system.
- Hidden
-
This file has been marked to be invisible to the user, unless the operating systems is explicitly set to show it.
- Archive
-
This file has been touched since the last DOS backup was performed on it.
Note that there is no bit to specify that a file is executable. DOS and Windows NT filesystems identify executable files by giving them the extensions .EXE, .COM, .CMD, or .BAT.
Consequently, there is no use for any of the three Unix executable bits that are present on a file in a Samba disk share. DOS files, however, have their own attributes that need to be preserved when they are stored in a Unix environment: the archive, system, and hidden bits. Samba can preserve these bits by reusing the executable permission bits of the file on the Unix side - if it is instructed to do so. Mapping these bits, however, has an unfortunate side-effect: if a Windows user stores a file in a Samba share, and you view it on Unix with the
ls
-al command, some of the executable bits won't mean what you'd expect them to.
Three Samba options decide whether the bits are mapped:
map
archive,
map
system , and
map
hidden. These options map the archive, system, and hidden attributes to the owner, group, and world execute bits of the file, respectively. You can add these options to the
[data] share, setting each of their values as follows:
[data]
path = /home/samba/data
browseable = yes
guest ok = yes
writeable = yes
map archive = yes
map system = yes
map hidden = yes
After that, try creating a file in the share under Unix - such as
hello.java - and change the permissions of the file to 755. With these Samba options set, you should be able to check the permissions on the Windows side and see that each of the three values has been checked in the Properties dialog box. What about the read-only attribute? By default, Samba 2.0 sets this whenever a file does not have the Unix owner write permission bit set. In other words, you can set this bit by changing the permissions of the file to 555.
We should warn you that the default value of the
map
archive option is
yes, while the other two options have a default value of
no. This is because many programs do not work properly if the archive bit is not stored correctly for DOS and Windows files. The system and hidden attributes, however, are not critical for a program's operation and are left to the discretion of the administrator.
Figure 5.7 summarizes the Unix permission bits and illustrates how Samba maps those bits to DOS attributes. Note that the group read/write and world read/write bits do not directly translate to a DOS attribute, but they still retain their original Unix definitions on the Samba server.
