I have a Linux file server. I am using SAMBA 3 as a domain controller.

I want to set up SAMBA shares on the file server that do not have to be accessed from Windows machines via either UNC notation or by separate mapped drives.

Instead, I want to have a share on the Linux server called Public that is accessible to all network users from any Windows machine. Within that share I want all users to be able to open, edit, and create any files or folders, EXCEPT certain specific folders.

For certain specific folders within the Public share, I want access controlled by a SAMBA valid users list, with the user names validated by the domain controller.

In other words:

/Public/ (any Windows user can see it, put things into it, etc.) Folder 1 (anybody can see it and open it and do anything inside it.) Folder 2 (anybody... ditto...) Folder 3 (access restricted to valid users) Folder 4 (anybody can ... etc.) Folder 5 (access restricted to valid users)

I've tried a number of things, none of which work.

Right now there's a share on the server called /data/. The only SAMBA command for that share is:

writeable = yes

All of the shares that people actually interact with are inside /data/. They all have permissions set as 777 for root, group, and Others in Nautilus. Some of them also have SAMBA valid users lists, which effectively override the file system permissions, UNLESS I put the share inside one of the other shares, in this case, /Public/.

There isn't anything unusual about /Public/ compared to the other shares as regards either file system permissions or SAMBA commands.

If I create a share called /Foo/ inside /Public/ and apply a valid users list, then if somebody not on the list on a Windows machine issues \SERVER\Foo, they are asked for credentials. However, if they issue \SERVER\Public, then try to open \Foo from there, they are allowed in.

I also don't fully understand the force create mode and force directory mode commands, or the create mask command, so any help in showing how those things can affect his would be great.

I don't want to do veto files; it hides the folder and again requires either UNC or mapped drive access.

I tried to use dont descend but I can't seem to make it work at all.

I realize that the Windows and Linux file systems are both implicated here, and they behave differently with regard to permissions, but it just seems to me that this is such a simple thing that there has to be a way to make it work.

This situation cannot be affected by setting folder permissions in Windows, I either get "access denied" (for folders created in Linux), or Windows appears to let me make changes but they don't have any effect (for folders created on the Linux server from Windows).

To summarize:

The way it is today:

/data/ /data/Public/ (UNC or mapping required; no valid user list; anybody can see and get into) /data/Another Share/ (UNC or mapping required; valid domain user list controls access) /data/Third Share/ (UNC or mapping required; different valid domain user list controls access) /data/Public/Some Share/ (even though there's a valid user list, any users coming through /Public/ can get in; users not on the list coming directly through a UNC or mapped drive cannot)

The way I want it is:

/data/ /data/Public/ (UNC or mapping required; no valid user list; anybody can see and get into) /data/Public/Another Share/ (Once in Public, valid domain user list controls access) /data/Public/Third Share/ (Once in Public, different valid domain user list controls access) /data/Public/Anything Else (Once in Public, anybody can see and get into)

I want to continue to use the domain to validate credentials, I don't want to have to create separate user accounts and access groups on the file server.

Thanks for any suggestions.

Ken Dibble www.stic-cil.org