Bug 6049 - unable to save profiles
Summary: unable to save profiles
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.3
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: 3.3.0rc2
Hardware: x64 Solaris
: P3 regression
Target Milestone: ---
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL: http://iws.cs.uni-magdeburg.de/~elkne...
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-18 03:43 UTC by Jens Elkner
Modified: 2009-03-02 09:02 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Elkner 2009-01-18 03:43:13 UTC
Trying to use a ZFS based profile directory (Vista x64), however saving the profile always fails (and reading as well as long as the 'check profile owner' 
policy is not disabled). Directories are created (even if there is no coerresponding entry in the logs) but contain *.tmp of size 0 only.
...
log level = 1 acls:10 vfs:10 registry:10 auth:10
[profiles]
        comment = Roaming Profiles
        path = /export/profiles
        browsable = no
        read only = no
        create mask = 0600
        directory mask = 0700
        csc policy = disable
        guest ok = no
        printable = no
        hide files = /desktop.ini/outlook*.lnk/*Briefcase*/

        # zfs stuff

        vfs objects = zfsacl full_audit
        vfs_full_audit:success = all
        vfs_full_audit:failure = all
        full_audit:facility = LOCAL1
        full_audit:priority = NOTICE
        nfs4: mode = special
        nfs4: chown = true
        nfs4: acedup = merge
        zfsacl: acesort = ntfs

        inherit acls = Yes
        blocking locks = No
        delete readonly = Yes
        dos filetime resolution = Yes

Tried this with the zfs order patch (see bug 5653) and without it - no luck.
If I chmod 1777 to the parent directory and use 'inherit permissions' profile reading and writing works without any Win errors (however having 1777 on each file/dir is not, what anybody wants), which leads to the conclusion, that there is something wrong with the zfs/nfs stack ...

log files are available from the URL above.
Comment 1 Jens Elkner 2009-03-02 09:02:30 UTC
fixed in 3.3.1 (nfs4_acls.c directory check). see #6133