Sponsored Content
Operating Systems Linux Red Hat Can not change timestamp on directory inside cifs mount Post 302519892 by Create on Thursday 5th of May 2011 10:15:30 AM
Old 05-05-2011
Can not change timestamp on directory inside cifs mount

Greetings,

I have an rsync server that is unable to change the timestamp on any directories inside of cifs mounts. The same thing happens on all of my red hat machines. These machines are all patched, touch -t works on directories inside any other filesystem including NFS mounts.

This is causing problems with our rsync process.

It is not a permissions issue as the same cifs mounts/users accounts work on a SUSE machine. Please note that changing the timestamps on files work, it is just a problem with directories.

Code:
[root@blah]# touch -t 200901011212 BLAH/
touch: setting times of `BLAH/': Permission denied
[root@blah]# ls -alh
total 20K
drwxrwxrwx  5 test users    0 May  5 09:47 .
drwxr-xr-x 12 root  root  4.0K Oct  1  2009 ..
drwxrwxrwx  2 test users 4.0K May  5 09:47 BLAH
[root@blah]# touch test
[root@blah]# touch -t 200901011212 test
[root@blah]# ls -al
total 21
drwxrwxrwx  5 test users    0 May  5 09:49 .
drwxr-xr-x 12 root  root  4096 Oct  1  2009 ..
drwxrwxrwx  2 test users 4096 May  5 09:47 BLAH
-rwxrwSrwx  1 test users    0 Jan  1  2009 test

Any help would be appreciated.

Thanks,

Ben

Last edited by pludi; 05-05-2011 at 11:26 AM..
 

10 More Discussions You Might Find Interesting

1. HP-UX

mount with CIFS

hi everyone months ago i installed software on hp-ux box. So instead of going to the server room (which is far and cold :) ), I put the DVD in my windows xp box and mount it using CIFS, it was successful. Now I want to install another software on the same hp-ux box using the same windows... (3 Replies)
Discussion started by: neemoze
3 Replies

2. UNIX for Advanced & Expert Users

mount -t cifs permission denied by mount -t smbfs works fine

I am having trouble mounting with cifs, but mounting the exact same command with smbfs works fine. The share is on another samba server and is set to full public guest access. # mount -t cifs //servername/sharename /mnt/temp -o password="" mount error 13 = Permission denied Refer to the... (3 Replies)
Discussion started by: humbletech99
3 Replies

3. AIX

CIFS Mount not mounting on my AIX server

Dear Experts, Im facing a unique situation. We got a windows server folder cifs mounted on my AIX server. Before restarting the win server I tried unmounting the cifs mount. It got hanged and win server was restarted however. Now Im trying to mount the same. It prompts for password... (3 Replies)
Discussion started by: jayadeava
3 Replies

4. AIX

AIX cifs mount to Windows Server 2008 R2

Hi i have some problem to mount a Windows Server 2008 R2 share on AIX. I found the artikel 157701-aix-cifs-mount-windows-server-2008-share on the Forum (cant post the Link) witch decribe my situation but there is no solution. I can mount a share to a Windows 2003 SP2 Server but not to 2008 R2... (2 Replies)
Discussion started by: MrTee
2 Replies

5. Linux

new file group permission of CIFS mount

After switching from smbfs mount, the dmask/dir_mode and fmask/file_mode no longer have an effect on the newly created files. It seems to use the system umask instead. I need the group to have write permissions without changing the root umask on the system. Any ideas? example fstab: ... (0 Replies)
Discussion started by: gadgetx23
0 Replies

6. Red Hat

Permissions problem with cifs.mount

hi, I have the following permission problems with cifs.mount : a share on a VNXe (EMC NAS) is accessed by two RHEL 5.9 accounts (authenticated by Active Directory); One account has read+wite permission to the share , the second one has only read permission. Both accounts uses the following... (0 Replies)
Discussion started by: Zarake
0 Replies

7. UNIX and Linux Applications

Slackware: mount cifs with kerberos

On Slackware14.0 Compiled cifs-utils with kerberos support on request-key.conf added create cifs.spnego * * /usr/sbin/cifs.upcall %k %d But when i try mount -o sec=krb5 -t cifs //SLACK64//Users /media/users mount error(38): Function not implemented Refer to the... (1 Reply)
Discussion started by: Linusolaradm1
1 Replies

8. AIX

Mount CIFS on AIX

Hello AIX gurus, I am trying to mount a CIFS share on AIX and I could use some help. Here are the environment details: AIX - 6100-05-01-1016 Domain Controller - WIN2K8R2 (authentication takes place here) CIFS share is stored on a NetApp storage array that is joined to the domain I have... (2 Replies)
Discussion started by: jhall
2 Replies

9. AIX

AIX available cifs mount options

Hi, I can't find any documentation of all available mount options of mount -v cifs Unfortunately you can specify any fantasy options, no complains, and the mount command shows this option In particular I want to know if there is a possibility to completely disable cifs caching in aix,... (3 Replies)
Discussion started by: funksen
3 Replies

10. UNIX for Beginners Questions & Answers

Help with cifs/smbfs mount on Solaris

I have a Linux server with a cifsmount, the entry in /etc/fstab looks like this: //windows_server_name/xyz /opt/xyz cifs credentials=/etc/creds/xyz.creds,uid=abc,gid=abc,noserverino,directio,_netdev 0 0 The username and password are stored in /etc/creds/xyz.creds This works fine.:wall: How... (1 Reply)
Discussion started by: Joke Holmer
1 Replies
fakeroot(1)							   Debian manual						       fakeroot(1)

NAME
fakeroot - run a command in an environment faking root privileges for file manipulation SYNOPSIS
fakeroot [-l|--lib library] [--faked faked-binary] [-i load-file] [-s save-file] [-u|--unknown-is-real ] [-b|--fd-base ] [-h|--help ] [-v|--version ] [--] [command] DESCRIPTION
fakeroot runs a command in an environment wherein it appears to have root privileges for file manipulation. This is useful for allowing users to create archives (tar, ar, .deb etc.) with files in them with root permissions/ownership. Without fakeroot one would need to have root privileges to create the constituent files of the archives with the correct permissions and ownership, and then pack them up, or one would have to construct the archives directly, without using the archiver. fakeroot works by replacing the file manipulation library functions (chmod(2), stat(2) etc.) by ones that simulate the effect the real library functions would have had, had the user really been root. These wrapper functions are in a shared library /usr/lib/libfakeroot.so* which is loaded through the LD_PRELOAD mechanism of the dynamic loader. (See ld.so(8)) If you intend to build packages with fakeroot, please try building the fakeroot package first: the "debian/rules build" stage has a few tests (testing mostly for bugs in old fakeroot versions). If those tests fail (for example because you have certain libc5 programs on your system), other packages you build with fakeroot will quite likely fail too, but possibly in much more subtle ways. Also, note that it's best not to do the building of the binaries themselves under fakeroot. Especially configure and friends don't like it when the system suddenly behaves differently from what they expect. (or, they randomly unset some environment variables, some of which fakeroot needs). OPTIONS
-l library, --lib library Specify an alternative wrapper library. --faked binary Specify an alternative binary to use as faked. [--] command Any command you want to be ran as fakeroot. Use '--' if in the command you have other options that may confuse fakeroot's option parsing. -s save-file Save the fakeroot environment to save-file on exit. This file can be used to restore the environment later using -i. However, this file will leak and fakeroot will behave in odd ways unless you leave the files touched inside the fakeroot alone when outside the environment. Still, this can be useful. For example, it can be used with rsync(1) to back up and restore whole directory trees com- plete with user, group and device information without needing to be root. See /usr/share/doc/fakeroot/README.saving for more details. -i load-file Load a fakeroot environment previously saved using -s from load-file. Note that this does not implicitly save the file, use -s as well for that behaviour. Using the same file for both -i and -s in a single fakeroot invocation is safe. -u, --unknown-is-real Use the real ownership of files previously unknown to fakeroot instead of pretending they are owned by root:root. -b fd Specify fd base (TCP mode only). fd is the minimum file descriptor number to use for TCP connections; this may be important to avoid conflicts with the file descriptors used by the programs being run under fakeroot. -h Display help. -v Display version. EXAMPLES
Here is an example session with fakeroot. Notice that inside the fake root environment file manipulation that requires root privileges succeeds, but is not really happening. $ whoami joost $ fakeroot /bin/bash # whoami root # mknod hda3 b 3 1 # ls -ld hda3 brw-r--r-- 1 root root 3, 1 Jul 2 22:58 hda3 # chown joost:root hda3 # ls -ld hda3 brw-r--r-- 1 joost root 3, 1 Jul 2 22:58 hda3 # ls -ld / drwxr-xr-x 20 root root 1024 Jun 17 21:50 / # chown joost:users / # chmod a+w / # ls -ld / drwxrwxrwx 20 joost users 1024 Jun 17 21:50 / # exit $ ls -ld / drwxr-xr-x 20 root root 1024 Jun 17 21:50 // $ ls -ld hda3 -rw-r--r-- 1 joost users 0 Jul 2 22:58 hda3 Only the effects that user joost could do anyway happen for real. fakeroot was specifically written to enable users to create Debian GNU/Linux packages (in the deb(5) format) without giving them root priv- ileges. This can be done by commands like dpkg-buildpackage -rfakeroot or debuild -rfakeroot (actually, -rfakeroot is default in debuild nowadays, so you don't need that argument). SECURITY ASPECTS
fakeroot is a regular, non-setuid program. It does not enhance a user's privileges, or decrease the system's security. FILES
/usr/lib/libfakeroot/libfakeroot.so* The shared library containing the wrapper functions. ENVIRONMENT
FAKEROOTKEY The key used to communicate with the fakeroot daemon. Any program started with the right LD_PRELOAD and a FAKEROOTKEY of a running daemon will automatically connect to that daemon, and have the same "fake" view of the file system's permissions/ownerships. (assuming the daemon and connecting program were started by the same user). LD_LIBRARY_PATH LD_PRELOAD Fakeroot is implemented by wrapping system calls. This is accomplished by setting LD_LIBRARY_PATH=/usr/lib/fakeroot and LD_PRELOAD=libfakeroot.so.0. That library is loaded before the system's C library, and so most of the library functions are inter- cepted by it. If you need to set either LD_LIBRARY_PATH or LD_PRELOAD from within a fakeroot environment, it should be set relative to the given paths, as in LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/foo/bar/ LIMITATIONS
Library versions Every command executed within fakeroot needs to be linked to the same version of the C library as fakeroot itself. open()/create() fakeroot doesn't wrap open(), create(), etc. So, if user joost does either touch foo fakeroot ls -al foo or the other way around, fakeroot touch foo ls -al foo fakeroot has no way of knowing that in the first case, the owner of foo really should be joost while the second case it should have been root. For the Debian packaging, defaulting to giving all "unknown" files uid=gid=0, is always OK. The real way around this is to wrap open() and create(), but that creates other problems, as demonstrated by the libtricks package. This package wrapped many more functions, and tried to do a lot more than fakeroot . It turned out that a minor upgrade of libc (from one where the stat() function didn't use open() to one with a stat() function that did (in some cases) use open()), would cause unexplainable segfaults (that is, the libc6 stat() called the wrapped open(), which would then call the libc6 stat(), etc). Fixing them wasn't all that easy, but once fixed, it was just a matter of time before another function started to use open(), never mind trying to port it to a different operating system. Thus I decided to keep the number of functions wrapped by fakeroot as small as possible, to limit the likelihood of 'collisions'. GNU configure (and other such programs) fakeroot, in effect, is changing the way the system behaves. Programs that probe the system like GNU configure may get confused by this (or if they don't, they may stress fakeroot so much that fakeroot itself becomes confused). So, it's advisable not to run "con- figure" from within fakeroot. As configure should be called in the "debian/rules build" target, running "dpkg-buildpackage -rfake- root" correctly takes care of this. BUGS
It doesn't wrap open(). This isn't bad by itself, but if a program does open("file", O_WRONLY, 000), writes to file "file", closes it, and then again tries to open to read the file, then that open fails, as the mode of the file will be 000. The bug is that if root does the same, open() will succeed, as the file permissions aren't checked at all for root. I choose not to wrap open(), as open() is used by many other functions in libc (also those that are already wrapped), thus creating loops (or possible future loops, when the implementation of various libc functions slightly change). COPYING
fakeroot is distributed under the GNU General Public License. (GPL 2.0 or greater). AUTHORS
joost witteveen <joostje@debian.org> Clint Adams <clint@debian.org> Timo Savola MANUAL PAGE
mostly by J.H.M. Dassen <jdassen@debian.org> Rather a lot mods/additions by joost and Clint. SEE ALSO
faked(1) dpkg-buildpackage(1), debuild(1) /usr/share/doc/fakeroot/DEBUG Debian Project 6 August 2004 fakeroot(1)
All times are GMT -4. The time now is 07:44 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy