[linux-cifs-client] Re: Re: Re: Re: Re: Timestamps not preservedonCIFS mount

[Eric B.]

"Jeff Layton" <jlayton at redhat.com> wrote in message 
news:20080310161222.104d1393 at tleilax.poochiereds.net...
> On Mon, 10 Mar 2008 15:49:01 -0400
> "Eric B." <ebenze at hotmail.com> wrote:
>
>> "Jeff Layton" <jlayton at redhat.com> wrote in message
>> news:20080310075757.77c135cf at tleilax.poochiereds.net...
>>
>> > > >just some additional thoughts on your problem i forgot
>> > > >to mention.
>> > > >When the samba server on your storage device is not running
>> > > >the cifs "unix extensions", the windows like smb functions
>> > > >are used - so you can probably been hit by the currently
>> > > >failing implementation, too.
>> > > >
>> > > >Btw - many NAS devices (even still sold today) are running
>> > > >samba-2.x.x. I've been told in many places, that users had problems
>> > > >when using cifs vfs - but smbfs was working (for their limited 
>> > > >needs).
>> > >
>> > > Thanks for the info.  I'm actually trying cifs b/c of problems I am
>> > > encountering with smbfs; the timestamps work properly, but I keep
>> > > getting
>> > > error/warning msgs regarding inability to set permissions and/or
>> > > ownership
>> > > of the files.  For example:
>> > > # cp -a /home/eric/deploy /mount/smbfs
>> > > cp: failed to preserve ownership for `./deploy/checksum.sh~': 
>> > > Permission
>> > > denied
>> > > cp: failed to preserve ownership for `./deploy/checksum.sh': 
>> > > Operation
>> > > not
>> > > permitted
>> > > cp: failed to preserve ownership for `./deploy/deploy-dev': Operation
>> > > not
>> > > permitted
>> > >
>> > >
>> > > I also get the same error msgs if I try rsync instead:
>> > > # rsync -a /home/eric/deploy
>> > > rsync: chown "/mount/bashful/cifs/deploy" failed: Operation not
>> > > permitted
>> > > (1)
>> > > rsync: chown "/mount/bashful/cifs/deploy/.checksum.sh.TDQedW" failed:
>> > > Operation not permitted (1)
>> > > rsync: chown "/mount/bashful/cifs/deploy/.checksum.sh~.KZ1wck" 
>> > > failed:
>> > > Permission denied (13)
>> > > rsync: chown "/mount/bashful/cifs/deploy/.deploy-dev.KweNfI" failed:
>> > > Operation not permitted (1)
>> > >
>> > >
>> > > I figured that those probs might be avoided with cifs, and indeed 
>> > > they
>> > > are,
>> > > but am running into the timestamp issue.  If I could resolve the
>> > > ownership /
>> > > chown problem in smbfs, I'd be happy to stick with that as well.
>> > >
>> > > Any ideas where I might be able to find help about that?  Maybe a
>> > > newsgroup
>> > > or mailing list that would be good for smb issues like this?  I was
>> > > hoping
>> > > to find a resolution for the cifs problem here, but that proves to be
>> > > too
>> > > difficult, I'll revert to looking for a smbfs soln instead.
>> > >
>> >
>> > I'd suggest first testing a newer kernel. That one is pretty ancient
>> > by now. The RHEL4.6 kernel contains a much more updated CIFS version
>> > and this may "just work" there. If it still doesn't work with that,
>> > then I'd suggest testing the kernels on my RH people page:
>>
>> Well, the machine that has been causing me all this grief is a production
>> server, so unfortunately I can't just update the kernel and reboot it
>> without proper notice, planning, etc. without causing some significant
>> outages for some users.  However, I do have a spare machine that I 
>> installed
>> CentOS4.6 on and I figured I would run tests there instead.  I have done 
>> a
>> full yum update on the machine, so in theory, everything is up-to-date. 
>> I
>> have even double checked that I had the latest kernel.
>>
>> # uname -a
>> Linux OMG3 2.6.9-67.0.4.ELsmp #1 SMP Sun Feb 3 07:08:57 EST 2008 i686 
>> i686
>> i386 GNU/Linux
>>
>>
>> I am still running into problems.
>> 1) For some reason, mount with the fdqn of my nas does not work.  I have 
>> to
>> use the IP.  Is there a reason for this?  On 2.6.9-34, the fqdn works 
>> fine.
>> Yes - the name is properly resolved (I am able to ping the fqdn), and the
>> dns server is in my /etc/resolv.conf file.  If I try to mount the fqdn, I
>> get errors in my dmesg and /var/log/messages
>> # mount -t cifs //bashful.domain.com/backups  /mount/bashful -o username
>> kernel:  CIFS VFS: cifs_mount failed w/return code = -22
>>
>> The only way I was able to get the mount to work is to use the IP 
>> address.
>> Is this a "feature" of a later CIFS version?
>> # mount -t cifs //192.168.1.10/backups  /mount/bashful -o username
>>
>
> It shouldn't be. Do you also have the samba-client package installed?
> If you don't then you don't have the mount.cifs program and it won't be
> able to resolve the fqdn before mounting. As a quick check...

Dim-witted me.  That's what I get for a fresh install. :)  Forgot to install 
the samba-client pkg.  Actually surprised/impressed that the cifs mount 
worked at all without that.
Installed samba-client and samba-common, and fqdn mounts work as before now. 
Thanks for pointing that out.



>> 2) Once I managed to get the mount up and working, I am running into the
>> same problems I had with my samba share.  Although the timestamp is 
>> properly
>> set this time, I get the same errors setting ownership that I was getting
>> with the smbfs (but not getting in the previous cifs):
>>
>> cp: failed to preserve ownership for `./install.log': Permission denied
>>
>
> This is expected, presuming that you're mounting the share as an
> unprivileged user. Samba will do the file operations on the share as
> that user and won't allow you to change ownership of those files to
> someone else.
>
> If it did otherwise it would be a (huge) security problem, since an
> unprivileged user could potentially chown files to someone else (even
> root).

Good point.  I had figured it was something along those lines, and thought I 
was able to work my way around the problem by mounting it as root, but as 
you aptly pointed out, Samba doesn't care who the user is at the client; 
only the user that is being used to mount the share.  And try as I may, I 
couldn't manage to mount as root; had to use a non-priviledged user.

>> Is there anything that I can do about this?
>>
>
> Not much. I recently converted my home backups to use amazon S3 with a
> program called "duplicity". You could conceivably use something like
> that here and simply write the archive files to the CIFS share instead:
>
> http://duplicity.nongnu.org/

Hmmm - that's an interesting thought.  I will take a closer look at 
duplicity; it definitely seems interesting.  From a cursory look, it 
definitely seems like something of interest.  My biggest concern, of course, 
with things like this is what happens if there is a failure with an 
incremental archive, etc (ie: either corrupt file, etc).  But thanks for the 
pointer.


Eric