On Wed, 31 Aug 2011 17:35:39 -0400 Tim Lank <timlank@xxxxxxxxxxx> wrote: > On Wed, Aug 31, 2011 at 3:41 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > On Wed, 31 Aug 2011 14:55:26 -0400 > > Tim Lank <timlank@xxxxxxxxxxx> 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 <timlank@xxxxxxxxxxx> 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 <jlayton@xxxxxxxxxx> > > > > 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. > In that case, none of what I said above applies :) This sounds like a server implementation issue. If the server doesn't support this call, then there's not much you can do other than report it to them as a bug and plan to ignore it. > 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. > There isn't much, mostly you need to set up krb5 on the client, and then set up cifs.upcall to be called when the kernel requests a key (see the cifs.upcall manpage for details on that). After that it should "just work". That said, it's not likely to help this specific problem... -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
