Under normal usage of a Windows app, temporary files can be created on a Samba NAS share but once created, the same user cannot delete or modify those files - unless they wait 'overnight'.
The temporary files have a name of
~$blah.blah (with a leading tilde and dollar-sign) and these files contain the user's Windows/Samba ID inside. The app being used is SolidWorks but I've seen forum posts that the
~$ filename designation appears also with Office apps as if a Windows file-locking API automatically creates the ~$ files. These temporary files will also appear on the user's local drive when using the local drive as a work-space but users have no problems with these local files. The problem appears when using the Samba NAS share as a work-space. This problem first appears when attempting to save the file - the app indicates that the files cannot be saved unless renamed.
FileExplorer can see the files but can't delete, rename or modify the offending files even after stopping the Windows app and even after rebooting the client computer. If the user waits till the next morning, then they can delete them. The only change that I can see that occurred overnight is that smbstatus gives different results - it shows this when the file cannot be deleted:
28085 1005 DENY_NONE 0x82 WRONLY NONE /OurSambaShare OurProjectDirectory/~$blah.blah Wed Jan 20 12:01:44 2016
When the file CAN be deleted, smbstatus shows no entry for the offending files.
Over on the Posix/Linux side, a user can modify (move, rename, delete etc) the offending files which implies that this is not a posix permissions or acl problem. Also, the posix/acl permissions didn't change overnight. This user can use Notepad to create, modify and save files in the same share and the posix permissions are the same as the offending files. These posix permissions are: -
rwxrwx--x+ 1 root users
Also getfacl shows that the user has
rwx permissions for the files and their directory.
How can I configure Samba to allow users to modify (or delete) files that they've created?
Why does Samba seem to relinquish these offending files overnight?
Samba version: smbstatus --version says: Version 3.4.3-1.32.1-2591-SUSE-CODE11
Excerpts from smb.conf
[global] workgroup = OurWorkgroup passdb backend = tdbsam printing = cups printcap name = cups printcap cache time = 750 cups options = raw map to guest = Bad User logon path = \\%L\profiles\.msprofile logon home = \\%L\%U\.9xprofile logon drive = P: usershare allow guests = Yes add machine script = /usr/sbin/useradd -c Machine -d /var/lib/nobody -s /bin/false %m$ domain logons = No domain master = No security = user wins support = Yes encrypt passwords = YES smb passwd file = /etc/samba/smbpasswd dos filemode = Yes [users] comment = All users path = /home read only = No inherit acls = Yes veto files = /aquota.user/groups/shares/ nt acl support = yes [shared] comment = OurSambaShare inherit acls = Yes inherit permissions = Yes inherit owner = Yes path = /OurShare read only = No force group = users force create mode = 775 nt acl support = yes