Project

General

Profile

Bug #2644

file corruption with nfs sharing

Added by Richard PALO over 8 years ago. Updated over 7 years ago.

Status:
In Progress
Priority:
High
Assignee:
-
Category:
-
Start date:
2012-04-20
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

followup from https://www.illumos.org/issues/2347

Have an openoffice .ods calc file on the nfs/cifs share on an OI_151a3 server
from a client running the same version, open the file (OOO3.3), made some modifications and closed the file. No erreurs.

But the following is found locally in /var/adm/messages

Apr 20 09:29:03 x3200 nfs: [ID 897781 kern.notice] NFS write error on host smicro: Permission denied.
Apr 20 09:29:03 x3200 nfs: [ID 702911 kern.notice] (file handle: 58b0f1aa 50a83908 27c2000a 0 2a1708 4000a 0 5ee45 0)
Apr 20 09:29:03 x3200 nfs: [ID 897781 kern.notice] NFS write error on host smicro: Permission denied.
Apr 20 09:29:03 x3200 nfs: [ID 702911 kern.notice] (file handle: 58b0f1aa 50a83908 27c2000a 0 2a1708 4000a 0 5ee45 0)
Apr 20 09:29:03 x3200 nfs: [ID 897781 kern.notice] NFS write error on host smicro: Permission denied.
Apr 20 09:29:03 x3200 nfs: [ID 702911 kern.notice] (file handle: 58b0f1aa 50a83908 27c2000a 0 2a1708 4000a 0 5ee45 0)
Apr 20 09:29:03 x3200 nfs: [ID 897781 kern.notice] NFS write error on host smicro: Permission denied.
Apr 20 09:29:03 x3200 nfs: [ID 702911 kern.notice] (file handle: 58b0f1aa 50a83908 27c2000a 0 2a1708 4000a 0 5ee45 0)

looked at the file, garbage now...

the server and the workstation are static ip addresses, both are listed in /etc/hosts
nfs share looks like zfs/rpool/export/dossiers nfs=() smb=() nfs:sys=(rw="@192.168.0.0/24:@192.168.1.0/24")
/export/dossiers
Dossiers=/export/dossiers smb=(guestok="true")
from sharemgr

starting to have vnc problems again too, will post another bug report

History

#1

Updated by Richard PALO over 8 years ago

file protection seems ok with ACL (/usr/bin/ls -av):

rwxrwxrwx+  1 nobody   nobody 104328 avr. 20 09:29  /export/dossiers/</dir/filename>
     0:everyone@:read_data/write_data/append_data/read_xattr/write_xattr
         /execute/delete_child/read_attributes/write_attributes/delete
         /read_acl/write_acl/write_owner/synchronize:file_inherit
         /dir_inherit:allow

#2

Updated by Richard PALO over 8 years ago

given that the CIFS deployment dates since november 2010 and has given no problems whatsoever until now (with the suggestion to turn on NFS to debug a file-roller problem), it is either related to NFS, 151a3 or both.
I guess there's no choice but to back out given the absence of any feedback.

#3

Updated by Richard PALO over 8 years ago

I'm not really sure why, but after looking at
https://wiki-bsse.ethz.ch/display/ITDOC/Managing+CIFS+on+Solaris
and
http://mail.opensolaris.org/pipermail/cifs-discuss/2009-December/002586.html

is it possible that the absence of setting aclmode=passthrough and aclinherit=passthrough could be behind the problem?
I just tried creating a file from the client using touch, and I get the following on the server:

# /usr/bin/ls -lapdV /export/dossiers/Documents/foo.bar 
-rw-r--r--   1 richard  staff          0 avr. 23 13:06 /export/dossiers/Documents/foo.bar
                 owner@:rw-p--aARWcCos:-------:allow
                 group@:r-----a-R-c--s:-------:allow
              everyone@:r-----a-R-c--s:-------:allow

the directory has
~# /usr/bin/ls -lapdV /export/dossiers/Documents/
drwxrwxrwx+ 41 root     root          54 avr. 23 13:06 /export/dossiers/Documents//
              everyone@:rwxpdDaARWcCos:fd-----:allow

extract from zfs get all

rpool/export/dossiers  aclmode                         discard                                            default
rpool/export/dossiers  aclinherit                      restricted                                         default

that is, after setting these, touching a file creates (as I would have already expected)

# /usr/bin/ls -lapdV /export/dossiers/Documents/bar.foo 
-rwxrwxrwx+  1 richard  staff          0 avr. 23 13:35 /export/dossiers/Documents/bar.foo
              everyone@:rwxpdDaARWcCos:------I:allow

