On Mon, 2009-09-21 at 14:03 +0100, John Austin wrote: > Hi > > I have just returned from holiday and updated F11 to latest state > Server Centos 5.3 also updated > > There was no problem afaik before the upgrades !!!! > > My F11 client uses kdm, xfce, evolution ... > and my home directory is an nfs4 mount from the server > > ------------------------------------------------------- > 1. My backup script fails - refusing to copy files of the type > > cp: cannot open `/home/ja/.local/share/applications/defaults.list.3PEP0U' for reading: Permission denied > > naxos ~ 78# ls -l /home/ja/.local/share/applications/defaults.list.I4ZS0U > ---------- 1 ja sysadmin 0 1970-05-08 03:02 /home/ja/.local/share/applications/defaults.list.I4ZS0U > > cp: cannot open `/home/ja/.kde/share/config/kconf_updaterc.lockGuIM8a.tmp' for reading: Permission denied > > naxos ~ 87# ls -l /home/ja/.kde/share/config/kconf_updaterc.lockGuIM8a.tmp > ---------- 1 ja sysadmin 0 1970-02-01 03:34 /home/ja/.kde/share/config/kconf_updaterc.lockGuIM8a.tmp > > ------------------------------------------------------- > > With zero length and 000 permissions > naxos ~ 86# find . -type f -size 0 -perm 000 |grep ".kde/share/config/*" |wc > 11336 11336 532781 > > Even more with just zero length > naxos ~ 84# find . -type f -size 0 |grep ".kde/share/config/*" |wc > 23783 23783 1117791 > > The vast majority of the files are associated with kde ! > naxos ~ 5# ja_null_files_ls |wc -l > 43087 > naxos ~ 6# ja_null_files_ls |grep .kde |wc -l > 43008 > > There are a lot of these files in my home directory! 240,000 at one stage !!!! > They take a very long time to delete > > The dates are strange some being in years 1970 and some 2038 > > ############################################################ > Update > My nfs4 mounted home directory is saved on a SSD disk > with noatime set > Removing the noatime seems to get rid of the 2038 dated file problem > other problems described here are still present > ############################################################ > > Why have these files appeared or have they always been there > If so why does my simple cp now treat them differently > > > 2. Evolution is now having great difficulty in reading/saving/deleting/filtering files > Is this to do with problem 1 ? > Also - when creating new message in evo a box pops up with > Could not save to autosave file "". > Error saving to autosave because "Could not open autosave file". > > 3. Thunar has great difficulty in showing thumbnails > and deselects thumbnails when changing directory > pcmanfm seems to work OK > > Is it a kde, nfs ... problem ? > > Any suggestions welcome > > John > > -------------------------------------------------------------------------- > PS > I have 4 little scripts to investigate with > > For 1970 dated files > naxos ~ 1# cat bin/ja_null_files_ls > #!/bin/bash > find $HOME -type f -size 0 -mtime +10000 -print0 | xargs -0 ls -l > -------------------------------------------------------------- > For 2038 dated files > naxos ~ 2# cat bin/ja_null_files_ls_future > #!/bin/bash > find $HOME -type f -size 0 -newermt "2030-02-01" -print0 | xargs -0 ls -l > -------------------------------------------------------------- > Second pair of scripts have rm instead of ls -l > -------------------------------------------------------------- > naxos ~ 9# ja_null_files_ls |less > ---------- 1 ja sysadmin 0 1970-04-13 14:24 /home/ja/.evolution/.evolution-composer.autosave-3Q3D0U > ---S--srw- 1 ja sysadmin 0 1970-04-11 04:20 /home/ja/.evolution/.evolution-composer.autosave-ATZC0U > ---------- 1 ja sysadmin 0 1970-04-18 16:02 /home/ja/.evolution/.evolution-composer.autosave-DFFE0U > ---S--srw- 1 ja sysadmin 0 1970-04-19 08:56 /home/ja/.evolution/.evolution-composer.autosave-EKHJ0U > ---------- 1 ja sysadmin 0 1970-04-12 14:56 /home/ja/.evolution/.evolution-composer.autosave-GPAN0U > ---------- 1 ja sysadmin 0 1970-04-17 22:57 /home/ja/.evolution/.evolution-composer.autosave-GUYR0U > ---------- 1 ja sysadmin 0 1970-04-11 21:30 /home/ja/.evolution/.evolution-composer.autosave-GWOH0U > ---S--srw- 1 ja sysadmin 0 1970-04-20 01:59 /home/ja/.evolution/.evolution-composer.autosave-JXSW0U > ---S--srw- 1 ja sysadmin 0 1970-04-15 01:59 /home/ja/.evolution/.evolution-composer.autosave-OAMW0U > ---S--srw- 1 ja sysadmin 0 1970-04-14 07:59 /home/ja/.evolution/.evolution-composer.autosave-QAJS0U > ---S--srw- 1 ja sysadmin 0 1970-04-17 05:51 /home/ja/.evolution/.evolution-composer.autosave-RTTF0U > ---------- 1 ja sysadmin 0 1970-04-16 12:45 /home/ja/.evolution/.evolution-composer.autosave-S9ZU0U > ---S--srw- 1 ja sysadmin 0 1970-04-15 19:31 /home/ja/.evolution/.evolution-composer.autosave-ZYQT0U > ---------- 1 ja sysadmin 0 1970-01-14 17:26 /home/ja/.kde/share/config/kconf_updaterc06fevc.new > ---------- 1 ja sysadmin 0 1970-01-14 22:22 /home/ja/.kde/share/config/kconf_updaterc0A5kOa.new > ---------- 1 ja sysadmin 0 1970-01-18 12:39 /home/ja/.kde/share/config/kconf_updaterc0EZsJa.new > --w-rw---x 1 ja sysadmin 0 1970-01-14 22:15 /home/ja/.kde/share/config/kconf_updaterc0I2gOa.new > -r--rwx-wx 1 ja sysadmin 0 1970-01-18 14:51 /home/ja/.kde/share/config/kconf_updaterc0Ii9Yb.new > ---xrwx-wx 1 ja sysadmin 0 1970-01-13 17:19 /home/ja/.kde/share/config/kconf_updaterc0JJLgc.new > ... > Problem not solved but "worked round" The heart of the problem is that fully updated F11 and/or Centos 5.3 versions of nfs4 do not seem to work correctly. They used to !!!! After chasing many red herrings I discovered a simple cp /tmp/file /global/dir where /global is an nfs4 mount does not work consistently 1. If the user does have permission to create the file It usually fails saying it cannot create the file because of permission problems However it creates a zero length file, with a variety of permissions set as seen above. However it sometimes copies the file correctly !!!! This was observed on one particular occasion with Thunar where some of the thumbnails were created and some not. 2. If the user does not have permission to create the file No problem - no zero length file created 3. Root works too, the file is copied OK and belongs to root:root Switching back to nfs3 mounts avoids the problems and all is well ------------------------------------------------------------- Has anyone seen anything similar? Has anyone any suggestions as to where my nfs4 configuration could be wrong ? The two lines used nfs3/nfs4 are shown below (I use NIS to distribute the files) maui.jaa.org.uk ~ 6# cat /etc/auto.home * -fstype=nfs 148.197.29.5:/exports/home/& #* -fstype=nfs4,rsize=32768,wsize=32768 148.197.29.5:/home/& maui.jaa.org.uk ~ 7# cat /etc/auto.direct /global -fstype=nfs 148.197.29.5:/exports/global #/global -fstype=nfs4,rsize=32768,wsize=32768 148.197.29.5:/global Should I create a bug report ?? John -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines