Samba, CIFS and Deleting Files

Question

So I've got a Samba share located on server A. I have that share mounted to two other servers, B and C. The idea is that B and C need to write temporary files to a single location so that multiple background processing jobs (also running on B and C) have access to the same pool of files.

When the background processes are complete they delete the file they were working on. When I do a directory listing of the share after a file has been deleted the original files names are now along the lines of cifs79, cifs78 etc. They take up the same amount of space as the original file so I assume they are the originals, just renamed.

The problem is these files don't go away unless I restart samba (which I don't plan on ever doing). Am I missing a simple config param that will delete files immediately?

I created my shares with this command:

mount -t cifs //10.251.251.251/uploads ./uploads -o username=samba_user,noexec

The files go into the share as -rw------- and remain that way after they change names.

Here's the full smb.conf file: http://gist.github.com/172474 and the result of running smbstatus: http://gist.github.com/172478

---

More info:

If I manually create a file from the box that has the share mounted, I can create, edit, delete no problem. If I start an IRB (interactive ruby) session, I can use Ruby to create/delete files no problem. It seems to be the app itself which creates the file with strange permissions. Although the app and my IRB session are running as the same user, so they should have the same permissions to do whatever.

Thanks for any help!

Answer 1

Do you have access to the full config for the samba server? I know a common idiom is to configure samba to do something other than delete a file on a command from the server to delete, in order to implement 'trash/recycle bin' style functionality across the network. Renaming the files in the original directory is a little unusual, but its still a possibility.

Answer 2

The R/W column does say RDONLY but in my config I have read only = no

That doesn't mean clients aren't allowed to fopen(file, "r"), i.e. open files read-only, even if they're allowed to write them.

Looks like Samba has to hold on to files that B deletes because A still has an oplock on them. The oplock should expire after not too long, after which samba will probably delete the renamed file.

This is very similar to what NFS does to implement the semantics of fd = open/create temp file delete file use temp file (since you haven't closed it yet) close fd

You get .nfs... files in your directories.

Answer 3

Basicaly i think it is a problem of permissions, the config file seems fine. Have you tried looking at the /var/log/samba/* logs?

About your smb.conf file:

[global]
force create mode = 0644
force directory mode = 0744

0744 isn't a common mode for "force directory mode", probably a typo, usually if you give read permissions to folders you want to give flag the execution bit too, use 755 or 750, or 700. This options makes all folders have at least those bits set. "force create mode" its fine.

[uploads]
create mask = 0655
directory mask = 755

Since you mounting it with noexec, i guess that a correct value for your "create mask" would be 666 or 644 and for "directory mask" would be 755.

I would ssh to the server and run something like this too:

find /tmp/uploads -type f -print0 | xargs -0 chmod 644
find /tmp/uploads -type d -print0 | xargs -0 chmod 755
chown "$SMBUSER:$SMBUSER_GROUP" -r /tmp/uploads/