在正常使用 Windows 应用程序的情况下，可以在 Samba NAS 共享上创建临时文件，但一旦创建，同一用户就无法删除或修改这些文件 -除非他们等“过夜”。
临时文件的名称为~$blah.blah（带有前导波形符和美元符号），这些文件内部包含用户的 Windows/Samba ID。正在使用的应用程序是 SolidWorks，但我见过论坛帖子，~$文件名指定也出现在 Office 应用程序中，就好像 Windows 文件锁定 API 自动创建 ~$ 文件一样。当使用本地驱动器作为工作空间时，这些临时文件也会出现在用户的本地驱动器上，但用户对这些本地文件没有任何问题。使用 Samba NAS 共享作为工作空间时会出现此问题。当尝试保存文件时，此问题首先出现 - 应用程序指示除非重命名，否则无法保存文件。
FileExplorer 可以查看文件，但无法删除、重命名或修改有问题的文件，即使在停止 Windows 应用程序后甚至重新启动客户端计算机后也是如此。如果用户等到第二天早上， 然后他们能删除它们。我能看到一夜之间发生的唯一变化是 smbstatus 给出了不同的结果 - 当文件无法删除时它会显示这一点：
28085 1005 DENY_NONE 0x82 WRONLY NONE /OurSambaShare OurProjectDirectory/~$blah.blah Wed Jan 20 12:01:44 2016
当文件可以被删除时，smbstatus 不会显示有问题的文件的条目。
在 Posix/Linux 端，用户可以修改（移动、重命名、删除等）有问题的文件，这意味着这不是 posix 权限或 acl 问题。此外，posix/acl 权限也不是一夜之间就改变的。该用户可以使用记事本在同一共享中创建、修改和保存文件，并且 posix 权限与违规文件相同。这些 posix 权限是： - rwxrwx--x+ 1 root users
getfacl 还显示用户具有rwx文件及其目录的权限。
我的问题：
如何配置 Samba 以允许用户修改（或删除）他们创建的文件？
为什么 Samba 似乎一夜之间就放弃了这些有问题的文件？
更多细节：
Samba 版本： smbstatus --version 说：版本 3.4.3-1.32.1-2591-SUSE-CODE11
摘自 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