[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 02/05/17 23:22, M. J. Everitt wrote: > On 02/05/17 22:48, Julian Hall wrote: >> Cerce Books # cd Mine/Just\ Ordinary\ Men/Main\ Story/ >> Cerce Main Story # ls -alh DOC >> total 2.7M >> drwxr-xr-x 2 julian julian 4.0K May 2 14:48 . >> drwxr-xr-x 5 julian julian 4.0K Jan 19 17:56 .. >> -rwxrwxrwx 1 1026 users 51K Sep 21 2012 Ordinary Men_ch10.doc >> -rwxrwxrwx 1 1026 users 48K Sep 22 2012 Ordinary Men_ch11.doc >> -rwxrwxrwx 1 1026 users 51K Sep 21 2012 Ordinary Men_ch12.doc > <snip snip> > > Yeah .. those '1026' and '1024' ids should really be 'julian' I fear, > and I suspect there is some peculiarity going on with the NFS share. > > Mr meowski was hoping you could change permissions with your user id, > and perhaps with sudo this /may/ have been possible, but as you've > proven, this is a whole lot more reliable as root, and therefore you > need to be more careful what you specify in the 'chown' command as your > user/group (NB. iirc, both are not always necessary). $USER in this > instance has shlurped 'root' instead of 'julian' as desired... ! > > I think you've got a lot of options in your NFS mount in /etc/fstab .. I > think I've managed with a very minimal config in the past to the effect > of "nfsvers=3 (to prevent nfs4 chaos) and rsize/wsize=zzz to optimise > transfer sizes. no-auto seems unnecessary if you want to -use- the share > without manually mounting, and 'nouser' is supposed to prevent normal > users from mounting the share themselves, hence requiring root > privileges. Somewhere I think you have a stack of potentially > conflicting options .. you might want to pare down (either by starting > with few/no options, or by reducing down one-by-one) to see which change > helps/breaks your scenario. You may be super-unlucky in that some other > (udisks?) service is not overriding your fstab information which you > -think- is being used, and you should definitely check what options are > *active* when the NFS share is up (simply type 'mount' and look at the > NFS entry's options) might give you a hint as to where to look for the > problem. Yes, this is all pretty much spot on - the NFS stuff is *definitely* wrong as MJE points out: those "1026:users" entries are sure signs of incorrect permissions. So for the moment, completely abandon the NFS stuff: it's broken, full stop. I've already pointed out that fstab stanza is a big fat mess with mutually contradictory options specified... But one thing at a time, or we'll never fix anything. Also correct: the chown command failed on the copy of "Main" folder in your example, presumably due to permissions *again* which is odd 'cos I thought you'd already chmod'd them 777 previously. You should have reissued it with sudo instead of as root because then the $USER variable would have been properly evaluated, but that was my fault for not being clearer. So, when you get the chance grab a terminal and head back to the same spot. So, presuming that you are julian:julian (user:group), have sudo access and are back in the arbitrary folder/path "Word" do the following: sudo chmod -R 777 Main sudo chown -R julian:julian Main sudo cp -avr Main ~/Desktop/ cd ~/Desktop/Main ls -alh This is using brute force and is hardly elegant, but hey Â\_(ã)_/Â It will set full permissions (read/write/execute) to ON for user/group/others (so everyone basically), change the owner and group to UID julian and GID julian (which should be completely redundant following a 777 but whatever), recursively copy (with sudo, again redundant) the entire Main folder whilst preserving all of it's attributes to the Desktop and finally cd to it and dump out the listing in long format. Paste the output of the final command - there won't be any errors this time, and if there are, we have serious problems. You should see all your files now owned by julian:julian and with permissions rwxrwxrwx for all entries except directories which will be drwxrwxrwx. Browse to it with a Nautilus/Thunar/whatever file viewer and everything should look fine as well. More importantly, you should now probably be able to open the files in LibreOffice writer and edit them as usual. I say "probably" because there are still things that may be preventing this: the OpenOffice > LibreOffice switch, the presence of temporary or stale lock files or a default save setting in OpenOffice that was somehow exporting files in a protected mode. But at least the stale/temp files thing will be immediately obvious from the output of the final "ls -alh" and the other issues can be dealt with one at a time. See how you get on with that for now. Cheers -- The Mailing List for the Devon & Cornwall LUG https://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq