Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
For some reason when I open an odt or ods file in OpenOffice it opens it as read-only when the file is on an nfs server. I have read/write permissions on both the file and the directory. If I copy the file to a local directory it works ok.
I have understood that file access over nfs was transparent as long as the export was (rw) and the user has appropriate permissions.
Server: Debian 4
Client: Sabayon 3.3
I'd appreciate any insight on what I need to do to get this to work.
I wonder if it has to do with the fact that an ODF document is a collection of zipped documents? Does this happen with all Open Office documents or just these two formats?
Can you open a zip collection in ark and then add a file?
My guess is that byte-range-locking is normally performed but this is impossible because the file can't be locked this way because it is a zip file, and needs to be saved over in the end.
This is just a wild guess on my part.
Another possibility is that because it is a zip file, and byte-range locking won't work, to save your changes, a deletion of the original file would need to be performed. If you aren't the owner of the document, and the sticky bit is set on the directory being shared, that is prohibited. A way to test if this is the problem would be to save an original OO document on this share and then try to edit it. Look at the ownership of the document. If the suid or guid on the directory isn't set, changing the ownership or group ownership, can you edit and save the document?
I tried it with the wordprocessor, spreadsheet, and impress formats. They all fail when I open them over nfs.
I can zip them and copy the zip to /home and everything opens fine as (rw). Or I can copy an individual file to /home and it works. It's just when I try to open it from the nfs share.
I tried creating a new document and saving it, but got a write error and it created a zero byte file.
When I open the ods file in gnumeric it opens it as read/write and saves it ok in the gnumeric format. That is not an option for other OO formats though. Apparently gnumeric can import but not export opendocument formats. Other applications, such as text editors can also open stuff and save correctly.
I've tried to find OO options that control this sort of thing, but the only thing I found was in the security setting where there is a checkbox saying "open file as read-only" and it is not checked.
Thanks again jschiwal. According to the link you gave me, the discussion there was specific to some versions of SUSE. However the problem appears to exactly what I am experiencing, so when I get home tonight I will try that solution.
Distribution: Solaris 11.4, Oracle Linux, Mint, Debian/WSL
Posts: 9,789
Rep:
This fix actually introduces a new issue: file locking is disabled so there is a risk of data loss if the document is open more than once at the same time.
A better but less simple to implement solution would be to upgrade to NFSv4.
Thanks jlliagre for the heads up. I am aware of this and I have already considered the risks. I only have two local users, including myself. The other users will be managing files via scp until I get a versioning system implemented. Each remote user will be responsible for a distinct set of files, so we won't have many concurrency issues.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.