On Wed, Aug 31, 2011 at 3:41 PM, Jeff Layton <[email protected]> wrote:
> On Wed, 31 Aug 2011 14:55:26 -0400 > Tim Lank <[email protected]> wrote: > > > the mount.cifs is from (cifs-utils-4.8.1-2.el6.x86_64) > > > > > > On Tue, Aug 30, 2011 at 8:05 PM, Tim Lank <[email protected]> wrote: > > > > > I've got a share from a Unisys MCP Mainframe mounted with mount.cifs > from > > > RHEL 6.1 (samba-common-3.5.6-86.el6.x86_64). > > > > > > when I try to touch a file, it creates the file, but reports an error - > > > "setting times of `testfile.txt': Permission denied" > > > > > > strace on the touch command shows that it is erroring out on the > > > utimensat() call > > > > > > utimensat(0, NULL, NULL, 0) = -1 EACCES (Permission denied) > > > > > > Documentation from the Unisys Mainframe can be found here.... > > > > > > > http://public.support.unisys.com/aseries/docs/clearpath-mcp-12.0/pdf/70118328-103.pdf > > > Pages: C-2 and C3 show what POSIX functions are/not supported > > > utime() and utimensat() are not among the supported functions listed > there. > > > > > > > > > Is there any combination of parameters to mount.cifs that can be used > that > > > would prevent touch from reporting this error? > > > > > > > > > > > (cc'ing linux-cifs ml) > > Most likely, this is a local (unix) permissions issue. CIFS has a rather > unintuitive permissions model. It attempts to enforce permissions > locally, but doesn't really have enough information to do so properly. > This leads to these sorts of problems. > > When you create files as a particular user, then they end up being > owned by the "default" file owner on the mount rather than the user > that just created the file. Then when you go to set the time, the > kernel tries to enforce the permissions on the file and denies you > access to do so. This varies somewhat depending on whether CIFS posix > extensions are in force, but it's a common problem. > > The best scheme is to switch the mount to being multiuser, but that > requires a kerberized setup at the moment. > > Another workaround is to mount with '-o noperm' which disables local > permissions checking entirely. This will however allow any process on > the box to read and write to the server using the mount credentials. > > Another idea is to get creative with the uid=,gid=,file_mode=, and > dir_mode= options. See the mount.cifs manpage. If you're careful, you > can craft a set of options that will allow the users you want to have > proper access without opening everything up. > > My SambaXP talk from last year covers a lot of this in detail if you're > interested.... > > http://sambaxp.org/index.php?id=38 > > Good luck! > -- > Jeff Layton <[email protected]> > Jeff, Thanks for all the info. A wireshark analysis shows that the Mainframe here is returning a frame that shows that the file is created and granted exclusive open for writing. The file actually gets created on the Mainframe (presumably because of the combination of my uid=,gid=,file_mode=, and dir_mode= options) and I can modify it from all users on the mount.cifs box. The next request is from the mount.cifs box to modify "Created, Last Access, Last Write, and Change" timestamp attributes for the (already) opened file. The response frame from the Mainframe is a basic "Access Denied" message which I suppose the touch command turns into a "setting times of" ... Permission Denied message being returned. I'd like to try and get a kerberized setup going with mount.cifs. I see the sec=krb5 option, but is there a series of other config steps that I need to perform (modifying /etc/krb5.conf for example). Supposedly the Mainframe already has kerberos mapping setup for all the users on our mount.cifs system. Any references (besides the mount.cifs manpage) that you can provide that walk through the kerberized setup would be appreciated. Thanks, Tim -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
