Created attachment 7710 [details] smb.conf example file for samba 3.6.6 I have a Samba 3.6.6 installation. This problem occurs: 1) An user creates an image file, FILE.PSD; 2) A second user opens the file FILE.PSD; 3) The first user can't edit the file anymore. In this installation, all is forced to user "arquivos" with permission 770. At Linux, I'm using ext3 without acl. There's no special unix permission, no ACL, but samba deny the file access from first user to the file. I've added "nt acl support = false" to smb.conf, but no result. I'm unable to identify at samba logs why the file is blocked: I can't find information about the problem. This Samba uses LDAP to auth users. The "net groupmap list" output for this samba installation: Account Operators (S-1-5-21-2455266176-1594837443-3197790934-548) -> Account Operators Administrators (S-1-5-21-2455266176-1594837443-3197790934-544) -> Administrators Backup Operators (S-1-5-21-2455266176-1594837443-3197790934-551) -> Backup Operators Domain Admins (S-1-5-21-2455266176-1594837443-3197790934-512) -> Domain Admins Domain Computers (S-1-5-21-2455266176-1594837443-3197790934-515) -> Domain Computers Domain Guests (S-1-5-21-2455266176-1594837443-3197790934-514) -> Domain Guests Domain Users (S-1-5-21-2455266176-1594837443-3197790934-513) -> Domain Users Print Operators (S-1-5-21-2455266176-1594837443-3197790934-550) -> Print Operators Replicators (S-1-5-21-2455266176-1594837443-3197790934-552) -> Replicators
I'm running now Samba 3.6.7. The problem persists. At shares I'm using: oplocks = False level2 oplocks = False locking = no strict locking = no blocking locks = no Now Samba locks the file and, when the process terminate at server, the file is REMOVED. Then, I'm loosing files, especially if they are large, when the locks occurs with frequence. I'm not certainly about how happens... the frequency is with .PSD photoshop files, but can occurs with other files sporadically, but it's difficult predict. While using Adobe Photoshop, if at least 2 people opens the same file, the file still locked, and remains inacessible and, now, is removed after the first time the locked message occurs. At Adobe Photoshop, I see the message I have no permission to access the file. After this, when the file is removed after the process ends at server, It's possible save again. If I forget save the file, it's lost. I don't know how to measure the time, but I'm certainly if the second opens when the first is opened (and this can be seconds of difference), the bug happens. But happened in times I don't understood yet. If the first client disconnects, the file still locked forever. To don't lost the file, I can copy at server with another name, for example... The same happens if the first machine is shut down... Please let me know how can I post here better backtraces or some additional information. Samba is making me loose important data, and I need solve this as fast I can.
This looks like expected behaviour of share modes to me. Reopen it if behaviour of windows is any different.
(In reply to comment #2) > This looks like expected behaviour of share modes to me. Reopen it if > behaviour of windows is any different. I'm reopening and editing the report title. The previous title wasn't clear about the real problem. All shares are with the default option (share modes = yes) and, when 2 users open files, the file is silently removed without ask the user about this. There are data loss. And the file can be locked for days, even the second user try change it and be removed. This is not a normal behavior. This happens with frequency as larger are the files.
In order to investigate we need an isolated, reproducible test environment using only 2 clients (to demonstrate files being deleted incorrectly). Please set that up and describe exactly how this is done. Also attach debug level 10 logs from the 2 smbd servers (one for each of the 2 clients) and also full network capture traces on tcp port 445 from each client to the server. Without this there isn't enough data to do anything with this bug report. Jeremy.
no feedback, closing.