Hi All, I have an nfs mount from my CentOS 5.3 client to a CentOS5.3 server. This has been functioning correctly for some years. Beginning last week I had problems saving OpenOffice documents onto the nfs mounted volume. OpenOffice just times out with a file io error. So I tried just a simple shell - cd to the mounted volume did a vi create of text file - no problems. tried a chmod +w on an owned file - returned okay but no change to the permissions when checked with ls -l tried sudo chmod +w on the same file and get [rkampen@robsws p_494]$ sudo chmod +w 5887_cover.pdf Password: chmod: changing permissions of `5887_cover.pdf': Operation not permitted yet using gnome file browser I can change permissions on these nfs mounted files just fine - go figure.
This did work in the past - so what has changed? how do I check what version of nfs is actually working?
[rkampen@robsws p_494]$ mount 192.168.230.230:/NDG on /NDG type nfs (rw,noatime,intr,addr=192.168.230.230)
Any thoughts? Thanks Rob
Rob Kampen wrote:
[rkampen@robsws p_494]$ sudo chmod +w 5887_cover.pdf Password: chmod: changing permissions of `5887_cover.pdf': Operation not permitted yet using gnome file browser I can change permissions on these nfs mounted files just fine - go figure.
This did work in the past - so what has changed? how do I check what version of nfs is actually working?
Root squash may be enabled by default, try adding the "no_root_squash" option to your exports file on the server side, you may need to remount the volume on the client side after restarting/reloading nfs on the server.
nate
nate wrote:
Rob Kampen wrote:
[rkampen@robsws p_494]$ sudo chmod +w 5887_cover.pdf Password: chmod: changing permissions of `5887_cover.pdf': Operation not permitted yet using gnome file browser I can change permissions on these nfs mounted files just fine - go figure.
This did work in the past - so what has changed? how do I check what version of nfs is actually working?
Root squash may be enabled by default, try adding the "no_root_squash" option to your exports file on the server side, you may need to remount the volume on the client side after restarting/reloading nfs on the server.
nate
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
tried that and that now normal chmod as me works okay but sudo chmod still not permitted. I tried dragging a file to my desktop, opening and saving back to desktop works fine. Drag from desktop back onto folder via the file browser also works fine! So I guess nfs is okay? BTW chmod +w file.doc only changes permissions for owner and group - world is left untouched, not what I remembered, I guess some man reading coming my way.
So now it seems what I have is an Openoffice problem. It writes odt files just fine via nfs but not doc files. Must be a micro$oft conspiracy. I'll take this off list as it does not appear to be a CentOS issue. Thanks for the help. Rob
On Mon, Jul 13, 2009 at 16:32, Rob Kampenrkampen@kampensonline.com wrote:
BTW chmod +w file.doc only changes permissions for owner and group - world is left untouched, not what I remembered, I guess some man reading coming my way.
From "man chmod":
"If none of these are given, the effect is as if ‘a’ were given, but bits that are set in the umask are not affected."
That means it will set all if your umask is "0". As your umask will probably be either "022" or "002", it will set write permissions to only user or only user+group respectively.
HTH, Filipe
Filipe Brandenburger wrote:
On Mon, Jul 13, 2009 at 16:32, Rob Kampenrkampen@kampensonline.com wrote:
BTW chmod +w file.doc only changes permissions for owner and group - world is left untouched, not what I remembered, I guess some man reading coming my way.
From "man chmod":
"If none of these are given, the effect is as if ‘a’ were given, but bits that are set in the umask are not affected."
That means it will set all if your umask is "0". As your umask will probably be either "022" or "002", it will set write permissions to only user or only user+group respectively.
HTH, Filipe _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Got it - that makes sense - Thanks!
On Mon, 2009-07-13 at 16:32 -0400, Rob Kampen wrote:
nate wrote:
Rob Kampen wrote:
[rkampen@robsws p_494]$ sudo chmod +w 5887_cover.pdf Password: chmod: changing permissions of `5887_cover.pdf': Operation not permitted yet using gnome file browser I can change permissions on these nfs mounted files just fine - go figure.
This did work in the past - so what has changed? how do I check what version of nfs is actually working?
Root squash may be enabled by default, try adding the "no_root_squash" option to your exports file on the server side, you may need to remount the volume on the client side after restarting/reloading nfs on the server.
nate
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
tried that and that now normal chmod as me works okay but sudo chmod still not permitted. I tried dragging a file to my desktop, opening and saving back to desktop works fine. Drag from desktop back onto folder via the file browser also works fine! So I guess nfs is okay? BTW chmod +w file.doc only changes permissions for owner and group - world is left untouched, not what I remembered, I guess some man reading coming my way.
So now it seems what I have is an Openoffice problem. It writes odt files just fine via nfs but not doc files. Must be a micro$oft conspiracy. I'll take this off list as it does not appear to be a CentOS issue. Thanks for the help. Rob
---- if the 'mount' is done as a 'user' mount but then you switch to su with sudo command, this would be a likely result.
Craig
Craig White wrote:
On Mon, 2009-07-13 at 16:32 -0400, Rob Kampen wrote:
nate wrote:
Rob Kampen wrote:
[rkampen@robsws p_494]$ sudo chmod +w 5887_cover.pdf Password: chmod: changing permissions of `5887_cover.pdf': Operation not permitted yet using gnome file browser I can change permissions on these nfs mounted files just fine - go figure.
This did work in the past - so what has changed? how do I check what version of nfs is actually working?
Root squash may be enabled by default, try adding the "no_root_squash" option to your exports file on the server side, you may need to remount the volume on the client side after restarting/reloading nfs on the server.
nate
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
tried that and that now normal chmod as me works okay but sudo chmod still not permitted. I tried dragging a file to my desktop, opening and saving back to desktop works fine. Drag from desktop back onto folder via the file browser also works fine! So I guess nfs is okay? BTW chmod +w file.doc only changes permissions for owner and group - world is left untouched, not what I remembered, I guess some man reading coming my way.
So now it seems what I have is an Openoffice problem. It writes odt files just fine via nfs but not doc files. Must be a micro$oft conspiracy. I'll take this off list as it does not appear to be a CentOS issue. Thanks for the help. Rob
if the 'mount' is done as a 'user' mount but then you switch to su with sudo command, this would be a likely result.
Craig
Is there any way to know what level (version) of nfs is in use? I know how to distinguish between v4 and the rest (the mount uses nfs4 rather than just nfs) but how about the lower levels? Thanks Rob
On Mon, 2009-07-13 at 16:32 -0400, Rob Kampen wrote: <snip>
So now it seems what I have is an Openoffice problem. It writes odt files just fine via nfs but not doc files. Must be a micro$oft conspiracy. I'll take this off list as it does not appear to be a CentOS issue.
--- /usr/lib/openoffice/program/soffice
# file locking now enabled by default SAL_ENABLE_FILE_LOCKING=1 export SAL_ENABLE_FILE_LOCKING
Comment those two lines out and try that. An alternative is to use Samba instead of NFS. I had that problem on NFS also a while ago.
John
On Tue, 2009-07-14 at 00:42 -0400, JohnS wrote:
On Mon, 2009-07-13 at 16:32 -0400, Rob Kampen wrote:
<snip> > > So now it seems what I have is an Openoffice problem. It writes odt > files just fine via nfs but not doc files. > Must be a micro$oft conspiracy. > I'll take this off list as it does not appear to be a CentOS issue. --- /usr/lib/openoffice/program/soffice
# file locking now enabled by default SAL_ENABLE_FILE_LOCKING=1 export SAL_ENABLE_FILE_LOCKING
Comment those two lines out and try that. An alternative is to use Samba instead of NFS. I had that problem on NFS also a while ago.
---- perhaps as a test but that is a bad idea for every day usage.
Craig
Craig White wrote:
On Tue, 2009-07-14 at 00:42 -0400, JohnS wrote:
On Mon, 2009-07-13 at 16:32 -0400, Rob Kampen wrote:
<snip>
So now it seems what I have is an Openoffice problem. It writes odt files just fine via nfs but not doc files. Must be a micro$oft conspiracy. I'll take this off list as it does not appear to be a CentOS issue.
/usr/lib/openoffice/program/soffice
# file locking now enabled by default SAL_ENABLE_FILE_LOCKING=1 export SAL_ENABLE_FILE_LOCKING
Comment those two lines out and try that. An alternative is to use Samba instead of NFS. I had that problem on NFS also a while ago.
perhaps as a test but that is a bad idea for every day usage.
Craig
Yeah, do not like the idea of no file locking. As it turns out, I found the problem - the server was rebooted last week to get the latest kernel functioning and for some reason nlockmgr came up on the wrong port, thus the firewall did not allow the client to lock the file...... etc. Checked /etc/sysconfig/nfs and found the issue. Thanks to those that helped and made suggestions. Kind regards Rob
On Tue, 2009-07-14 at 06:39 -0700, Craig White wrote:
On Tue, 2009-07-14 at 00:42 -0400, JohnS wrote:
On Mon, 2009-07-13 at 16:32 -0400, Rob Kampen wrote:
<snip> > > So now it seems what I have is an Openoffice problem. It writes odt > files just fine via nfs but not doc files. > Must be a micro$oft conspiracy. > I'll take this off list as it does not appear to be a CentOS issue. --- /usr/lib/openoffice/program/soffice
# file locking now enabled by default SAL_ENABLE_FILE_LOCKING=1 export SAL_ENABLE_FILE_LOCKING
Comment those two lines out and try that. An alternative is to use Samba instead of NFS. I had that problem on NFS also a while ago.
perhaps as a test but that is a bad idea for every day usage.
Craig
--- Correct, but I only use that on a NFS server at home and not on production client machines. Production client I have using samba.
John
On Wed, 2009-07-15 at 11:02 -0400, JohnS wrote:
On Tue, 2009-07-14 at 06:39 -0700, Craig White wrote:
On Tue, 2009-07-14 at 00:42 -0400, JohnS wrote:
On Mon, 2009-07-13 at 16:32 -0400, Rob Kampen wrote:
<snip> > > So now it seems what I have is an Openoffice problem. It writes odt > files just fine via nfs but not doc files. > Must be a micro$oft conspiracy. > I'll take this off list as it does not appear to be a CentOS issue. --- /usr/lib/openoffice/program/soffice
# file locking now enabled by default SAL_ENABLE_FILE_LOCKING=1 export SAL_ENABLE_FILE_LOCKING
Comment those two lines out and try that. An alternative is to use Samba instead of NFS. I had that problem on NFS also a while ago.
perhaps as a test but that is a bad idea for every day usage.
Craig
Correct, but I only use that on a NFS server at home and not on production client machines. Production client I have using samba.
---- I can assure you from my own home usage that if I have file open on Linux (Fedora) desktop system, files are mounted from CentOS server via NFS mount and Windows uses samba from same CentOS server and if either is using an ODF or XLS or DOC file, the other will be notified that the file is locked and offered to open a copy or read-only. Locking semantics seems to work perfectly among systems.
Craig
On Wed, 2009-07-15 at 10:43 -0700, Craig White wrote:
On Wed, 2009-07-15 at 11:02 -0400, JohnS wrote:
On Tue, 2009-07-14 at 06:39 -0700, Craig White wrote:
On Tue, 2009-07-14 at 00:42 -0400, JohnS wrote:
On Mon, 2009-07-13 at 16:32 -0400, Rob Kampen wrote:
<snip> > > So now it seems what I have is an Openoffice problem. It writes odt > files just fine via nfs but not doc files. > Must be a micro$oft conspiracy. > I'll take this off list as it does not appear to be a CentOS issue. --- /usr/lib/openoffice/program/soffice
# file locking now enabled by default SAL_ENABLE_FILE_LOCKING=1 export SAL_ENABLE_FILE_LOCKING
Comment those two lines out and try that. An alternative is to use Samba instead of NFS. I had that problem on NFS also a while ago.
perhaps as a test but that is a bad idea for every day usage.
Craig
Correct, but I only use that on a NFS server at home and not on production client machines. Production client I have using samba.
I can assure you from my own home usage that if I have file open on Linux (Fedora) desktop system, files are mounted from CentOS server via NFS mount and Windows uses samba from same CentOS server and if either is using an ODF or XLS or DOC file, the other will be notified that the file is locked and offered to open a copy or read-only. Locking semantics seems to work perfectly among systems.
Craig
--- This is the older Open Office Version 2. This was not a samba or nfs problem. Since it has been fixed in Open Office but not my end. Does that explain my usage? I don't have the time to get to many of my own things. :-)
John
On Wed, 2009-07-15 at 14:51 -0400, JohnS wrote:
On Wed, 2009-07-15 at 10:43 -0700, Craig White wrote:
On Wed, 2009-07-15 at 11:02 -0400, JohnS wrote:
On Tue, 2009-07-14 at 06:39 -0700, Craig White wrote:
On Tue, 2009-07-14 at 00:42 -0400, JohnS wrote:
On Mon, 2009-07-13 at 16:32 -0400, Rob Kampen wrote:
<snip> > > So now it seems what I have is an Openoffice problem. It writes odt > files just fine via nfs but not doc files. > Must be a micro$oft conspiracy. > I'll take this off list as it does not appear to be a CentOS issue. --- /usr/lib/openoffice/program/soffice
# file locking now enabled by default SAL_ENABLE_FILE_LOCKING=1 export SAL_ENABLE_FILE_LOCKING
Comment those two lines out and try that. An alternative is to use Samba instead of NFS. I had that problem on NFS also a while ago.
perhaps as a test but that is a bad idea for every day usage.
Craig
Correct, but I only use that on a NFS server at home and not on production client machines. Production client I have using samba.
I can assure you from my own home usage that if I have file open on Linux (Fedora) desktop system, files are mounted from CentOS server via NFS mount and Windows uses samba from same CentOS server and if either is using an ODF or XLS or DOC file, the other will be notified that the file is locked and offered to open a copy or read-only. Locking semantics seems to work perfectly among systems.
Craig
This is the older Open Office Version 2. This was not a samba or nfs problem. Since it has been fixed in Open Office but not my end. Does that explain my usage? I don't have the time to get to many of my own things. :-)
---- there is little reason to be running OOo 2.x any longer
Craig
On Wed, 2009-07-15 at 12:16 -0700, Craig White wrote:
On Wed, 2009-07-15 at 14:51 -0400, JohnS wrote:
On Wed, 2009-07-15 at 10:43 -0700, Craig White wrote:
On Wed, 2009-07-15 at 11:02 -0400, JohnS wrote:
On Tue, 2009-07-14 at 06:39 -0700, Craig White wrote:
On Tue, 2009-07-14 at 00:42 -0400, JohnS wrote:
On Mon, 2009-07-13 at 16:32 -0400, Rob Kampen wrote:
<snip> > > So now it seems what I have is an Openoffice problem. It writes odt > files just fine via nfs but not doc files. > Must be a micro$oft conspiracy. > I'll take this off list as it does not appear to be a CentOS issue. --- /usr/lib/openoffice/program/soffice
# file locking now enabled by default SAL_ENABLE_FILE_LOCKING=1 export SAL_ENABLE_FILE_LOCKING
Comment those two lines out and try that. An alternative is to use Samba instead of NFS. I had that problem on NFS also a while ago.
perhaps as a test but that is a bad idea for every day usage.
Craig
Correct, but I only use that on a NFS server at home and not on production client machines. Production client I have using samba.
I can assure you from my own home usage that if I have file open on Linux (Fedora) desktop system, files are mounted from CentOS server via NFS mount and Windows uses samba from same CentOS server and if either is using an ODF or XLS or DOC file, the other will be notified that the file is locked and offered to open a copy or read-only. Locking semantics seems to work perfectly among systems.
Craig
This is the older Open Office Version 2. This was not a samba or nfs problem. Since it has been fixed in Open Office but not my end. Does that explain my usage? I don't have the time to get to many of my own things. :-)
there is little reason to be running OOo 2.x any longer
Craig
--- Ha Ha come on over and Update for me :-)
John
On 2009-07-15 21:16, Craig White wrote:
there is little reason to be running OOo 2.x any longer
Except that OOo 3.x is not packaged by RHEL/CentOS/rpmforge/... and that downloading and installing from openoffice.org installs version 3.1.0 which positions all your tables from a MS Word documents 16cm out of the visable page.
http://www.openoffice.org/issues/show_bug.cgi?id=101451
Which is a showstopper in real life, where doc and docx files are still "normal" for most of the people.
Unless you install the mongolian version, which is still at 3.0 and which does not have the bug. Or wait for 3.1.1 which would solve this, but then having a packaged version which can easily be upgraded using yum would still be handy.
Paul Bijnens wrote:
On 2009-07-15 21:16, Craig White wrote:
there is little reason to be running OOo 2.x any longer
Except that OOo 3.x is not packaged by RHEL/CentOS/rpmforge/... and that downloading and installing from openoffice.org installs version 3.1.0 which positions all your tables from a MS Word documents 16cm out of the visable page.
http://www.openoffice.org/issues/show_bug.cgi?id=101451
Which is a showstopper in real life, where doc and docx files are still "normal" for most of the people.
Unless you install the mongolian version, which is still at 3.0 and which does not have the bug. Or wait for 3.1.1 which would solve this, but then having a packaged version which can easily be upgraded using yum would still be handy.
I use OOo 3.1 x86_64 and at the office use M$ word doc files - we use tables and I have no issues with opening these in OO0 3.1. YMMV
On Mon, 2009-07-13 at 15:47 -0400, Rob Kampen wrote:
Hi All, I have an nfs mount from my CentOS 5.3 client to a CentOS5.3 server. This has been functioning correctly for some years. Beginning last week I had problems saving OpenOffice documents onto the nfs mounted volume. OpenOffice just times out with a file io error. So I tried just a simple shell - cd to the mounted volume did a vi create of text file - no problems. tried a chmod +w on an owned file - returned okay but no change to the permissions when checked with ls -l tried sudo chmod +w on the same file and get [rkampen@robsws p_494]$ sudo chmod +w 5887_cover.pdf Password: chmod: changing permissions of `5887_cover.pdf': Operation not permitted yet using gnome file browser I can change permissions on these nfs mounted files just fine - go figure.
This did work in the past - so what has changed? how do I check what version of nfs is actually working?
[rkampen@robsws p_494]$ mount 192.168.230.230:/NDG on /NDG type nfs (rw,noatime,intr,addr=192.168.230.230)
Any thoughts?
---- man pages are your friends
man exports
Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anonymous or nobody uid. This mode of operation (called ‘root squash- ing’) is the default, and can be turned off with no_root_squash.
Craig
-
Craig White -
Filipe Brandenburger -
JohnS -
nate -
Paul Bijnens -
Rob Kampen