Hi, I set up a few shares a while ago. I use these under both windows and linux. The problem I have relates to usage on a linux box. The smb.conf for the share in question reads:

I mount this on my Fedora box as:

I have had problems writing to files in the past and worked around this by making mods on the server. Which is not very healthy going forward!

The problem is quite simple:

1. I mkdir a directory under the /mnt/doco folder. Let's call this /mnt/doco/coding
2. I open an existing file in a directory under my /home (I use geany for editing)
3. I save this file into /mnt/doco/coding
4. I make changes and save. All good
5. I compile. All good
6. I try to run and things go wrong
7. Then I start to panic.

I saw a post on here recently about samba privileges but I can't find it. Basically, do I need to add some hooks either in the smb.conf file or at mount time to give me access to new files created?

Cheers

guest ok (S)
If this parameter is yes for a service, then no password is required to connect to the service. Privileges will be those of the guest account.
valid users (S)
This is a list of users that should be allowed to login to this service
create mask (S)
When a file is created, the necessary permissions are calculated according to the mapping from DOS modes to UNIX permissions, and the resulting UNIX mode is then bit-wise 'AND'ed with this parameter. This parameter may be thought of as a bit-wise MASK for the UNIX modes of a file. Any bit not set here will be removed from the modes set on a file when it is created....New in Samba 4.0.0. This mask is applied whenever permissions are changed on a file. To allow clients full control over permission changes it should be set to 0777.

According to this settings you will be mapped to guest and execute permission is removed, and not allowed to restore.

1 members found this post helpful.

thanks pan64. Your explanation on the mapping of permissions (execute permission is removed, and not allowed to restore) explains my predicament and also why I can read/write office docs with no fuss. The solution in this instance is to create a new share for coding where I can build executables.

Cheers

Unfortunately I am reopening this as I am not getting very far. I set up a new share:

Restart smb/nmb and I mount this on my fedora box (fstab entry)

Then:

but the file is created

I copy a file from my home area into the share and the privileges change:

I think I am confused about privileges between the samba server and my PC...I specified a mask of 777 so everyone should be able to read, write, execute. Is that right? However, I am losing group privileges when I copy to the share. Basically, when I create a file in the share, on my Fedora box I want it to be writeable and executable from the Fedora box. Are there any other setting I need to add to smb.conf?

thanks

I think the problem is related to user ids, somehow they are not properly configured. You can see used ids instead of user names.
touch aaa created the file but it was immediately owned by someone else and you will have no write access any more. So can you please tell us some details about the users (tim, coding, doco, 503, 506) on both hosts.

Hi,

tim is the account I use to login at the client end (petunia).

coding (506) is the owner of the share in question on the server. Set up with:

doco (503) is the owner of the doco share (/home/doco). I don't have any records on how this was set up.

So when the client mounts the coding share it uses the coding login to verify with the server. However, tim is logged in to the client and there is no coding login on the client.

Cheers

try to chmod 777 on /mnt/coding/aaa
what is your umask settings

my umask is 002. I recreated the aaa file and tried chmod. From my user this did not work, from root it worked.

So the file is created under the user coding (506) while I am logged on as tim. Do I need to include something in smb.conf to open up access to the tim user/group?

Cheers

probably force create mode can help you

Hi pan64, I tried that as well but no joy. I have set up a VirtualBox PC to play around with this problem. The first share I created had exactly the same problem.

From the posts you have made so far I can see that this is a problem relating to ownership conflicts between the share and the host computer. I guess I need to dig deeper to find a solution to this. If/when I come up with a solution I will post it here.

Thanks

okay, looks like I am in business now. First of all I will have to go back on my last post as I added "force create mode = 777" & "force directory mode = 777" and I can read, write & x. The other thing I came across which will not have been evident from any of my posts is that I was using the share name [shared] for all my shares! Changing this to [coding] could also have helped to solve this:

anyway, thanks for all the help. I will mark this one as solved in a day or 2 unless something else goes wrong

Cheers