Opened 14 years ago
Closed 13 years ago
#166 closed defect (fixed)
Cannot delete file in a created directory on the OS/2 share
Reported by: | dmik | Owned by: | Silvan Scherrer |
---|---|---|---|
Priority: | Feedback Pending | Milestone: | Samba Server for eCS (OS/2) 1.1.x |
Component: | Samba Server | Version: | Server 3.3.x |
Keywords: | Cc: |
Description
If I create a directory through a Samba client on an OS/2 share and copy a file to that directory, I cannot delete this file through the client (it may be deleted only locally on the server).
Steps to reproduce:
- Connect to an OS/2 share.
- Create a directory.
- Copy a file to that directory from the local machine or create it from scratch.
- Attempt to delete this file. You will get the "Access denied" ("Permission denied") error.
Change History (8)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
After torturing it with some more similar tests, the server has just failed.
comment:3 by , 14 years ago
By failed I mean that the server stopped responding to client requests so I had to stop/start it.
comment:4 by , 14 years ago
The same happens if I use both the Samba client (Linux, OS/2) and the Sharity client (Linux).
comment:6 by , 14 years ago
Component: | Unknown → Samba Server |
---|---|
Milestone: | → Samba Server for eCS (OS/2) 1.1.0 |
Owner: | changed from | to
Priority: | minor → Feedback Pending |
also a log could help here
comment:7 by , 13 years ago
Just tried this szenario here using Server 1.1.0 (3.3.15) and Client 2.2.beta1 (3.5.11) and I CANNOT reproduce it - everything seems to work normally. We definitely need a logfile.
comment:8 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
With the latest samba 3.3 and my libc064 build which fixes the permission issue on HPFS386, I don't see any problems any longer.
Note that if the directory is first created locally on the server, and then a file is copied to that directory remotely by the samba client, this file can be deleted by the client w/o any problems.
My assumption is that when the OS/2 server creates a directory upon the remote client's request, it somehow screws up kLIBC permission bits for this directory which then will prevent it from performing the remote delete request.