In summary, since the file was existing, is it possible that the corruption was due to this ACL ?

Thanks in advance

#4

Updated by Richard PALO over 8 years ago

still fighting this one, seems more and more a combination of nfs and ACLs
(for memory, ACL=> /usr/bin/chmod -R A=everyone@:full_set:fd:allow rpool/export/dossiers)

# zfs get aclmode,aclinherit,sharenfs rpool/export/dossiers
NAME                   PROPERTY    VALUE                                              SOURCE
rpool/export/dossiers  aclmode     passthrough                                        local
rpool/export/dossiers  aclinherit  passthrough                                        local
rpool/export/dossiers  sharenfs    rw=@192.168.0.0/24:@192.168.1.0/24 local
# ls -aV .zfs/shares/dossiers 
-rwxrwxrwx+  1 root     root           0 mars 26 11:54 .zfs/shares/dossiers
              everyone@:rwxpdDaARWcCos:-------:allow
# ls -aV
total 91
drwxrwxrwx+  5 root     root           5 avr. 27 07:14 .
              everyone@:rwxpdDaARWcCos:fd-----:allow
drwxr-xr-x   5 root     root           5 oct. 27  2011 ..
                 owner@:--------------:-------:deny
                 owner@:rwxp---A-W-Co-:-------:allow
                 group@:-w-p----------:-------:deny
                 group@:r-x-----------:-------:allow
              everyone@:-w-p---A-W-Co-:-------:deny
              everyone@:r-x---a-R-c--s:-------:allow
drwxrwxrwx+  2 root     sys            3 mars 26 11:54 .$EXTEND
              everyone@:rwxpdDaARWcCos:fd-----:allow
drwxrwxrwx+ 41 root     root          56 avr. 27 13:06 Documents
              everyone@:rwxpdDaARWcCos:fd-----:allow
drwxrwxrwx+ 35 root     root         155 avr. 27 08:02 test
              everyone@:rwxpdDaARWcCos:fd-----:allow

I tried the following experiment touch local and over nfs, and save_as from scalc over both:
(note over NFS, the differing ACL from save or save as)

$ ls -aV 
-rwxrwxrwx+  1 nobody   nobody    260051 avr. 27 11:12 <calc file>.ods*
              everyone@:rwxpdDaARWcCos:fd-----:allow
-rwxrwxrwx+  1 richard  staff          0 avr. 27 15:10 nfs-foo*
              everyone@:rwxpdDaARWcCos:-------:allow
-rw-r--r--   1 richard  staff     272815 avr. 27 15:11 nfs-<calc file>.ods
                 owner@:rw-p--aARWcCos:-------:allow
                 group@:r-----a-R-c--s:-------:allow
              everyone@:r-----a-R-c--s:-------:allow
-rwxrwxrwx+  1 richard  staff     272426 avr. 27 15:13 local<calc file>.ods*
              everyone@:rwxpdDaARWcCos:-------:allow
-rwxrwxrwx+  1 root     root           0 avr. 27 15:13 local-foo*
              everyone@:rwxpdDaARWcCos:-------:allow
-rwxrwxrwx   1 richard  staff     270914 avr. 27 15:25 nfs modify <calc file>.ods*
                 owner@:rwxp--aARWcCos:-------:allow
                 group@:rwxp--a-R-c--s:-------:allow
              everyone@:rwxp--a-R-c--s:-------:allow

I have a gut feeling that the resulting ACL over NFS is behind the problem somehow.

Is it possible that this is a combination of a OpenOffice 3.3 CALC and NFS problem.
There are no problems under local or CIFS calc access.

I'd like to know if LibreOffice behaves the same way in save/save_as over NFS... is there a version that works on oi_151a3?

Pointers to help get over this data corruption problem?

#5

Updated by Bayard Bell over 8 years ago

  • Tags deleted (needs-triage)

For something as important as data corruption, please escalate the issue via e-mail to oi-dev and or the illumos developer@.

#6

Updated by Richard PALO over 8 years ago

sorry, perhaps I posted to the wrong lists:
http://article.gmane.org/gmane.os.openindiana.general/7581

#7

Updated by Ken Mays over 7 years ago

  • Status changed from New to Closed

Migrate this over to Illumos-specific bug reports.

#8

Updated by Marcel Telka over 7 years ago

  • Project changed from OpenIndiana Distribution to illumos gate
#9

Updated by Marcel Telka over 7 years ago

  • Status changed from Closed to In Progress

Moved to illumos gate project and reopened.

Also available in: Atom PDF