Re: [zfs-discuss] Making ZFS better: zfshistory

[Mark Shellenbaum]

On 4/21/10 6:49 AM, Edward Ned Harvey wrote:

From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Edward Ned Harvey


From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Nicolas Williams

And you can even create, rename and destroy snapshots by creating,
renaming and removing directories in .zfs/snapshot:

% mkdir .zfs/snapshot/foo
% mv .zfs/snapshot/foo .zfs/snapshot/bar
% rmdir .zfs/snapshot/bar

(All this also works locally, not just over ZFS.)


Holy crap, for real?  I'll have to try that.  ;-)


I just tested that, and it works (cool, thanks for the tip Nicolas.)
However, I think you phrased it slightly incorrect.  At least on my systems
(solaris 10), let me correct this:

You can create/destroy/rename snapshots via mkdir, rmdir, mv inside the
.zfs/snapshot directory, however, it will only work if you're running the
command locally.  It will not work from a NFS client.



It will work over NFS or SMB, but you will need to allow it via the 
necessary delegated administration permissions.


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Making ZFS better: zfshistory

[Mark Shellenbaum]

On 04/21/10 08:45 AM, Edward Ned Harvey wrote:

From: Mark Shellenbaum [mailto:mark.shellenb...@oracle.com]


You can create/destroy/rename snapshots via mkdir, rmdir, mv inside

the

.zfs/snapshot directory, however, it will only work if you're running

the

command locally.  It will not work from a NFS client.



It will work over NFS or SMB, but you will need to allow it via the
necessary delegated administration permissions.


Go on?
I tried it over NFS and it didn't work.  So ... what are the "necessary
permissions?"



Depends on what you want to do

If all you want is to allow a certain NFS/SMB user the ability to create 
snapshots then all you would need is something like this


# zfs allow  snapshot 

But if you want to let them delete snapshot then you would also need to 
give out destroy,mount.


# zfs allow  destroy,mount 

renaming will also require "create" permission.


I did it from a NFS client as root, where root maps to root.



If you aren't using delegation then the code will require PRIV_SYS_MOUNT 
and an NFS won't have that privilege.


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] NFS sgid directory interoperability with Linux

[Mark Shellenbaum]

Paul B. Henson wrote:

We're running Solaris 10 with ZFS to provide home and group directory file
space over NFSv4. We've run into an interoperability issue between the
Solaris NFS server and the Linux NFS client regarding the sgid bit on
directories and assigning appropriate group ownership on newly created
subdirectories.

If a directory exists with the sgid bit set owned by a group other than
the user's primary group, new directories created in that directory are
owned by the primary group rather than by the group of the parent
directory.

Evidently, the Solaris NFS server assumes the client will specify the
correct owner of the directory, whereas the Linux NFS client assumes the
server is in charge of implementing the sgid functionality and will assign
the right group itself. As such, with a Solaris server and a Linux client
the functionality is simply broken :(.

This poses a considerable security issue, as the GROUP@ inherited ACL now
provides access to the primary group of the user rather than the intended
group, which as you might imagine is somewhat problematic.

Ideally, it seems that the server should be responsible for this, rather
than the client voluntarily enforcing it. Is this functionality strictly
defined anywhere, or is it implementation dependent? You'd think
something like this would have turned up in an interoperability bake-off at
some point.

Thanks for any information...




Does it only fail under NFS or does it only fail when inheriting an ACL?

I just tried it locally and it appears to work.

# ls -ld test.dir
drwsr-sr-x   2 marksstorage4 Oct 12 16:45 test.dir

my primary group is "staff"

$ touch file
$ ls -l file
-rw-r--r--   1 marksstorage0 Oct 12 16:49 file


   -Mark




___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] acl's and new dirs

[Mark Shellenbaum]

Thomas Burgess wrote:
I've got a strange issue,  If this is covered elsewhere, i apologize in 
advance for my newbness


I've got a couple ZFS filesystems shared cifs and nfs, i've managed to 
get ACL's working the way i want, provided things are accessed via cifs 
and nfs.


If i create a new dir via cifs or NFS then the acl's work exactly as i 
want, but if i do the same thing with shell using mkdir, it 
doesn't.i'm not sure what i'm missing here...




What is the ACL on the parent directory?

What are the settings of the aclinherit and aclmode properties?

How are you creating the directory?  Is it /usr/bin/mkdir or 
/usr/gnu/bin/mkdir?


basically,  if i create the dir with mkdir, it creates, it looks ok but 
i can't copy files into it.why should this be?




That doesn't make sense, NFS and local should access should behave the 
same way.


The CIFS serve bypasses the aclmode/aclinherit properties and always 
creates files/dir with strict windows ACL inheritance semantics.


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Repairing corrupted ZFS pool

[Mark Shellenbaum]

On 11/16/12 17:15, Peter Jeremy wrote:

I have been tracking down a problem with "zfs diff" that reveals
itself variously as a hang (unkillable process), panic or error,
depending on the ZFS kernel version but seems to be caused by
corruption within the pool.  I am using FreeBSD but the issue looks to
be generic ZFS, rather than FreeBSD-specific.

The hang and panic are related to the rw_enter() in
opensolaris/uts/common/fs/zfs/zap.c:zap_get_leaf_byblk()



There is probably nothing wrong with the snapshots.  This is a bug in 
ZFS diff.  The ZPL parent pointer is only guaranteed to be correct for 
directory objects.  What you probably have is a file that was hard 
linked multiple times and the parent pointer (i.e. directory) was 
recycled and is now a file




The error is:
Unable to determine path or stats for object 2128453 in 
tank/beckett/home@20120518: Invalid argument

A scrub reports no issues:
root@FB10-64:~ # zpool status
   pool: tank
  state: ONLINE
status: The pool is formatted using a legacy on-disk format.  The pool can
 still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
 pool will no longer be accessible on software that does not support 
feature
 flags.
   scan: scrub repaired 0 in 3h24m with 0 errors on Wed Nov 14 01:58:36 2012
config:

 NAMESTATE READ WRITE CKSUM
 tankONLINE   0 0 0
   ada2  ONLINE   0 0 0

errors: No known data errors

But zdb says that object is the child of a plain file - which isn't sane:

root@FB10-64:~ # zdb -vvv tank/beckett/home@20120518 2128453
Dataset tank/beckett/home@20120518 [ZPL], ID 605, cr_txg 8379, 143G, 2026419 objects, 
rootbp DVA[0]=<0:266a0efa00:200>  DVA[1]=<0:31b07fbc00:200>  [L0 DMU objset] 
fletcher4 lzjb LE contiguous unique double size=800L/200P birth=8375L/8375P fill=2026419 
cksum=1acdb1fbd9:93bf9c61e94:1b35c72eb8adb:389743898e4f79

 Object  lvl   iblk   dblk  dsize  lsize   %full  type
2128453116K  1.50K  1.50K  1.50K  100.00  ZFS plain file
 264   bonus  ZFS znode
 dnode flags: USED_BYTES USERUSED_ACCOUNTED
 dnode maxblkid: 0
 path???
 uid 1000
 gid 1000
 atime   Fri Mar 23 16:34:52 2012
 mtime   Sat Oct 22 16:13:42 2011
 ctime   Sun Oct 23 21:09:02 2011
 crtime  Sat Oct 22 16:13:42 2011
 gen 2237174
 mode100444
 size1089
 parent  2242171
 links   1
 pflags  4080004
 xattr   0
 rdev0x

root@FB10-64:~ # zdb -vvv tank/beckett/home@20120518 2242171
Dataset tank/beckett/home@20120518 [ZPL], ID 605, cr_txg 8379, 143G, 2026419 objects, 
rootbp DVA[0]=<0:266a0efa00:200>  DVA[1]=<0:31b07fbc00:200>  [L0 DMU objset] 
fletcher4 lzjb LE contiguous unique double size=800L/200P birth=8375L/8375P fill=2026419 
cksum=1acdb1fbd9:93bf9c61e94:1b35c72eb8adb:389743898e4f79

 Object  lvl   iblk   dblk  dsize  lsize   %full  type
2242171316K   128K  25.4M  25.5M  100.00  ZFS plain file
 264   bonus  ZFS znode
 dnode flags: USED_BYTES USERUSED_ACCOUNTED
 dnode maxblkid: 203
 path/jashank/Pictures/sch/pdm-a4-11/stereo-pair-2.png
 uid 1000
 gid 1000
 atime   Fri Mar 23 16:41:53 2012
 mtime   Mon Oct 24 21:15:56 2011
 ctime   Mon Oct 24 21:15:56 2011
 crtime  Mon Oct 24 21:15:37 2011
 gen 2286679
 mode100644
 size26625731
 parent  7001490
 links   1
 pflags  4080004
 xattr   0
 rdev0x

root@FB10-64:~ # zdb -vvv tank/beckett/home@20120518 7001490
Dataset tank/beckett/home@20120518 [ZPL], ID 605, cr_txg 8379, 143G, 2026419 objects, 
rootbp DVA[0]=<0:266a0efa00:200>  DVA[1]=<0:31b07fbc00:200>  [L0 DMU objset] 
fletcher4 lzjb LE contiguous unique double size=800L/200P birth=8375L/8375P fill=2026419 
cksum=1acdb1fbd9:93bf9c61e94:1b35c72eb8adb:389743898e4f79

 Object  lvl   iblk   dblk  dsize  lsize   %full  type
7001490116K512 1K512  100.00  ZFS directory
 264   bonus  ZFS znode
 dnode flags: USED_BYTES USERUSED_ACCOUNTED
 dnode maxblkid: 0
 path/jashank/Pictures/sch/pdm-a4-11
 uid 1000
 gid 1000
 atime   Thu May 17 03:38:32 2012
 mtime   Mon Oct 24 21:15:37 2011
 ctime   Mon Oct 24 21:15:37 2011
 crtime  Fri Oct 14 22:17:44 2011
 gen 2088407
 mode40755
 size6
 parent  6370559
 links   2
 pflags  4080144
 xattr   0
 rdev0x
 microzap: 512 bytes, 4 entries

 stereo-pai

Re: [zfs-discuss] Repairing corrupted ZFS pool

[Mark Shellenbaum]

On 11/19/12 1:14 PM, Jim Klimov wrote:

On 2012-11-19 20:58, Mark Shellenbaum wrote:

There is probably nothing wrong with the snapshots.  This is a bug in
ZFS diff.  The ZPL parent pointer is only guaranteed to be correct for
directory objects.  What you probably have is a file that was hard
linked multiple times and the parent pointer (i.e. directory) was
recycled and is now a file


Interesting... do the ZPL files in ZFS keep pointers to parents?



The parent pointer for hard linked files is always set to the last link 
to be created.


$ mkdir dir.1
$ mkdir dir.2
$ touch dir.1/a
$ ln dir.1/a dir.2/a.linked
$ rm -rf dir.2

Now the parent pointer for "a" will reference a removed directory.

The parent pointer is a single 64 bit quantity that can't track all the 
possible parents a hard linked file could have.


Now when the original dir.2 object number is recycled you could have a 
situation where the parent pointer for points to a non-directory.


The ZPL never uses the parent pointer internally.  It is only used by 
zfs diff and other utility code to translate object numbers to full 
pathnames.  The ZPL has always set the parent pointer, but it is more 
for debugging purposes.



How in the COW transactiveness could the parent directory be
removed, and not the pointer to it from the files inside it?
Is this possible in current ZFS, or could this be a leftover
in the pool from its history with older releases?

Thanks,
//Jim
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] NFS acl inherit problem

[Mark Shellenbaum]

On 6/1/11 12:51 AM, lance wilson wrote:

The problem is that nfs clients that connect to my solaris 11 express server 
are not inheriting the acl's that are set for the share. They create files that 
don't have any acl assigned to them, just the normal unix file permissions. Can 
someone please provide some additional things to test so that I can get this 
sorted out.

This is the output of a normal ls -al

drwxrwxrwx+ 5 root root 11 2011-05-31 11:14 acltest

The compact version is ls -Vd

drwxrwxrwx+ 5 root root 11 May 31 11:14 /smallstore/acltest
user:root:rwxpdDaARWcCos:fd-:allow
everyone@:rwxpdDaARWc--s:fd-:allow

The parent share has the following permissions
drwxr-xr-x+ 5 root root 5 May 30 22:26 /smallstore/
user:root:rwxpdDaARWcCos:fd-:allow
everyone@:r-x---a-R-c---:fd-:allow
owner@:rwxpdDaARWcCos:fd-:allow

This is the acl for the files created by a ubuntu client. There is no acl 
inheritance occurring.

-rw-r--r-- 1 1000 1000 0 May 31 22:20 /smallstore/acltest/ubuntu_file
owner@:rw-p--aARWcCos:---:allow
group@:r-a-R-c--s:---:allow
everyone@:r-a-R-c--s:---:allow


Looks like the linux client did a chmod(2) after creating the file.

what happens when you create a file locally in that directory on the 
solaris system?




This is the acl for files created by a user from a windows client. There is 
full acl inheritance.
-rwxrwxrwx+ 1 ljw staff 0 May 31 22:22 /smallstore/acltest/windows_file
user:root:rwxpdDaARWcCos:--I:allow
everyone@:rwxpdDaARWc--s:--I:allow

The acl inheritance is on at both the share and directory levels so it should 
be passing them to files that are created.

smallstore aclinherit restricted default
smallstore/acltest aclinherit passthrough local

Again any help would be most appreciated.


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] send/receive

[Mark Shellenbaum]

Justin Vassallo wrote:
> Thanks Michale,
> 
> that got me through to second round :) I eventually added /sbin to my
> /etc/profile to avoid the mistake in future.
> 
> So the issue is now with the USER rights on the zfs. How can I grant USER
> rights on this zfs? Is upgrading to a zfs which supports 'zfs allow' my only
> option?
> 
> ---justin
> 

If your wanting to allow a non-privileged user the ability to do a 
send/receive then you will need to give the user the necessary permissions.

For example:

# zfs allow joe receive,send,create,mount tank/fs

This will allow user joe to send, receive, create datasets and mount 
them on the dataset tank/fs and all of its descendants.

See the zfs admin guide for example of the zfs delegated admin model.

Your pool must be version 8 or greater for delegated administration support.

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] send/receive

[Mark Shellenbaum]

Justin Vassallo wrote:
> Indeed I want a permanent solution so I'll upgrade my zpool as suggested,
> since that seems to be the only option
> 
> I searched sunsolve for the relevant patches /package downloads and googled
> zfs upgrade but only got references to documentation. Any clues where I can
> get the upgrade from?
> 
> I'm running Solaris 10 8/07 s10x_u4wos_12b X86
> 
> justin
> 

zfs delegation isn't currently available in Solaris 10.  It will be in 
S10u6 though.

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] How to get a file's crtime attribute from a znode?

[Mark Shellenbaum]

Todd E. Moore wrote:
> I'm used to using fstat() and other calls to get atime, ctime, and mtime 
> values, but I understand that the znode also stores a files creation 
> time in crtime attribute.
> 
> Which system call can I use to retrieve this information?
> 

You can use the getattrat() or fgetattr() interface to retrieve the 
create time attribute.  That interface returns an nvlist which has 
various supplemental attributes such as the create time.

You must have a ZFS version 3 file system for that interface to work.

If all you want is to see the create time then you can use "ls" to 
display it.

$ ls -% all 



   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] force a reset/reinheit zfs acls?

[Mark Shellenbaum]

Rob wrote:
> Hello All!
> 
> Is there a command to force a re-inheritance/reset of ACLs? e.g., if i have a 
> directory full of folders that have been created with inherited ACLs, and i 
> want to change the ACLs on the parent folder, how can i force a reapply of 
> all ACLs?
>  
>  
>

There isn't an easy way to do exactly what you want.

You could use a chmod in the directory and reapply the ACL to each child 
of the directory.

# chmod A ...

or

# chmod -R A ...

If you want to remove all of the ACLs then

# chmod -R A- 


P.S.

If your using a build older than snv_95 then you will get errors if you 
attempt to set inheritance flags on files.  That problem has been fixed 
in snv_95.

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] force a reset/reinheit zfs acls?

[Mark Shellenbaum]

Rob wrote:
>> Rob wrote:
>>> Hello All!
>>>
>>> Is there a command to force a re-inheritance/reset
>> of ACLs? e.g., if i have a directory full of folders
>> that have been created with inherited ACLs, and i
>> want to change the ACLs on the parent folder, how can
>> i force a reapply of all ACLs?
>>>  
>>>  
>>>
>> There isn't an easy way to do exactly what you want.
> 
> That's unfortunate :(
> How do I go about requesting a feature like this?
>  

You can open an RFE via:

http://www.opensolaris.org/bug/report.jspa

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] C code for reading ZFS ACL

[Mark Shellenbaum]

Paul B. Henson wrote:
> I asked a while back if there was any utility function to evaluate a ZFS
> ACL, I didn't get much of a response and was unable to find anything, so
> decided to implement my own C code.
> 
> It appears the acl_get() function is a convenient way to read the ACL;
> however, I don't see an efficient way to parse the data structure returned.
> 
> The function returns an "acl_t *", which is defined in  as
> "typedef struct acl_info acl_t;"
> 
> The acl_info struct does not appear to be defined in any header files
> shipped with Solaris 10. Browsing the opensolaris code base, I found the
> definition in  to be:
> 
> struct acl_info {
>  acl_type_t acl_type; /* style of acl */
>  int acl_cnt; /* number of acl entries */
>  int acl_entry_size;  /* sizeof acl entry */
>  int acl_flags;   /* special flags about acl */
>  void *acl_aclp;  /* the acl */
> };
> 
> Is the acl_t intentionally designed to be opaque?

Yes, its meant to be opaque.

The layout of the acl_t will likely change in the not too distant future.

> can do with it is pass it to acltotext(), which will return a text string
> describing the ACL.
> 
> It doesn't seem particularly efficient to pass a C structure to a function
> that converts it to a string, and then use C code to parse the text string.
> 
> I would prefer to directly access the acl_info structure.
> 

There are a number of private interfaces in libsec to retrieve stuff out 
of the ACL, but they aren't documented interfaces, such as acl_data() 
which will return you the pointer to the array of ace_t's and acl_cnt() 
that will return you the number of ACEs in the array.  With those two 
interfaces you can then easily iterate over the ACL.

> So either I use the raw underlying system call, which is less than
> desirable, or I use acl_get() but have to perform text parsing, which is
> less than desirable.
> 
> I think I'm inclined to simply copy the data structure definition from
>  into my code so I can access the acl_t directly, which
> probably isn't recommended and will no doubt break if the internal
> implementation changes; but it seems the effort to fix it when it breaks
> would be less than either the effort to use the underlying system call or
> the effort to parse the text.
> 
> Unless I'm missing something? Thanks for any feedback...
> 
> 

We are currently investigating adding more functionality to libsec to 
provide many of the things you desire.  We will have iterators, editing 
capabilities and so on.

   -Mark


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] C code for reading ZFS ACL

[Mark Shellenbaum]

Joe Blount wrote:
> 
>>> Is the acl_t intentionally designed to be opaque?
>>> 
>>
>> Yes, its meant to be opaque.
>>
>> The layout of the acl_t will likely change in the not too distant future.
>>   
> 
> Will old versions be supported?  For example, if ADM 
>  treats it as opaque and 
> archives the current format, after an upgrade (layout change), could we 
> write the old ACL to the new ZFS code?
> 
> thanks,
> Joe

acl_t is a purely in-core data structure, and is not appropriate for 
storing in an archive.  Thats what interfaces such as acl_totext() are 
for.  ADM should be archiving the ACL in a textual representation, much 
like tar/cpio do.

The interfaces such as acl_get()/acl_set() are merely convenience 
functions to make it easier for getting/setting ACLs without having to 
know if the file system is ZFS or UFS.  For example acl_get() knows how 
to determine if a file system supports POSIX draft ACLs or NFSv4 ACL and 
then uses the native acl(2) syscall to retrieve the data.


   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] C code for reading ZFS ACL

[Mark Shellenbaum]

Paul B. Henson wrote:
> On Fri, 15 Aug 2008, Mark Shellenbaum wrote:
> 
>> The layout of the acl_t will likely change in the not too distant future.
> [...]
>> of the ACL, but they aren't documented interfaces, such as acl_data()
>> which will return you the pointer to the array of ace_t's and acl_cnt()
>> that will return you the number of ACEs in the array.  With those two
>> interfaces you can then easily iterate over the ACL.
> 
> Ah, thanks for the pointer. Reviewing the libsec code, I see there is also
> acl_type(), and acl_flags(), but I don't see anything for accessing the
> acl_entry_size. However, both aclent_t and ace_t are publicly documented so
> sizeof() should do the trick.
> 
> Are the libsec undocumented interfaces likely to remain the same when the
> acl_t structure changes? They will still require adding the prototypes to
> my code so the compiler knows what to make of them, but less chance of
> breakage is good.
> 

I can't guarantee they will remain in the future.  Thats why they aren't 
documented.

It may be that with appropriate iterators and other interfaces they will 
no longer be needed.

>> We are currently investigating adding more functionality to libsec to
>> provide many of the things you desire.  We will have iterators, editing
>> capabilities and so on.
> 
> Sweet. Might I request an acl evaluation function? Which basically, given a
> user and a requested permission, returns either true (user has permission),
> false (user doesn't have permission), or error condition. Similar to the
> POSIX access() call, but for ACLs. If I had that I wouldn't need to be
> mucking around with the ACL directly at all :), as that's basically what
> I'm implementing...
> 
> Thanks much, I always appreciate your informative responses.

Yep, the evaluation sort of thing is on our list of things to look into.

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] C code for reading ZFS ACL

[Mark Shellenbaum]

Ian Collins wrote:
> Mark Shellenbaum wrote:
>> Paul B. Henson wrote:
>>> Are the libsec undocumented interfaces likely to remain the same when the
>>> acl_t structure changes? They will still require adding the prototypes to
>>> my code so the compiler knows what to make of them, but less chance of
>>> breakage is good.
>>>
>>> 
>> I can't guarantee they will remain in the future.  Thats why they aren't 
>> documented.
>>
>> It may be that with appropriate iterators and other interfaces they will 
>> no longer be needed.
>>
>>   
> I'm working on a similar problem to Paul (sorry I didn't get back to you
> Paul - shifting priorities!), writing a PHP extension for ACLs, and I've
> fallen into the trap of using acl_info.  Is this work you mention
> happening in the open, or in side of Sun?  If it's the former, how can
> we get involved?
> 
> Ian

Currently we are just doing some preliminary discussions internal to 
Sun?  Were you looking to help out and provide some code? We could 
probably include you in the discussions if you are interested.

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS commands hanging in B95

[Mark Shellenbaum]

Ian Collins wrote:
> I have a pretty standard ZFS boot AMD64 desktop.  A the moment, most ZFS
> related commands are hanging (can't be killed) .  Running 'truss share'
> the last few lines I see are:
> 

Can you provide a kernel thread list report?  You can use mdb -k to get 
that.  Once in mdb type ::threadlist -v


   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS commands hanging in B95

[Mark Shellenbaum]

Ian Collins wrote:
> Mark Shellenbaum wrote:
>> Ian Collins wrote:
>>> I have a pretty standard ZFS boot AMD64 desktop.  A the moment, most ZFS
>>> related commands are hanging (can't be killed) .  Running 'truss share'
>>> the last few lines I see are:
>>>
>> Can you provide a kernel thread list report?  You can use mdb -k to
>> get that.  Once in mdb type ::threadlist -v
>>
> Here you go:
> 

That doesn't appear to be a complete list.  We need to see the ZFS threads.

>> ::threadlist -v
> ADDR PROC  LWP CLS PRIWCHAN
> fbc29420 fbc287b0 fbc2b010   0  960
>   PC: _resume_from_idle+0xf1CMD: sched
>   stack pointer for thread fbc29420: fbc48d60
>   [ fbc48d60 _resume_from_idle+0xf1() ]
> swtch+0x17f()
> sched+0x423()
> main+0x419()
> _locore_start+0x92()
> 
> ff0007a05c80 fbc287b00   0  -10
>   PC: _resume_from_idle+0xf1THREAD: idle()
>   stack pointer for thread ff0007a05c80: ff0007a05c00
>   [ ff0007a05c00 _resume_from_idle+0xf1() ]
> cpu_idle+0xe9()
> idle+0x10e()
> thread_start+8()
> 
> ff0007a0bc80 fbc287b00   0  60 fbcaa8b0
>   PC: _resume_from_idle+0xf1THREAD: thread_reaper()
>   stack pointer for thread ff0007a0bc80: ff0007a0bb90
>   [ ff0007a0bb90 _resume_from_idle+0xf1() ]
> swtch+0x17f()
> cv_wait+0x61()
> thread_reaper+0xb7()
> thread_start+8()
> 
> ff0007a11c80 fbc287b00   0  60 ff01cce37e90
>   PC: _resume_from_idle+0xf1TASKQ: kmem_move_taskq
>   stack pointer for thread ff0007a11c80: ff0007a11b60
>   [ ff0007a11b60 _resume_from_idle+0xf1() ]
> swtch+0x17f()
> cv_wait+0x61()
> taskq_thread+0x11e()
> thread_start+8()
> 
> ff0007a17c80 fbc287b00   0  60 ff01cce37db8
>   PC: _resume_from_idle+0xf1TASKQ: kmem_taskq
>   stack pointer for thread ff0007a17c80: ff0007a17b60
>   [ ff0007a17b60 _resume_from_idle+0xf1() ]
> swtch+0x17f()
> cv_wait+0x61()
> taskq_thread+0x11e()
> thread_start+8()
> 
> ff0007a1dc80 fbc287b00   0  60 ff01cce37ce0
>   PC: _resume_from_idle+0xf1TASKQ: pseudo_nexus_enum_tq
>   stack pointer for thread ff0007a1dc80: ff0007a1db60
>   [ ff0007a1db60 _resume_from_idle+0xf1() ]
> swtch+0x17f()
> cv_wait+0x61()
> taskq_thread+0x11e()
> thread_start+8()
> 
> ff0007a23c80 fbc287b00   0  60 ff01cce37c08
>   PC: _resume_from_idle+0xf1TASKQ: scsi_vhci_nexus_enum_tq
>   stack pointer for thread ff0007a23c80: ff0007a23b60
>   [ ff0007a23b60 _resume_from_idle+0xf1() ]
> swtch+0x17f()
> cv_wait+0x61()
> 
> Ian
> 
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] C code for reading ZFS ACL

[Mark Shellenbaum]

Joe Blount wrote:
> Mark Shellenbaum wrote:
>> Joe Blount wrote:
>>>>> Is the acl_t intentionally designed to be opaque?
>>>>> 
>>>> Yes, its meant to be opaque.
>>>>
>>>> The layout of the acl_t will likely change in the not too distant 
>>>> future.
>>>>   
>>> Will old versions be supported?  For example, if ADM 
>>> <http://www.opensolaris.org/os/project/adm/> treats it as opaque and 
>>> archives the current format, after an upgrade (layout change), could 
>>> we write the old ACL to the new ZFS code?
>>>
>>> thanks,
>>> Joe
>> acl_t is a purely in-core data structure, and is not appropriate for 
>> storing in an archive.  Thats what interfaces such as acl_totext() are 
>> for.  ADM should be archiving the ACL in a textual representation, 
>> much like tar/cpio do.
> We're trying to use DMAPI interfaces for all interaction with the 
> filesystem.  The DMAPI interfaces take a DMAPI handle (fsid & fid), and 
> call the DMAPI kernel driver which uses the handle to get a vnode and do 
> whatever was requested...
> I was hoping to add a DMAPI ACL interface like this - in the kernel get 
> the ACL for a vnode (VOP_GETSECATTR), and convert it to text...  Is 
> there an acl to text interface available in the kernel?
> 

the functions to convert an ACL to/from text aren't available in the 
kernel.  You would only want to archive a non-trivial ACL and you can 
use fs_acl_nontrivial() in the kernel to determine that.

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Snapshots during a scrub

[Mark Shellenbaum]

mike wrote:
> I have a weekly scrub setup, and I've seen at least once now where it
> says "don't snapshot while scrubbing"
> 
> Is this a data integrity issue, or will it make one or both of the
> processes take longer?
> 
> Thank



That problem has been fixed in build 94.

Here is the bug that people have been referring to:

6343667 scrub/resilver has to start over when a snapshot is taken

   -Mark

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Kernel Panic

[Mark Shellenbaum]

David Bartley wrote:
> Hello,
> 
> We're repeatedly seeing a kernel panic on our disk server. We've been unable 
> to determine exactly how to reproduce it, but it seems to occur fairly 
> frequently (a few times a day). This is happening on both snv91 and snv96. 
> We've run 'zpool scrub' and this has reported no errors. I can try to provide 
> more information if needed. Is there a way to turn on more logging/debugging?
> 
> Sep  9 09:32:23 ginseng unix: [ID 836849 kern.notice] 
> Sep  9 09:32:23 ginseng ^Mpanic[cpu1]/thread=ff01598d6820: 
> Sep  9 09:32:23 ginseng genunix: [ID 403854 kern.notice] assertion failed: 0 
> == dmu_bonus_hold(os, fuid_obj, FTAG, &db), file: 
> ../../common/fs/zfs/zfs_fuid.c, line: 116
> Sep  9 09:32:23 ginseng unix: [ID 10 kern.notice] 
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d03010 
> genunix:assfail+7e ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d030b0 
> zfs:zfs_fuid_table_load+1ed ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d03100 
> zfs:zfs_fuid_init+f8 ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d03140 
> zfs:zfs_fuid_find_by_idx+3f ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d031a0 
> zfs:zfs_fuid_map_id+3f ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d03250 
> zfs:zfs_zaccess_common+253 ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d032b0 
> zfs:zfs_zaccess_delete+9f ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d03310 
> zfs:zfs_zaccess_rename+64 ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d03400 
> zfs:zfs_rename+2e1 ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d03490 
> genunix:fop_rename+c2 ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d03770 
> nfssrv:rfs3_rename+3ad ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d03a70 
> nfssrv:common_dispatch+439 ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d03a90 
> nfssrv:rfs_dispatch+2d ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d03b80 
> rpcmod:svc_getreq+1c6 ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d03bf0 
> rpcmod:svc_run+185 ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d03c30 
> rpcmod:svc_do_run+85 ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d03ec0 
> nfs:nfssys+770 ()
> Sep  9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ff0005d03f10 
> unix:brand_sys_sysenter+1e6 ()
> Sep  9 09:32:23 ginseng unix: [ID 10 kern.notice] 
> Sep  9 09:32:23 ginseng genunix: [ID 672855 kern.notice] syncing file 
> systems...
> Sep  9 09:32:23 ginseng genunix: [ID 904073 kern.notice]  done
> Sep  9 09:32:24 ginseng genunix: [ID 111219 kern.notice] dumping to 
> /dev/dsk/c5d1s1, offset 429391872, content: kernel
> Sep  9 09:32:41 ginseng genunix: [ID 409368 kern.notice] ^M100% done: 265125 
> pages dumped, compression ratio 3.52, 
> Sep  9 09:32:41 ginseng genunix: [ID 851671 kern.notice] dump succeeded
> 
> -- David
> --

Have you been using the CIFS server?  You should only be going down that 
path for Windows created files and its trying to load Windows domain SID 
  table.

  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Kernel Panic

[Mark Shellenbaum]

David Bartley wrote:
> On Tue, Sep 9, 2008 at 11:43 AM, Mark Shellenbaum
> <[EMAIL PROTECTED]> wrote:
>> David Bartley wrote:
>>> Hello,
>>>
>>> We're repeatedly seeing a kernel panic on our disk server. We've been
>>> unable to determine exactly how to reproduce it, but it seems to occur
>>> fairly frequently (a few times a day). This is happening on both snv91 and
>>> snv96. We've run 'zpool scrub' and this has reported no errors. I can try to
>>> provide more information if needed. Is there a way to turn on more
>>> logging/debugging?
>>>
>>> -- David
>>> --
>> Have you been using the CIFS server?  You should only be going down that
>> path for Windows created files and its trying to load Windows domain SID
>>  table.
> 
> No. We have a bunch of linux NFS clients. The machines mount from the
> server using a mixture of NFSv3, NFSv4, sys auth, and krb5 auth.
> 

What is the history of this file system?  Was is created prior to snv_77 
and then upgraded?  You most likely have a bad uid/gid on one or more files.

Can you post the dump so I can download it?

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] dataset directory [C1]

[Mark Shellenbaum]

Cyril ROUHASSIA wrote:
> 
> Dear all,
> 
>  From an implementation point of  view, I really do not understand where 
> the list of all datasets lie. I  know  how to to get from the uberblock 
> to the "active dataset" (through MOS and so on)  but once there how to 
> get to others datasets located in the  pool?
> 
> Thank for your answer,
> 
> C Rouhassia
> 

One of the simplest ways to see how the pool hierarchy works is to use 
"zdb -vvv  and then peruse the output.


   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Kernel Panic

[Mark Shellenbaum]

Matthew R. Wilson wrote:
> I can reliably reproduce this panic with a similar stack trace on a
> newly installed Solaris 10 10/08 system (I know, not OpenSolaris but
> it appears to be the same problem). I just opened a support case w/
> Sun but then discovered what appear to be the specific steps for me to
> reproduce it.
> 
> My setup is a Sol10u6 server, with /export/olddata a ZFS filesystem
> with sharenfs=root=zeus.mattwilson.local
> 
> zeus.mattwilson.local is an Ubuntu Linux system. I mount the NFS share
> with no options, just mount athena:/export/olddata /mnt
> 
> What I think is causing the problem is that if I copy a file, as root,
> with owner UID 4294967294 to the Solaris NFS share, using the -a
> option to GNU cp on the Linux box (which, among other things,
> preserves the owner), the panic occurs. Other files, with more
> "reasonable" owners, don't panic the server.
> 
> In my case I can avoid the problem by fixing the bad owner ID on the
> file I'm copying, but not sure if this helps with your situation.
> 

I believe this panic shouldn't happen on OpenSolaris.  It has some extra 
protection to prevent the panic that doesn't exist in the S10 code base.

Are there any ACLs on the parent directory that would be inherited to 
the newly created file you tried to copy? If so what are they?


> My stack was:
> SolarisCAT(vmcore.2/10X)> stack
> unix:vpanic_common+0x165()
> unix:0xfb84d7c2()
> genunix:0xfb9f0c63()
> zfs:zfs_fuid_table_load+0xac()
> zfs:zfs_fuid_init+0x53()
> zfs:zfs_fuid_find_by_idx+0x87()
> zfs:zfs_fuid_map_id+0x47()
> zfs:zfs_fuid_map_ids+0x42()
> zfs:zfs_getattr+0xbc()
> zfs:zfs_shim_getattr+0x15()
> genunix:fop_getattr+0x25()
> nfssrv:rfs4_delegated_getattr+0x9()
> nfssrv:rfs3_setattr+0x19d()
> nfssrv:common_dispatch+0x5b8()
> nfssrv:rfs_dispatch+0x21()
> rpcmod:svc_getreq+0x209()
> rpcmod:svc_run+0x124()
> rpcmod:svc_do_run+0x88()
> nfs:nfssys+0x16a()
> unix:_sys_sysenter_post_swapgs+0x14b()
> -- switch to user thread's user stack --
> 
> panic string:   assertion failed: 0 == dmu_bonus_hold(os, fuid_obj,
> FTAG, &db), file: ../../common/fs/zfs/zfs_fuid.c, line: 95
> 
> 
> On Tue, Sep 9, 2008 at 7:56 AM, Mark Shellenbaum
> <[EMAIL PROTECTED]> wrote:
>> David Bartley wrote:
>>> On Tue, Sep 9, 2008 at 11:43 AM, Mark Shellenbaum
>>> <[EMAIL PROTECTED]> wrote:
>>>> David Bartley wrote:
>>>>> Hello,
>>>>>
>>>>> We're repeatedly seeing a kernel panic on our disk server. We've been
>>>>> unable to determine exactly how to reproduce it, but it seems to occur
>>>>> fairly frequently (a few times a day). This is happening on both snv91 and
>>>>> snv96. We've run 'zpool scrub' and this has reported no errors. I can try 
>>>>> to
>>>>> provide more information if needed. Is there a way to turn on more
>>>>> logging/debugging?
>>>>>
>>>>> -- David
>>>>> --
>>>> Have you been using the CIFS server?  You should only be going down that
>>>> path for Windows created files and its trying to load Windows domain SID
>>>>  table.
>>> No. We have a bunch of linux NFS clients. The machines mount from the
>>> server using a mixture of NFSv3, NFSv4, sys auth, and krb5 auth.
>>>
>> What is the history of this file system?  Was is created prior to snv_77
>> and then upgraded?  You most likely have a bad uid/gid on one or more files.
>>
>> Can you post the dump so I can download it?
>>
>>   -Mark
>> ___
>> zfs-discuss mailing list
>> zfs-discuss@opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>>
> 
> 
> 

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ufsrestore to ZFS

[Mark Shellenbaum]

dick hoogendijk wrote:
> On Sun, 02 Nov 2008 19:47:52 +0100
> [EMAIL PROTECTED] (Joerg Schilling) wrote:
> 
>> Ian Collins <[EMAIL PROTECTED]> wrote:
>>
>>> dick hoogendijk wrote:
 As I understand ufsrestore is independent of the FS it writes to.
 So, I wonder, is it possible to do a pipe from a UFS to a ZFS
 destination like:

 # ufsdump 0f - /dev/rdsk/c0d0s4 | (cd /dest; ufsrestore xf -)
 [ufs-source -> zfs destination]

   
>>> You can, but I don't think ufsdump is ACL aware.
>> ufsdump is ACL aware since 12 years.
>>
>> The problem may be in ufsrestore that IIRC only supports POSIX draft
>> ACLs.
>>
>> If ZFS is able to translate this to NFSv4 ACLs, you may have luck.
> 
> So it might be better to use something like:
> 
> # cd /dir1
> # find . -print -depth | cpio -Ppdm /dir2
> [dir1 on UFS; dir2 on ZFS]
> 

ufsrestore will translate a UFS ACL to a ZFS ACL.  Its all handled in 
the acl_set() interface.

   -Mark

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Files from the future are not accessible on ZFS

[Mark Shellenbaum]

Laurent Blume wrote:
> Hi all,
> 
> It seems a user managed to create files dated Oct 16, 2057, from a Linux 
> distro that mounted by NFS the volumes on an x2100 server running S10U5, with 
> ZFS volumes.
> 
> The problem is, those files are completely unreachable on the S10 server:
> 
> # ls -l .gtk-bookmarks
> .gtk-bookmarks: Value too large for defined data type
> 
> # more .gtk-bookmarks
> .gtk-bookmarks: Value too large for defined data type
> 
> # cp .gtk-bookmarks /tmp
> cp: cannot access .gtk-bookmarks
> 
> # touch .gtk-bookmarks
> touch: .gtk-bookmarks cannot stat
> 

The touch utility was modified a few months ago to deal with out of 
range timestamps.

PSARC 2008/508 allow touch/settime to fix out of range timestamps
6709455 settime should be able to manipulate files with wrong timestamp


-Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Problem with ZFS and ACL with GDM

[Mark Shellenbaum]

> However, I notice that when using ZFS on Indiana the above commands fail
> with the following error:
> 
>File system doesn't support aclent_t style ACL's.
>See acl(5) for more information on ACL styles support by Solaris.
> 
> What is the appropriate command to use with ZFS? 

You can use pathconf() with _PC_ACL_ENABLED to determine what flavor of 
ACL the file system supports.

check out these links.

http://docs.sun.com/app/docs/doc/816-5167/fpathconf-2?a=view
http://blogs.sun.com/alvaro/entry/detecting_the_acl_type_you

The example in the blog isn't quite correct.  The returned value is a 
bit mask, and it is possible for a file system to support multiple ACL 
flavors.

Here is an example of pathconf() as used in acl_strip(3sec)

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libsec/common/aclutils.c#390


   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Problem with ZFS and ACL with GDM

[Mark Shellenbaum]

> 
> ACL's seemed a good solution since it leaves the overall ownership
> and permissions of the device the same, but just adds the gdm user as
> having permission to access the device as needed.  Is there any way to
> get this same sort of behavior when using ZFS.
> 

I think you may have misunderstood what people were suggesting.  They 
weren't suggesting changing the mode of the file, but using chmod(1M) to 
add/modify ZFS ACLs on the device file.

chmod A+user:gdm:rwx:allow 

See chmod(1M) or the zfs admin guide for ZFS ACL examples.


> If not, can people recommend a better way to manage audio device
> permisisons from the login screen?  I know on some Linux distros,
> they make the audio device owned by the "audio" group and ensure that
> the "gdm" user is in the audio group.  Perhaps we should use a similar
> approach on Solaris if ACL isn't a practical solution for all file
> systems.
> 
> Remember that the need to have access to the audio device from the login
> screen is only used to support text-to-speech so that users with certain
> accessibility needs can navigate the login screen.  In other words, it is
> a feature that only a small percentage of users really need, but a
> feature that makes the desktop completely unusable for them if it is not
> present.
> 
> Thoughts?
> 
> Thanks again for all the help,
> 
> Brian
> 
> 
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Problem with ZFS and ACL with GDM

[Mark Shellenbaum]

Brian Cameron wrote:
> Mark & Others:
> 
>> I think you may have misunderstood what people were suggesting.  They 
>> weren't suggesting changing the mode of the file, but using chmod(1M) to 
>> add/modify ZFS ACLs on the device file.
>>
>> chmod A+user:gdm:rwx:allow 
>>
>> See chmod(1M) or the zfs admin guide for ZFS ACL examples.
> 
> Thanks for your help.  Now GDM is using the following code to set ACL's
> (spacing slightly modified for readability):
> 
>   {
>  int acl_flavor;
>  acl_flavor = pathconf("/dev/audio", _PC_ACL_ENABLED);
> 
>  if (acl_flavor & _ACL_ACLENT_ENABLED) {
>  system ("/usr/bin/setfacl -m user:gdm:rwx,mask:rwx
>  /dev/audio");
>  system ("/usr/bin/setfacl -m user:gdm:rwx,mask:rwx
>  /dev/audioctl");
>  } else if (acl_flavor & _ACL_ACE_ENABLED) {
>  system ("/usr/bin/chmod A+user:gdm:rwx:allow
>  /dev/audio");
>  system ("/usr/bin/chmod A+user:gdm:rwx:allow
>  /dev/audioctl");
>  }
>   }
> 
> That works much better, and now GDM text-to-speech works much better on
> ZFS filesystems.
> 
> However, now I am wondering if it might be better to call acl(2) functions
> rather than spawning off new processes via system().  Does setfacl(2), for
> exmaple, work with both flavors, or would I need to call different functions
> based on the acl_flavor?  I am not very familiar with working with
> acl's, so any help explaining how to modify the above code to use acl
> functions rather than calling system would be helpful.
> 
> Thanks,
> 

You could call acl(2) directly, but you would have to construct a 
complete ACL to set. It would be easier to use acl_get() and acl_set() 
which understand the various ACL flavors and will call the syscall with 
correct ACL flavor arguments.

Unfortunately, what you are wanting to do is retrieve the ACL, prepend 
an entry and then call acl_set().  There is a private interface in 
libsec called acl_addentries() that can do such a thing, but that 
interface could change and I'm not sure I would recommend using it since 
gdm isn't in ON.  Also, acl_entries needs the added ACE entries to be in 
raw ace_t format and not the textual representation you are setting with 
chmod(1).  We definately need some better ACL interfaces for this sort 
of thing.

You should probably make sure that you just don't keep continually 
adding the same entry over and over again to the ACL.  With NFSv4 ACLs 
you can insert the same entry multiple times and if you keep doing it 
long enough you will eventually get an error back when you reach the ACE 
limit on the file.

There is code in libdevinfo called setdevaccess() that will strip off 
all ACEs on a device file via acl_strip(3sec).  The setdevaccess() 
interface is called by di_devperm_login().  Does gdm use that interface?

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Problem with ZFS and ACL with GDM

[Mark Shellenbaum]

>> You should probably make sure that you just don't keep continually 
>> adding the same entry over and over again to the ACL.  With NFSv4 ACLs 
>> you can insert the same entry multiple times and if you keep doing it 
>> long enough you will eventually get an error back when you reach the 
>> ACE limit on the file.
> 
> Note that logindevperm will reset the ownership and permission of the
> file each time a user logs in or out.  I guess I was assuming this would
> reset the ACL's as well.  Is this not the case?
> 

Yes, it also changes the owner and group.

> At any rate, it wouldn't hurt to check to see if the ACL is there already.
> Do you have a code example that shows how to do that?
> 

Nope, but you should be able to just use access(2) to determine if you 
need to add the ACL entry.

>> There is code in libdevinfo called setdevaccess() that will strip off 
>> all ACEs on a device file via acl_strip(3sec).  The setdevaccess() 
>> interface is called by di_devperm_login().  Does gdm use that interface?
> 
> Yes, does this mean that the ACL's are getting reset anyway each time a
> user logs in?  If so, then I don't think there is a real need to worry
> about the ACL list getting too long.  Since logindevperm is only used
> for console login, there wouldn't be any issues (for example) in a
> Sun Ray environment where multiple login screens would be showing
> and calling the ACL list at the same time.
> 
> Brian
> 

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Problem with ZFS and ACL with GDM

[Mark Shellenbaum]

Mark Shellenbaum wrote:
>>> You should probably make sure that you just don't keep continually 
>>> adding the same entry over and over again to the ACL.  With NFSv4 ACLs 
>>> you can insert the same entry multiple times and if you keep doing it 
>>> long enough you will eventually get an error back when you reach the 
>>> ACE limit on the file.
>> Note that logindevperm will reset the ownership and permission of the
>> file each time a user logs in or out.  I guess I was assuming this would
>> reset the ACL's as well.  Is this not the case?
>>
> 
> Yes, it also changes the owner and group.
> 
>> At any rate, it wouldn't hurt to check to see if the ACL is there already.
>> Do you have a code example that shows how to do that?
>>
> 
> Nope, but you should be able to just use access(2) to determine if you 
> need to add the ACL entry.
> 

But that probably won't work since you won't be running as that user yet 
and access(2) would be checking off of a privileged cred.

  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] perm/mode is lost on zfs raw device

[Mark Shellenbaum]

Vahid Moghaddasi wrote:
> Hi all,
> We have this problem of losing permission and ownership of the raw zfs 
> devices when the pool is moved from one system to another.
> The owner is an application account and each time we failover to another 
> machine, have to set the permission and owner manually on that server.
> Is this zfs limitation or there is a way to set the perm/owner on the raw 
> devices and keep it across server? 
> Thanks,

Thats a known bug.

6717940 Access control for zvol can't be done by changing permissions to 
the volumes.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] POSIX permission bits, ACEs, and inheritance confusion

[Mark Shellenbaum]

  >> ls -V file
> -rw-r--r--+  1 root root   0 Jan  6 21:42 d
>  user:root:rwxpdDaARWcCos:--:allow
> owner@:--x---:--:deny
> owner@:rw-p---A-W-Co-:--:allow
> group@:-wxp--:--:deny
> group@:r-:--:allow
>  everyone@:-wxp---A-W-Co-:--:deny
>  everyone@:r-a-R-c--s:--:allow
> 
> Can anyone explain to me what just happened? Why are owner/group/everyone 
> ACEs (corresponding to old fashioned POSIX permission bits) created and even 
> more strange, why are deny entries created? Is there something mandating the 
> creation of these ACEs? I can understand that umask might affect this, but I 
> wouldn't have though that it would be causing ACEs to appear out of the blue.
> 
> While writing this, I stumbled into this thread: http://tinyurl.com/7ofxfj. 
> Ok, so it seems that this is "intended" behavior to comply with POSIX. As the 
> author of the thread mentioned, I would like to see an inheritance mode that 
> completely ignores POSIX. The thread ends with Mark Shellenbaum commenting 
> that he will fasttrack "the behavior that many people want". It is not clear 
> to me what exactly he means by this.
> 
> Then I found http://docs.sun.com/app/docs/doc/819-5461/ftyxi?l=zh&a=view and 
> much to my confusion, the deny ACEs aren't created in example 8-10. How could 
> this be? Following some playing around, I came to the conclusion that as long 
> as at least one ACE corresponding to owner/group/everyone exists, the extra 
> ACEs aren't created:
> 

The requested mode from an application is only ignored if the directory 
has inheritable ACES that would affect the mode when aclinherit is set 
to passthrough.  Otherwise the mode is honored and you get the 
owner@,group@ and everyone@ ACEs.


The way a file create works is something like this

1. build up ACL based on inherited ACEs from parent.  This ACL will
often be "emtpy" when no inheritable ACEs exists.

2. Next the chmod algorithm is applied the the ACL in order to make it
reflect the requested mode.  This step is bypassed if the ACL created
in step 1 had any ACEs that affect the mode and aclinherit property
is set to passthrough.

>> mkdir test
>> chmod A=user:root:rwxpdDaARWcCos:fd:allow,everyone@::fd:allow test
>> ls -dV test
> d-+  3 root root  15 Jan  6 22:11 test
>  user:root:rwxpdDaARWcCos:fd:allow
>  everyone@:--:fd:allow
> 
>> cd test
>> touch file
>> ls -V file
> --+  1 root root   0 Jan  6 22:15 file
>  user:root:rwxpdDaARWcCos:--:allow
>  everyone@:--:--:allow
> 
> Not bad at all. However, I contend that this shouldn't be necessary - and I 
> don't understand why the inclusion of just one "POSIX ACE" (empty to boot) 
> makes things work as expected.
> 
> /Peter

We don't have a mode that says completely disregard POSIX.  We try to 
honor the applications mode request except in situations where the 
inherited ACEs would conflict with the requested mode from the application.


-Mark

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] questions on zfs backups

[Mark Shellenbaum]

Ian Collins wrote:
> satya wrote:
>>  Any idea if we can use pax command to backup ZFS acls? will -p option of 
>> pax utility do the trick? 
>>
>>   
> pax should, according to
> http://docs.sun.com/app/docs/doc/819-5461/gbchx?a=view
> 

pax isn't ACL aware.  It does handle extended attributes, though.
Here is pax RFE to support ACLs.

1191280 *pax* pax should understand acls

> tar and cpio do.
> 

tar and cpio handle both ACLs and extended attributes.

> It should be simple enough to test, just generate an archive and have a
> look.
> 

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] CIFS and zfs

[Mark Shellenbaum]

Louis Hoefler wrote:
> But what is the recommended way to share a directory?

You should be able to use sharemgr directly to just share a directory 
and not an entire file system.  If you do that you shouldn't set the 
sharesmb property, though.  Use either the sharesmb property or use 
sharemgr directly.  The CIFS administration guide should have examples 
of using sharemgr.

-Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs smb public share, files created not public

[Mark Shellenbaum]

Roger wrote:
> Hi!
> Im running popensolaris b101 and ive made a zfs pool called tank and an fs 
> inside of it tank/public, ive shared it with smb.
> 
> zfs set sharesmb=on tank/public
> 
> im using solaris smb and not samba.
> 
> The problem is this. When i connect and create a file its readable to 
> everyone but it should be 777. So if i create a file someone else cant erase 
> it. How do i do to get this to work?
> 
> cheers
> -gob

It would be better to ask this question in cifs-disc...@opensolaris.org

I believe the following should get you the results you want.

# chmod A=everyone@:full_set:fd:allow /tank/public

then all cifs created files will have full access and anyone can 
read,write,delete,...

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Problems with '..' on ZFS pool

[Mark Shellenbaum]

Dustin Marquess wrote:
> Forgot to add that a truss shows:
> 
> 14960:  lstat64("/a1000/..", 0xFFBFF7E8)Err#13 EACCES 
> [file_dac_search]
> 
> ppriv shows the error in UFS:
> 
> $ ppriv -e -D -s -file_dac_search ls -ld /a1000/..
> ls[15022]: missing privilege "file_dac_search" (euid = 100, syscall = 216) 
> needed at ufs_iaccess+0x110
> /a1000/..: Permission denied
> 
> However seeing as it only happens for mounts on that 1 ZFS pool, it being a 
> UFS problem seems highly unlikely.

unmount the file system and look at the permission on the UFS mountpoint 
directory /a1000.  They will probably be 0700 or something similar.

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] ZFS core contributor nominations

[Mark Shellenbaum]

The time has come to review the current Contributor and Core contributor 
grants for ZFS.  Since all of the ZFS core contributors grants are set 
to expire on 02-24-2009 we need to renew the members that are still 
contributing at core contributor levels.   We should also add some new 
members to both Contributor and Core contributor levels.

First the current list of Core contributors:

Bill Moore (billm)
Cindy Swearingen (cindys)
Lori M. Alt (lalt)
Mark Shellenbaum (marks)
Mark Maybee (maybee)
Matthew A. Ahrens (ahrens)
Neil V. Perrin (perrin)
Jeff Bonwick (bonwick)
Eric Schrock (eschrock)
Noel Dellofano (ndellofa)
Eric Kustarz (goo)*
Georgina A. Chua (chua)*
Tabriz Holtz (tabriz)*
Krister Johansen (johansen)*

All of these should be renewed at Core contributor level, except for 
those with a "*".  Those with a "*" are no longer involved with ZFS and 
we should let their grants expire.

I am nominating the following to be new Core Contributors of ZFS:

Jonathan W. Adams (jwadams)
Chris Kirby
Lin Ling
Eric C. Taylor (taylor)
Mark Musante
Rich Morris
George Wilson
Tim Haley
Brendan Gregg
Adam Leventhal
Pawel Jakub Dawidek
Ricardo Correia

For Contributor I am nominating the following:
Darren Moffat
Richard Elling

I am voting +1 for all of these (including myself)

Feel free to nominate others for Contributor or Core Contributor.


-Mark



___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS core contributor nominations

[Mark Shellenbaum]

Neelakanth Nadgir wrote:
> +1.
> 
> I would like to nominate roch.bourbonn...@sun.com for his work on
> improving the performance of ZFS over the last few years.
> 
> thanks,
> -neel
> 
> 
+1 on Roch being a core contributor.


> On Feb 2, 2009, at 4:02 PM, Neil Perrin wrote:
> 
>> Looks reasonable
>> +1
>>
>> Neil.
>>
>> On 02/02/09 08:55, Mark Shellenbaum wrote:
>>> The time has come to review the current Contributor and Core  
>>> contributor
>>> grants for ZFS.  Since all of the ZFS core contributors grants are  
>>> set
>>> to expire on 02-24-2009 we need to renew the members that are still
>>> contributing at core contributor levels.   We should also add some  
>>> new
>>> members to both Contributor and Core contributor levels.
>>>
>>> First the current list of Core contributors:
>>>
>>> Bill Moore (billm)
>>> Cindy Swearingen (cindys)
>>> Lori M. Alt (lalt)
>>> Mark Shellenbaum (marks)
>>> Mark Maybee (maybee)
>>> Matthew A. Ahrens (ahrens)
>>> Neil V. Perrin (perrin)
>>> Jeff Bonwick (bonwick)
>>> Eric Schrock (eschrock)
>>> Noel Dellofano (ndellofa)
>>> Eric Kustarz (goo)*
>>> Georgina A. Chua (chua)*
>>> Tabriz Holtz (tabriz)*
>>> Krister Johansen (johansen)*
>>>
>>> All of these should be renewed at Core contributor level, except for
>>> those with a "*".  Those with a "*" are no longer involved with ZFS  
>>> and
>>> we should let their grants expire.
>>>
>>> I am nominating the following to be new Core Contributors of ZFS:
>>>
>>> Jonathan W. Adams (jwadams)
>>> Chris Kirby
>>> Lin Ling
>>> Eric C. Taylor (taylor)
>>> Mark Musante
>>> Rich Morris
>>> George Wilson
>>> Tim Haley
>>> Brendan Gregg
>>> Adam Leventhal
>>> Pawel Jakub Dawidek
>>> Ricardo Correia
>>>
>>> For Contributor I am nominating the following:
>>> Darren Moffat
>>> Richard Elling
>>>
>>> I am voting +1 for all of these (including myself)
>>>
>>> Feel free to nominate others for Contributor or Core Contributor.
>>>
>>>
>>>-Mark
>>>
>>>
>>>
>>> ___
>>> zfs-discuss mailing list
>>> zfs-discuss@opensolaris.org
>>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>> ___
>> zfs-discuss mailing list
>> zfs-discuss@opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> 
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ACL mode inherit issue

[Mark Shellenbaum]

Asif Iqbal wrote:

How do I make sure any new file inherit the group permission from its
directory in ZFS?

I tried to add a non-trivial acl (index id 3), but the files
permissions are still following the users umask

# ls -dv folder/
drwxrwxr-x+  2 root other  3 Mar  6 02:09 folder/
 0:owner@::deny
 1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
 /append_data/write_xattr/execute/write_attributes/write_acl
 /write_owner:allow
 2:group@::deny
 3:group:other:list_directory/read_data/add_file/write_data
 /add_subdirectory/append_data/write_xattr/write_attributes
 /write_acl/write_owner:file_inherit/dir_inherit:allow
 4:group@:list_directory/read_data/add_file/write_data/add_subdirectory
 /append_data/execute:allow
 5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
 /write_attributes/write_acl/write_owner:deny
 6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
 /read_acl/synchronize:allow

I made sure the zfs aclmode is set to passthrough



You will need aclinherit=passthrough for this to work.

Also, in order to bypass the creation mode you will need to inherit at 
least one of the abstract ACEs (owner@, group@ or everyone@).  Those are 
the ACEs that affect the mode of the file.


  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ACL interpretation

[Mark Shellenbaum]

David Dyer-Bennet wrote:

On page 202 of the December 2008 Solaris ZFS Administration Guide, it says
the ACLs are processed in order.  Then it says that an explicit allow ends
processing (or at least it says that a later deny can't override an
earlier allow).

But that's all it says; it doesn't really describe the interpretation
process completely.  I certainly couldn't implement it from this!  And I
can't figure out what my ACLs should mean from this.

In particular, does a matching deny entry also halt processing?  Or does
processing continue, meaning that a later allow can override an earlier
deny?




An ACL is processed from top to bottom.  A "deny" entry  can't take away 
an already granted "allow" nor can a "allow" take away an denied "deny" 
entry.


For example:

user:joe:read_data/write_data:allow
user:joe:write_data:deny

In this case joe would be allowed read_data and write_data

whereas

user:joe:write_data/execute:deny
user:joe:read_data/write_data:allow

would deny "joe" the ability to execute or write_data, but joe could 
still read the files data.


Once a bit has been denied only a privilege subsystem override can give 
you that ability.


  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS ACLs

[Mark Shellenbaum]

Drew Balfour wrote:
I have OSol 2009.06 (b111a), and I'm not sure I'm getting this ZFS ACL 
thing:


%whoami
abalfour
% ls -V file
--+  1 abalfour root 1474560 May 11 18:43 file
 owner@:-w--d--A-W-C--:---:deny

according to that ACL I shouldn't be able to write anything having to do 
with file, correct?


% cat >> file
zsh: permission denied: file
% mv file foo
mv: cannot rename file to foo: Permission denied
% rm file
rm: file: override protection 0 (yes/no)? y
rm: file not removed: Permission denied

So far, so good.

But then I can do this:

% chmod A=owner@:full_set:allow file
% ls -V file
-rwx--+  1 abalfour root 1474560 May 11 18:43 file
 owner@:rwxpdDaARWcCos:---:allow
% rm file
%

I've tried this with all the aclmode values on the filesystem, and it's 
always the same behavior.




aclmode has no bearing on that.  that only comes into play during file 
creation or during a chmod operation.


Am I missing something? Does the owner always have the ability to change 
the ACL to whatever they want?




Nope, the owner always has the ability to fix broken permissions on 
files.  Otherwise the owner would be locked out of their own files.


Here is a similar example on UFS, but without an ACL.

$ touch file
$ chmod 000 file
$ echo this >file
/bin/ksh93: file: cannot create [Permission denied]
$ chmod 644 file

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS ACLs

[Mark Shellenbaum]

abalf...@gmail.com wrote:

On May 21, 2009 11:08am, Mark Shellenbaum  wrote:

 > Nope, the owner always has the ability to fix broken permissions on 
files.  Otherwise the owner would be locked out of their own files.


Nuts; That's what I was trying to do; lock owners into read/write 
without being able to delete.




If you want to prevent deletion then you can always use the nounlink 
attribute.


# chmod S+cu 


Thanks for the info.

-Drew


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ACL not being inherited correctly

[Mark Shellenbaum]

Andrew Watkins wrote:

[I did post this in NFS, but I think it should be here]

I am playing with ACL on snv_114 (and Storage 7110) system and I have 
noticed that strange things are happing to ACL's or am I doing something 
wrong.


When you create a new sub-directory or file the ACL's seem to be incorrect.



Its actually doing exactly what its suppose to do.  See below for 
explanation.



# zfs create  rpool/export/home/andrew
# zfs set aclinherit=passthrough   rpool/export/home/andrew
# zfs set aclmode=passthrough   rpool/export/home/andrew

# chown andrew:staff  /export/home/andrew
# chmod "A+user:oxygen:rwxpdDaARWcCos:fd-:allow" /export/home/andrew

# ls -ldV /export/home/andrew
drwxr-xr-x+  3 andrew   staff  3 Jun 19 17:09 /export/home/andrew
user:oxygen:rwxpdDaARWcCos:fd-:allow
 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

# mkdir /export/home/andrew/foo

# ls -ldV /export/home/andrew/foo
drwxr-xr-x+  2 andrew   staff  2 Jun 19 17:09 
/export/home/andrew/foo

user:oxygen:rwxpdDaARWcCos:fdi---I:allow  <

The entry with the inheritance flags of "fdi" is an inherit only ACE 
which does NOT affect access control and is used for future propagation 
to children of the new directory.


This is done since chmod(2) *may* under some situations alter/reduce the 
permission(s) of ACEs that affect access control.  A chmod(2) operation 
never alters "inherit only" ACEs.  This then allows future 
directories/files to always inherit the same ACL as its parent, or 
parents parent and so on.




user:oxygen:rwxpdDaARWcCos:--I:allow  <

The "I" indicates the ACE was inherited.  This is the ACE that will used 
during access control.


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Creating ZFS filesystem with inherited ACLs ?

[Mark Shellenbaum]

Thomas Fili wrote:

Hi @all,

with ZFS its recommended to create a new filesystem, for example for each user 
to give them a home directory.

So far, so good. The homes should be under tank/export/home/staff and my 
intention is to restrict the ACL rights so only the user self can access his 
own home directory.

I study the ZFS Admin Guide and found the aclmode and aclinherit options, IMHO 
for my intention the following configuration fits my wishes / needs.

zfs set aclmode=discard   tank/export/home/staff
zfs set aclinherit=passthrough-x  tank/export/home/staff

Now i set the ACLs on these staff directory :

/bin/chmod  A=owner@:rwxp---A-W-Cos:---:allow /export/home/staff
/bin/chmod  A1+owner@:rwxp---A-W-Cos:fdi:allow /export/home/staff
/bin/chmod  A2+group@:r-x---a-R-c--s:---:allow /export/home/staff
/bin/chmod  A3+everyone@:--a-R-c--s:fdi:allow /export/home/staff
/bin/chmod  A4+everyone@:--a-R-c--s:---:allow /export/home/staff
 
Creating a "normal" directory resulting in expected mode:


mkdir /export/home/staff/userx

/bin/ls -Vd /export/home/staff/userx

drwx--+  2 root root   2 Jun 22 09:27 /export/home/staff/userx
 owner@:rwxp---A-W-Cos:fdi---I:allow
 owner@:rwxp---A-W-Cos:--I:allow
  everyone@:--a-R-c--s:fdi---I:allow
  everyone@:--a-R-c--s:--I:allow
 

But when creating a new filesystem the ACL stay unchanged 


zfs create tank/export/home/staff/usery

/bin/ls -Vd /export/home/staff/usery

drwxr-xr-x   2 root root   2 Jun 22 09:40 /export/home/staff/usery
 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



I played around with aclmode and aclinherit but creating a new zfs filesystem 
always resulting in the same ACL.

Is this the intended behavior by the developers of ZFS ?


Currently no ACL inheritance takes place when a new file system is 
created.  Feel free to open an RFE for this.




Or is there any posibility to create a filesystem considering inherited ACLs ?


It would be possible with some restrictions.  Such as we must be 
inheriting the aclinherit/aclmode properties and the parent directory 
must also be a ZFS file system and you must be using the default mount 
point.





Thomas


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS attributes for CIFS.

[Mark Shellenbaum]

Kyle McDonald wrote:

Hi all,

I'm setting up a new fileserver, and while I'm not planning on enabling 
CIFS right away, I know I will in the future.


I know there are several ZFS properties or attributes that affect how 
CIFS behaves. I seem to recall that at least one of those needs to be 
set early (like when the filesystem [or pool?] is created?


Which properties might those be?



nbmand, utf8only, casesensitivity.

utf8only and casesensitivity can oly be set when a file system is 
initially created.


For the DOS attribute support you must have a ZPL version 3+ file system.

I believe most of this is described in the CIFS admin guide.


http://docs.sun.com/app/docs/doc/820-2429




Where can I find more info the CIFS/ZFS interaction?

 -Kyle

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Purpose of zfs_acl_split_ace

[Mark Shellenbaum]

Nils Goroll wrote:

Hi,

I just noticed that Mark Shellenbaum has replied to the same question in 
a thread "ACL not being inherited correctly" on zfs-discuss.


Sorry for the noise.

Out of curiosity, I would still be interested in answers to this question:

  It there a reason why inheritable ACEs are  split always, even if the
  particular chmod call would not require splitting them?

For instance, a mode bit change would never influence 
n...@owner/@group/@everyone ACEs and even for the 
@owner/@group/@everyone, one could check if the mode bits are actually 
changed by the chmod call.


Any group entry could have its permissions modified in some situations 
(i.e. group has greater permissions than owner).  Its true that a user 
entry wouldn't necessarily need it, but in order to keep the algorithm 
simpler we just always do the split.


It would be simple enough to exclude user entries from splitting.  Feel 
free to open a bug on this.




Does this make any sense?

Thank you,

Nils
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] [cifs-discuss] [nfs-discuss] Why can't we write to files created in multi-protocol se

[Mark Shellenbaum]

Afshin Salek wrote:

I can't really explain the changes that happen to the file's
ACL using vi over NFS. I'm CC'ing zfs-discuss maybe someone
there can help out.

Afshin



This is caused by vim trying to preserve ACLs and the NFSv3 server 
making some bad assumptions.


What is happening is that vim tries to find out what if any POSIX draft 
ACLs exist on the file.  POSIX draft ACLs aren't supported by ZFS and 
the file system returns ENOSYS.  The NFS server sees this error and is 
afraid that returning that error will cause problems for the client so 
it fabricates an ACL based on the mode bits of the file.  This causes 
"vim" to see an ACL that equates to a mode of 000.  Then after writing 
the data "vim" restores an ACL that equates to the mode.  The NFS server 
actually translates the POSIX draft ACL into a NFSv4 ACL and that is the 
ACL you actual see on the file after the exiting "vim".


Here is the snipit of code from NFS that actually causes the problem
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs_acl_srv.c#98

The assumption made in the comment really aren't accurate anymore. 
Solaris can generally deal with an error from VOP_GETSECATTR() now and 
probably predates ZFS being integrated into ON.


There are a couple of ways to work around the problem.

- Recompile "vim" without ACL support.
- Use NFSv4 instead of NFSv3

This really should be a bug that needs to be investigated by the NFS 
team to determine if/when they really need to fabricate an ACL.  I would 
guess they probably don't need to do that anymore.


  -Mark



John Keiffer wrote:

Looks like this:

n...@leo-ha2:/$ ls -Vd ha2/f1/
drwxr-xr-x+  3 enguser  root   4 Jul  1 14:51 ha2/f1/
   user:smb:rwxp-D-ARW-Co-:---:allow
   user:nfs:rwxp-D-ARW-Co-:---:allow
 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

Thanks,
John

-Original Message-
From: afshin.ardak...@sun.com [mailto:afshin.ardak...@sun.com] Sent: 
Wednesday, July 01, 2009 6:17 PM

To: John Keiffer
Cc: cifs-disc...@opensolaris.org
Subject: Re: [cifs-discuss] [nfs-discuss] Why can't we write to files 
created in multi-protocol se


How does the ACL for 'f1' look like?

Afshin

John Keiffer wrote:
Well... I may have had an idamp problem before, which I believe I've 
now corrected. This is my current idamp config:


add "wingroup:Domain us...@matrix.lab"  unixgroup:group2
add winuser:engu...@matrix.lab  unixuser:enguser
wingroup:Domain adm...@matrix.lab   ==  gid:2147483650
wingroup:Authenticated Users==  gid:2147483651
wingroup:Network==  gid:2147483652
wingroup:administrat...@builtin ==  gid:2147483653


I still have some questions regarding access from both CIFS and NFS:

After steping on the file from Linux and vi with the ! I believe it 
reordered the ACL's like this:


n...@leo-ha2:/$ ls -V ha2/f1/
total 2
--+  1 enguser  group2 6 Jul  1 14:32 cifs.txt
   group:group2:rwxp--:---:deny
  everyone@:r-xCo-:---:deny
   group:group2:-s:---:allow
   user:enguser:rwxpdDaARWcCos:fd-:allow
  everyone@:--a-R-c--s:---:allow

Which means that when I try and access it from Windows I can't, 
because group2 has write deny (among other things). If I remove the 
user ACL and insert it at the beginning, I can write again from 
Windows...


n...@leo-ha2:/$ chmod A3- ha2/f1/cifs.txt

n...@leo-ha2:/$ chmod A0+user:enguser:rwxpdDaARWcCos:fd-:allow 
ha2/f1/cifs.txt

n...@leo-ha2:/$ ls -V ha2/f1/
total 2
--+  1 enguser  group2 6 Jul  1 14:32 cifs.txt
   user:enguser:rwxpdDaARWcCos:fd-:allow
   group:group2:rwxp--:---:deny
  everyone@:r-xCo-:---:deny
   group:group2:-s:---:allow
  everyone@:--a-R-c--s:---:allow

Until I ! save it again from Linux, because then the ACLs are changed 
(such that nobody can do much of anything because of the deny lines):


n...@leo-ha2:/$ ls -V ha2/f1/cifs.txt
--   1 enguser  group227 Jul  1 14:48 ha2/f1/cifs.txt
 owner@:rwxp--:---:deny
 owner@:---A-W-Co-:---:allow
 group@:rwxp--:---:deny
 group@:--:---:allow
  everyone@:rwxp---A-W-Co-:---:deny
  everyone@:--a-R-c--s:---:allow

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


___
z

Re: [zfs-discuss] [cifs-discuss] [nfs-discuss] Why can't we write to files created in multi-protocol se

[Mark Shellenbaum]

John Keiffer wrote:

Mark,

Does it matter that the share IS mounted nfsv4?



I'm not sure.  In a cursory look at the nfsv4 server code it looks like 
it would also fabricate an ACL.  I don't know what translations if any 
the linux client does before sending it over to Solaris.  I will CC 
nfs-disc...@opensolaris.org and couple of engineers who will most likely 
know.


  -Mark


From the client:

bash-3.1$ mount
:/volumes/ha2/f1 on /mnt/leo1/nfsv3 type nfs4 (rw,addr=)

bash-3.1$ pwd
/mnt/leo1/nfsv3

bash-3.1$ nfs4_getfacl .
A::s...@matrix:rwaDxTnNCo
A::nobody:rwaDxTnNCo
D::OWNER@:
A::OWNER@:rwaxTNCo
D:g:GROUP@:wa
A:g:GROUP@:rx
D::EVERYONE@:waTC
A::EVERYONE@:rxtncy

bash-3.1$ nfs4_getfacl cifs.txt
D::OWNER@:rwax
A::OWNER@:TNCo
D:g:GROUP@:rwax
A:g:GROUP@:
D::EVERYONE@:rwaxTC
A::EVERYONE@:tncy

This system can't do 'ls -V', so I'm having to use nfs4_getfacl instead (not as 
convienient).

Thanks,
John

-Original Message-
From: mark.shellenb...@sun.com [mailto:mark.shellenb...@sun.com] 
Sent: Thursday, July 02, 2009 6:16 AM

To: Afshin Salek
Cc: John Keiffer; zfs-discuss@opensolaris.org; cifs-disc...@opensolaris.org
Subject: Re: [zfs-discuss] [cifs-discuss] [nfs-discuss] Why can't we write to 
files created in multi-protocol se

Afshin Salek wrote:

I can't really explain the changes that happen to the file's
ACL using vi over NFS. I'm CC'ing zfs-discuss maybe someone
there can help out.

Afshin



This is caused by vim trying to preserve ACLs and the NFSv3 server 
making some bad assumptions.


What is happening is that vim tries to find out what if any POSIX draft 
ACLs exist on the file.  POSIX draft ACLs aren't supported by ZFS and 
the file system returns ENOSYS.  The NFS server sees this error and is 
afraid that returning that error will cause problems for the client so 
it fabricates an ACL based on the mode bits of the file.  This causes 
"vim" to see an ACL that equates to a mode of 000.  Then after writing 
the data "vim" restores an ACL that equates to the mode.  The NFS server 
actually translates the POSIX draft ACL into a NFSv4 ACL and that is the 
ACL you actual see on the file after the exiting "vim".


Here is the snipit of code from NFS that actually causes the problem
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs_acl_srv.c#98

The assumption made in the comment really aren't accurate anymore. 
Solaris can generally deal with an error from VOP_GETSECATTR() now and 
probably predates ZFS being integrated into ON.


There are a couple of ways to work around the problem.

- Recompile "vim" without ACL support.
- Use NFSv4 instead of NFSv3

This really should be a bug that needs to be investigated by the NFS 
team to determine if/when they really need to fabricate an ACL.  I would 
guess they probably don't need to do that anymore.


   -Mark



John Keiffer wrote:

Looks like this:

n...@leo-ha2:/$ ls -Vd ha2/f1/
drwxr-xr-x+  3 enguser  root   4 Jul  1 14:51 ha2/f1/
   user:smb:rwxp-D-ARW-Co-:---:allow
   user:nfs:rwxp-D-ARW-Co-:---:allow
 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

Thanks,
John

-Original Message-
From: afshin.ardak...@sun.com [mailto:afshin.ardak...@sun.com] Sent: 
Wednesday, July 01, 2009 6:17 PM

To: John Keiffer
Cc: cifs-disc...@opensolaris.org
Subject: Re: [cifs-discuss] [nfs-discuss] Why can't we write to files 
created in multi-protocol se


How does the ACL for 'f1' look like?

Afshin

John Keiffer wrote:
Well... I may have had an idamp problem before, which I believe I've 
now corrected. This is my current idamp config:


add "wingroup:Domain us...@matrix.lab"  unixgroup:group2
add winuser:engu...@matrix.lab  unixuser:enguser
wingroup:Domain adm...@matrix.lab   ==  gid:2147483650
wingroup:Authenticated Users==  gid:2147483651
wingroup:Network==  gid:2147483652
wingroup:administrat...@builtin ==  gid:2147483653


I still have some questions regarding access from both CIFS and NFS:

After steping on the file from Linux and vi with the ! I believe it 
reordered the ACL's like this:


n...@leo-ha2:/$ ls -V ha2/f1/
total 2
--+  1 enguser  group2 6 Jul  1 14:32 cifs.txt
   group:group2:rwxp--:---:deny
  everyone@:r-xCo-:---:deny
   group:group2:-s:---:allow
   user:enguser:rwxpdDaARWcCos:fd-:allow
  everyone@:--a-R-c--s:---:allow

Which means that when I try and access it from Windows I can't, 
because group2 has write deny (among other things). If I remove the 
user ACL and insert it at the beginning, I can write again from 
Windows...


n...@leo-ha2

Re: [zfs-discuss] Why is Solaris 10 ZFS performance so terrible?

[Mark Shellenbaum]

Bob Friesenhahn wrote:
There has been no forward progress on the ZFS read performance issue for 
a week now.  A 4X reduction in file read performance due to having read 
the file before is terrible, and of course the situation is considerably 
worse if the file was previously mmapped as well.  Many of us have sent 
a lot of money to Sun and were not aware that ZFS is sucking the life 
out of our expensive Sun hardware.


It is trivially easy to reproduce this problem on multiple machines. For 
example, I reproduced it on my Blade 2500 (SPARC) which uses a simple 
mirrored rpool.  On that system there is a 1.8X read slowdown from the 
file being accessed previously.


In order to raise visibility of this issue, I invite others to see if 
they can reproduce it in their ZFS pools.  The script at


http://www.simplesystems.org/users/bfriesen/zfs-discuss/zfs-cache-test.ksh

Implements a simple test.  It requires a fair amount of disk space to 
run, but the main requirement is that the disk space consumed be more 
than available memory so that file data gets purged from the ARC. The 
script needs to run as root since it creates a filesystem and uses 
mount/umount.  The script does not destroy any data.


There are several adjustments which may be made at the front of the 
script.  The pool 'rpool' is used by default, but the name of the pool 
to test may be supplied via an argument similar to:


# ./zfs-cache-test.ksh Sun_2540
zfs create Sun_2540/zfscachetest
Creating data file set (3000 files of 8192000 bytes) under 
/Sun_2540/zfscachetest ...

Done!
zfs unmount Sun_2540/zfscachetest
zfs mount Sun_2540/zfscachetest



I've opened the following bug to track this issue:

6859997 zfs caching performance problem

We need to track down if/when this problem was introduced or if it has 
always been there.



   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS file permissions - some files missing over SMB?

[Mark Shellenbaum]

Chris Murray wrote:

Hello,

Hopefully a quick and easy permissions problem here, but I'm stumped and 
quickly reached the end of my Unix knowledge.

I have a ZFS filesystem called "fs/itunes" on pool "zp". In it, the "iTunes 
music" folder contained a load of other folders - one for each artist.

During a resilver operation which was going to take a week, I decided to delete this data 
(amongst other things) and restore it from backup once the resilver was complete. It 
finished on Sunday night, so I started copying content from my Windows machine + an NTFS 
external disk, to "/zp/fs/itunes/iTunes music", using winscp.

Now, if I browse to that folder over SMB from the Windows machine, I have a subset of all of the 
artist names, and I can't identify exactly why some are there and others aren't. I'm accessing it 
using the "sharesmb=on" option, and user "chris".

So:
*  "\\mammoth\itunes\iTunes music" contains *some* folders.
*  If I winscp using user "chris" and browse to the same folder, everything is 
there.
*  Inspecting the properties on a folder that is visible, I see that it has group "staff", owner 
"chris", and permissions "0777".
*  A one that is visible in winscp but NOT through Windows has the same ... ?!

I'm not sure what I've done here, but clearly there's something I don't understand about 
permissions. If I try to create one of the missing folders through Windows, I'm told 
"Cannot rename New Folder: A file with the name you specified already exists. 
Specify a different file name.", so they appear to be hidden from view in some way.

Thanks in advance,
Chris


This is better asked on cifs-disc...@opensolaris.org

The first thing they will ask you to do is to run

http://opensolaris.org/os/project/cifs-server/files/cifs-gendiag


  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] sharenfs question

[Mark Shellenbaum]

dick hoogendijk wrote:

# zfs create store/snaps
# zfs set sharenfs='rw=arwen,root=arwen' store/snaps
# share
-...@store/snaps   /store/snaps   sec=sys,rw=arwen,root=arwen   ""  


arwen# zfs send -Rv rp...@0906 > /net/westmark/store/snaps/rpool.0906
zsh: permission denied: /net/westmark/store/snaps/rpool.0906

*** BOTH systems have NFSMAPID DOMAIN=nagual.nl set in the
*** file /etc/default/nfs

The NFS docs mention that the rw option can be a node (like arwen).
But as you can see I get no access when I set rw=arwen.
And yet arwen is known!
This rule works:
#zfs set sharenfs='root=arwen' store/snaps
The snapshots are send from arwen to the remote machine and get the
root:root privileges. So that,s OK.
This rule does NOT work:
# zfs set sharenfs='rw=arwen,root=arwen' store/snaps
I get a permission denied. Apparently rw=arwen is nog reckognized.

Is something wrong in the syntax the way ZFS uses sharenfs?
Or have I misread the manual of share_nfs?
What can be wrong is the line "zfs set sharenfs='rw=arwen,root=arwen'
store/snaps"



I would suggest you open a bug on this.  You can use either bugzilla or 
bugster:


http://defect.opensolaris.org/bz/
http://bugs.opensolaris.org/

This issue does have some similarities with the following bug, but its 
different enough to warrant its own bug


http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6856710


  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS CIFS problem with Ubuntu, NFS as an alternative?

[Mark Shellenbaum]

Christian Flaig wrote:

Hello,

I got a very strange problem here, tried out many things, can't solve it.
I run a virtual machine via VirtualBox 2.2.4, with Ubuntu 9.04. OpenSolaris as the host 
is 2009-06, with snv118. Now I try to mount (via CIFS) a share in Ubuntu from 
OpenSolaris. Mounting is successful, I can see all files, also change directories. But I 
can't read the files! Whenever I try to copy a file, I get a "Permission 
denied" from Ubuntu. But when I mount the same share in Windows XP, I can read the 
files also. So might be an Ubuntu issue, anyone also experienced this? Any logs I can 
check/configure to find out more?
Here the permissions for the directory (tmns is the user I use for mounting):
dr-xr-xr-x+ 31 chrisstaff588 Aug  4 23:57 video
  user:tmns:r-x---a-R-c---:fd-:allow
 user:chris:rwxpdDaARWcCos:fd-:allow
(The "x" shouldn't be necessary, but XP seems not able to list subdirectories 
without it...)

So I thought about using NFS instead, which should be better for an Unix - Unix 
connection anyway. But here I face another issue, which might be because of 
missing knowledge about NFS...
I share the "video" directory above with the ZFS sharenfs command, options are "anon=0,ro". Without 
"anon=0" I always get a "Permission denied" when I want to mount the share via NFS on Ubuntu (mounting with 
root user). But with "anon=0" I can only read the files on the Ubuntu side with root, the mounted directory had 
numerical ids for owner and group on the Ubuntu side.
Any clue how I can solve this?

Many thanks for your help, I'm not sure how to progress on this...

Cheers,

Chris



This is better asked on cifs-disc...@opensolaris.org

They will start out by asking you to run:

http://opensolaris.org/os/project/cifs-server/files/cifs-gendiag


  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] `zfs list -t filesystem` shouldn't return snapshots

[Mark Shellenbaum]

Robert Lawhead wrote:

I recently tried to post this as a bug, and received an auto-ack, but can't 
tell whether its been accepted.  Does this seem like a bug to anyone else?

Default for zfs list is now to show only filesystems.  However, a `zfs list` or 
`zfs list -t filesystem` shows filesystems AND incomplete snapshots, and
`zfs list -t snapshot` doesn't show incomplete snapshots.

Steps to Reproduce
  # start a send|receive, and DO NOT wait for it to finish...
zfs snapshot f...@bar && (zfs send f...@bar | zfs receive -F baz) &
# See where snapshot being created is reported; it will be reported
# with filesystems (wrong) and not with snapshots (wrong again).
zfs list
zfs list -t filesystem
zfs list -t snapshot

Expected Result
  Snapshot in progress should be reported with snapshots (I think) and 
definitely not with filesystems.  Necessitates filtering like '| grep -v -- %'


That was closed as a duplicate of:

6759986 zfs list shows temporary %clone when doing online zfs recv

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6759986
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] *Almost* empty ZFS filesystem - 14GB?

[Mark Shellenbaum]

Chris Murray wrote:

Nico, what is a zero-link file, and how would I go about finding whether I have 
one? You'll have to bear with me, I'm afraid, as I'm still building my Solaris 
knowledge at the minute - I was brought up on Windows. I use Solaris for my 
storage needs now though, and slowly improving on my knowledge so I can move 
away from Windows one day  :)

If it makes any difference, the problem persists after a full reboot, and I've 
deleted the three folders, so now there is literally nothing in that filesystem 
.. yet it reports 14GB.

It's not too much of an inconvenience, but it does make me wonder whether the 
'used' figures on my other filesystems and zvols are correct.



You could be running into an instance of

6792701 Removing large holey file does not free space

A fix for this was integrated into build 118


  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS Export, Import = Windows sees wrong groups in ACLs

[Mark Shellenbaum]

Owen Davies wrote:

I had a OpenSolaris server running basically as a fileserver for all my windows 
machines.  The CIFS server was running in WORKGROUP mode.  I had several users 
defined on the server to match my windows users.  I had these users in a few 
groups (the most important being Parents and Kids).

For various reasons I decided to blow away the OS and install fresh.  First I exported the zpool holding my shared files.  I then rebuilt the server, created the same users, granted the same group memberships and finally imported my zpool.  


Unfortunately, the GIDs for the Parents and Kids groups must have been swapped 
when I rebuilt because I found that the Kids had full control of everything and 
Parents had read only access.  What is the right way to correct this?

I tried editing the /etc/group file to swap the GIDs but this didn't seem to 
have the effect I wanted.  Now, when I view the ACLs with an ls -V from the 
OSOL side I see that the Parents group has full permissions but from the 
Windows side these folders show that HOMESERVER\Kids group has full control.

I know ZFS keeps the Windows style SIDs in the ACLs across export/import but 
how am I supposed to get the users/groups I created during the rebuild to match 
up with the old SIDs?  Where is Windows getting a different idea of who that 
group is that OSOL has?  There is no Active Directory or other LDAP which could 
have maintained a definition of those SIDs over the rebuild.

Thanks,
Owen Davies


How are the parent and kids defined in the /etc/passwd file?

What do the ACLs look like?

Issues with the CIFS server are best served by asking on 
cifs-disc...@opensolaris.org



  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Which kind of ACLs does tmpfs support ?

[Mark Shellenbaum]

Roland Mainz wrote:

Hi!



Does anyone know out-of-the-head whether tmpfs supports ACLs - and if
"yes" - which type(s) of ACLs (e.g. NFSv4/ZFS, old POSIX draft ACLs
etc.) are supported by tmpfs ?



tmpfs does not support ACLs

see _PC_ACL_ENABLED in [f]pathconf(2).  You can query the file system 
for what type of ACLs it supports.





Bye,
Roland




___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] status of user delegation

[Mark Shellenbaum]

Darren J Moffat wrote:
Is there a time line for when we should expect the integration of the 
user delegation functionality ?  I'm desperately waiting for it and I 
keep seeing new functionality that was approved after it integrating and 
I'm wondering when it is coming.


Anything I can do to help (mainly since I think it is an important 
usability partner to crypto).


Thanks.



I'm waiting for the in kernel sharetab support to be integrated.  Once 
thats available I can add user level NFS share support.  I would expect 
it about a month after the sharetab support is integrated.  The sharetab 
code is going through final testing now.


  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] status of user delegation

[Mark Shellenbaum]

Al Hopper wrote:

On Fri, 16 Mar 2007, Mark Shellenbaum wrote:


Darren J Moffat wrote:

Is there a time line for when we should expect the integration of the
user delegation functionality ?  I'm desperately waiting for it and I
keep seeing new functionality that was approved after it integrating and
I'm wondering when it is coming.

Anything I can do to help (mainly since I think it is an important
usability partner to crypto).

Thanks.


I'm waiting for the in kernel sharetab support to be integrated.  Once


In German "was das ist"[1] or "what is that"?



That is moving /etc/dfs/sharetab into the kernel, much like /etc/mnttab is.


thats available I can add user level NFS share support.  I would expect


OK - maybe I've missed something on the 15 or so OpenSolaris lists I'm
subscribed to ... but (at the risk of appearing totally stupid) "was ist
das"?



That is to allow a non-privileged the ability to perform an NFS share of 
a ZFS file system.  This assumes the user has the necessary dataset 
permission to allow th operation.  For example:


# zfs allow marks share sandbox/fs

marks$ zfs share sandbox/fs
marks$

If 'marks' tries to share sandbox/otherfs, he will receive an error 
since he doesn't have 'share' permission on that dataset.


marks$ zfs share sandbox/otherfs
cannot share 'sandbox/otherfs': /sandbox/otherfs: no permission


  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] migration/acl4 problem

[Mark Shellenbaum]

Jens Elkner wrote:

Hi,



2) On zfs
- e.g. as root do:
cp -P -r -p /dir /pool1/zfsdir
# cp: Insufficient memory to save acl entry


I will open a bug on that.


cp  -r -p /dir /pool1/zfsdir
# cp: Insufficient memory to save acl entry
find dir | cpio -puvmdP /pool1/docs/
- as user B do:
cd /pool1/zfsdir/dir
touch y
- as user A do:
cd /pool1/zfsdir/dir
echo "bla" >y


I can't reproduce your simple test.

I have two user tester1 and tester2 and both are members of tstgroup
tester1$ mkdir a.dir
tester1$ chmod 775 a.dir
tester1$ setfacl -m d:u::rwx,d:g::rwx,d:o:r-x,d:m:rwx a.dir
# su - tester2
tester2$ cd a.dir
tester2$ touch b
tester2$ ls -l b
total 0
-rw-rw-r--   1 tester2  tstgrp 0 Mar 22 08:21 b

# find a.dir -print | cpio -Pvmudp /sandbox
/sandbox/a.dir
/sandbox/a.dir/b
0 blocks

tester1$ cd /sandbox/a.dir
tester1$ touch a
# su tester2
tester2$ touch c
tester2$ ls -l
total 3
-rw-r--r--+  1 tester1  tstgrp 0 Mar 22 08:22 a
-rw-rw-r--+  1 tester2  tstgrp 0 Mar 22 08:21 b
-rw-r--r--+  1 tester2  tstgrp 0 Mar 22 08:22 c


There is one big difference which you see here.  ZFS always honors the 
users umask, and that is why the file was created with 644 permission 
rather than 664 as UFS did.  ZFS has to always apply the users umask 
because of POSIX.




So, has anybody a clue, how one is able to migrate directories from
ufs to zfs without loosing functionality?

I've read, that it is always possible to translate POSIX_ACLs to ACL4,
but it doesn't seem to work. So I've a big migration problem ... :(((

Also I haven't found anything, which explain, how ACL4 really works on
Solaris, i.e. how the rules are applied. Yes, in order and only "who"
matches. But what means '"who"  matches', what purpose have the
'owner@:--:--:deny'  entries, what takes precendence
(allow | deny | first match | last match), also I remember, that
sometimes I heard, that if allow once matched, everything else is
ignored - but than I' askling, why the order of the ACLEs are important.
Last but not least, what purpose have the standard perms e.g. 0644 -
completely ignored if ACLEs are present ? Or used as fallback, if no
ACLE matches or ACLE match, but have not set anywhere e.g. the r bit ?

Any hints?

Regards,
jel.


owner@ entries control the owner permissions
group@ entries control the owning group permissions
everyone@ entries control everyones permissions, not just the other 
permissions.


A little example will illustrate what everyone@ does.
# chmod A=owner@:r:allow,group@:r:allow,everyone@:rwx:allow file.test
# ls -V file.test
-rwxrwxrwx   1 tester1  tstgrp 0 Mar 22 08:29 file.test
owner@:r-:--:allow
group@:r-:--:allow
 everyone@:rwx---:--:allow

Since everyone@ is giving away rwx and there are no deny entries for 
either  owner@ or group@ the mode of the file becomes 777 and all users 
can rwx the file.


Now if I insert a deny before the group entry the mode will change.
# chmod A1+group@:wx:deny file.test
# ls -V file.test
-rwxr--rwx   1 tester1  tstgrp 0 Mar 22 08:29 file.test
owner@:r-:--:allow
group@:-wx---:--:deny
group@:r-:--:allow
 everyone@:rwx---:--:allow

Now the anyone who isn't a member of tstgroup has rwx permission to the 
file.


The ACEs are processed in order and once a requested permission has been 
granted a subsequent deny can't take it away, but if a permission has 
yet been granted then a deny for that permission will halt the access check.


For example:

# ls -V file.test
-rw-r--r--+  1 tester1  tstgrp 0 Mar 22 08:35 file.test
  user:tester2:rwx---:--:allow
  user:tester2:-w:--:deny
owner@:--x---:--:deny
owner@:rw-p---A-W-Co-:--:allow
group@:-wxp--:--:deny
group@:r-:--:allow
 everyone@:-wxp---A-W-Co-:--:deny
 everyone@:r-a-R-c--s:--:allow

In this ACL the deny entry for 'w' for tester2 has no effect, since 'w' 
would have already been granted.  If the first two entries had been 
swapped then tester2 would be denied write permission.


A normal file that doesn't really have an ACL will have a number of deny 
entries inserted into the ACL.  The reason for this is to provide POSIX 
compliance in that you are either in the owner class, group class or 
other class.  The deny entries stop the access control from proceeding 
to the next entries.  In the ACL shown below the deny entries on the 
group@ entry will prevent a member of tstgrp from picking up write 
permission from the everyone@ allow entry.


# touch file.2
# ls -V file.2
-rwxr-xrwx   1 tester1  tstgrp 0 Mar 22 08:39 file.2
owner@:--

Re: [zfs-discuss] migration/acl4 problem

[Mark Shellenbaum]

There is one big difference which you see here.  ZFS always honors the 
users umask, and that is why the file was created with 644 permission 
rather than 664 as UFS did.  ZFS has to always apply the users umask 
because of POSIX.


Wow, that's a big show stopper! If I tell the users, that after the
transition they have to toggle their umask before/after writing to
certain directories or need to do a chmod, I'm sure they wanna hang me
right on the next tree and wanna get their OS changed to Linux/Windooze...



Only if your goal is to ignore a users intent on what permissions their 
files should be created with.  Think about users who set their umask to 
077.  They will be upset when their files are created with a more 
permissive mode.  The ZFS way is much more secure.


What is your real desired goal?  Are you just wanting anybody in a 
specific group to be able to read,write all files in a certain directory 
tree?  If so, then there are other ways to achieve this, with file and 
directory inheritance.



Isn't there a flag/property for zfs, to get back the old behavior
or to enable POSIX-ACLs instead of zfs-ACLs?
A "force_directory_create_mode=0770,force_file_create_mode=0660'
(like for samba shares) property would be even better - no need to fight
with ACLs...


That would be bad.  That would mean that every file in a file system 
would be forced to be created with forced set of permissions.


  -Mark


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] migration/acl4 problem

[Mark Shellenbaum]

Please explain how. I've been trying to make this work for months with
no success.

The business requirement is that all files in a directory hierarchy be 
created

mode 660 - read and write by owner and primary group. How do I do
this?



# zfs set aclmode=passthrough 
# mkdir dir.test

# chmod A+group:::fd:allow dir.test

create files and directories under dir.test.

This should allow anyone in the the desired group to read/write all 
files, and the passthrough of aclmode stops chmod(2) from prepending 
deny entries.


  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] migration/acl4 problem

[Mark Shellenbaum]

It looks like we're between a rock and a hard place. We want to use
ZFS for one project because of snapshots and data integrity - both
would give us considerable advantages over ufs (not to mention
filesystem size). Unfortunately, this is critical company data and the
access control has to be exactly right all the time: the default
ACLs as implemented in UFS are exactly what we need and work
perfectly.



The original plan was to allow the inheritance of owner/group/other 
permissions. Unfortunately, during ARC reviews we were forced to remove 
that functionality, due to POSIX compliance and security concerns.


We can look into alternatives to provide a way to force the creation of 
directory trees with a specified set of permissions.


 -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] migration/acl4 problem

[Mark Shellenbaum]

Peter Tribble wrote:

On 3/23/07, Mark Shellenbaum <[EMAIL PROTECTED]> wrote:


The original plan was to allow the inheritance of owner/group/other
permissions. Unfortunately, during ARC reviews we were forced to remove
that functionality, due to POSIX compliance and security concerns.


What exactly is the POSIX compliance requirement here?


The ignoring of a users umask.


(It's also not clear to me how *not* allowing control of permissions
helps security in any way.)



___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] migration/acl4 problem

[Mark Shellenbaum]

Peter Tribble wrote:

On 3/23/07, Mark Shellenbaum <[EMAIL PROTECTED]> wrote:

Peter Tribble wrote:
> What exactly is the POSIX compliance requirement here?
>
The ignoring of a users umask.


Where in POSIX does it specify the interaction of ACLs and a
user's umask?



Let me try and summarize the discussion that took place, a few years ago.

The POSIX ACL draft stated:

p 269: "The process umask is the user's way of specifying security for
newly created objects. It was a goal to preserve this behavior
//unless it is specifically overridden in a default ACL//."

However, that is a withdrawn specification and Solaris is required to 
conform to a set of "approved standards".


The main POSIX specification doesn't say anything specific about ACLs, 
but rather alternate and additional access control methods.


POSIX gives clear rules for file access permissions based on umask, file 
mode bits, additional access control mechanisms, and alternate access 
control mechanisms.  Most of this is discussed in section 2.3 "General 
Concepts".


Since there is nothing in the spec that states that we *can* ignore the 
umask, we are therefore forced to honor it.  At least until we find a 
way to



I will open an RFE to look into alternative ways to work around this issue.


  -Mark

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Re: delete acl not working on zfs.v3?

[Mark Shellenbaum]

Carson Gaspar wrote:

we give the right to add folder to user foo.(this
user can not delete anything as a default) After that
we give the right create file.And then user foo gains
delete everthing. How come is it possible.
Even though we add another rule like
"0:user:foo:delete_child/delete:deny". Again it does
not work . Why please somebody answer this strange
situation.


I can't find any response to this query from last August. I can confirm that on 
a Solaris 10 U3 fully patched server that the 'delete_child' ACL is being 
ignored in ZFS. Deletion is only controlled by the 'add_file' ACL.  I'm fairly 
certain that this is in violation of the NFSv4 spec, which zfs claims to 
implement.

The "sticky bit" on a directory is also not reflected in the ACLs output by 'ls 
-dv', although it appears to work as usual. I have a nasty suspicion that this is related.



Can you post the full ACL on the directory and on the file you are being 
allowed to delete.


  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Re: delete acl not working on zfs.v3?

[Mark Shellenbaum]

Carson Gaspar wrote:

we give the right to add folder to user foo.(this
user can not delete anything as a default) After that
we give the right create file.And then user foo gains
delete everthing. How come is it possible.
Even though we add another rule like
"0:user:foo:delete_child/delete:deny". Again it does
not work . Why please somebody answer this strange
situation.


I can't find any response to this query from last August. I can confirm that on 
a Solaris 10 U3 fully patched server that the 'delete_child' ACL is being 
ignored in ZFS. Deletion is only controlled by the 'add_file' ACL.  I'm fairly 
certain that this is in violation of the NFSv4 spec, which zfs claims to 
implement.

The "sticky bit" on a directory is also not reflected in the ACLs output by 'ls 
-dv', although it appears to work as usual. I have a nasty suspicion that this is related.



I would suspect you are seeing:

6541829 zfs delete permissions are not working correctly.

That bug is fixed in Nevada, and will be in update 4.

  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Re: delete acl not working on zfs.v3?

[Mark Shellenbaum]

Carson Gaspar wrote:

Mark Shellenbaum wrote:

Can you post the full ACL on the directory and on the file you are 
being allowed to delete.


Simple test:

carson:gandalf 2 $ uname -a
SunOS gandalf.taltos.org 5.10 Generic_125101-02 i86pc i386 i86pc

carson:gandalf 0 $ mkdir foo

carson:gandalf 0 $ ls -dv foo
drwxr-xr-x   2 carson   carson 2 Apr  3 07:28 foo
 0:owner@::deny
 1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
 /append_data/write_xattr/execute/write_attributes/write_acl
 /write_owner:allow
 2:group@:add_file/write_data/add_subdirectory/append_data:deny
 3:group@:list_directory/read_data/execute:allow

4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
 /write_attributes/write_acl/write_owner:deny

5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
 /read_acl/synchronize:allow

carson:gandalf 0 $ chmod A+everyone@:add_file:allow foo

carson:gandalf 0 $ chmod A+everyone@:delete_child:deny foo

Tue Apr 03 07:30:41 /export/data/acltest
carson:gandalf 0 $ ls -dv foo
drwxrwxrwx+  2 carson   carson 2 Apr  3 07:30 foo
 0:everyone@:delete_child:deny
 1:everyone@:add_file/write_data:allow
 2:owner@::deny
 3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
 /append_data/write_xattr/execute/write_attributes/write_acl
 /write_owner:allow
 4:group@:add_file/write_data/add_subdirectory/append_data:deny
 5:group@:list_directory/read_data/execute:allow

6:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
 /write_attributes/write_acl/write_owner:deny

7:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
 /read_acl/synchronize:allow

carson:gandalf 0 $ touch foo/bar

carson:gandalf 0 $ ls -v foo/bar
-rw-r--r--   1 carson   carson 0 Apr  3 07:29 foo/bar
 0:owner@:execute:deny
 1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
 /write_acl/write_owner:allow
 2:group@:write_data/append_data/execute:deny
 3:group@:read_data:allow

4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
 /write_acl/write_owner:deny
 5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
 :allow

(different user)

gabe:gandalf 0 $ rm foo/bar
rm: foo/bar: override protection 644 (yes/no)? yes

carson:gandalf 0 $ ls -v foo/bar
foo/bar: No such file or directory



This appears to work correctly in Nevada.

$ cd /sandbox
$ mkdir foo
$ ls -dv foo
drwxr-xr-x   2 marksstaff  2 Apr  3 08:42 foo
 0:owner@::deny
 1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
 /append_data/write_xattr/execute/write_attributes/write_acl
 /write_owner:allow
 2:group@:add_file/write_data/add_subdirectory/append_data:deny
 3:group@:list_directory/read_data/execute:allow

4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
 /write_attributes/write_acl/write_owner:deny

5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
 /read_acl/synchronize:allow
$ chmod A+everyone@:delete_child:deny foo
$ ls -dv foo
drwxrwxrwx+  2 marksstaff  2 Apr  3 08:42 foo
 0:everyone@:delete_child:deny
 1:everyone@:add_file/write_data:allow
 2:owner@::deny
 3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
 /append_data/write_xattr/execute/write_attributes/write_acl
 /write_owner:allow
 4:group@:add_file/write_data/add_subdirectory/append_data:deny
 5:group@:list_directory/read_data/execute:allow

6:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
 /write_attributes/write_acl/write_owner:deny

7:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
 /read_acl/synchronize:allow
$ touch foo/bar

Switch to user "lp"

lp$ rm foo/bar
rm: foo/bar: override protection 644 (yes/no)? y
rm: foo/bar not removed: Permission denied
lp$ ls
foo   test
lp$ ls foo/bar
foo/bar

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Best way to migrate filesystems to ZFS?

[Mark Shellenbaum]

Robert Thurlow wrote:

Richard Elling wrote:

Peter Eriksson wrote:


ufsdump/ufsrestore doesn't restore the ACLs so that doesn't work, 
same with rsync.


ufsrestore obviously won't work on ZFS.


ufsrestore works fine; it only reads from a 'ufsdump' format medium and
writes through generic filesystem APIs.  I did some of this last week.
ACLs, as noted, won't get written out to ZFS.



Actually current ufsrestore can restore ACLs from UFS to ZFS

# newfs /dev/dsk/c1t0d0s0
newfs: construct a new file system /dev/rdsk/c1t0d0s0: (y/n)? y
Warning: 4164 sector(s) in last cylinder unallocated
/dev/rdsk/c1t0d0s0: 52938684 sectors in 8617 cylinders of 48 tracks, 
128 sectors

25849.0MB in 539 cyl groups (16 c/g, 48.00MB/g, 5824 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
 32, 98464, 196896, 295328, 393760, 492192, 590624, 689056, 787488, 885920,
Initializing cylinder groups:
..
super-block backups for last 10 cylinder groups at:
 52005024, 52103456, 52201888, 52300320, 52398752, 52497184, 52595616,
 52694048, 52792480, 52890912
# mount /dev/dsk/c1t0d0s0 /mnt
# cd /mnt
# touch file.1
# setfacl -m user:marks:rwx file.1
# ufsdump 0vf /var/tmp/dump.out /dev/rdsk/c1t0d0s0
  DUMP: Date of this level 0 dump: Tue Apr 03 11:51:19 2007
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/rdsk/c1t0d0s0 (rousay.Central.Sun.COM:/mnt) to 
/var/tmp/dump.out.

  DUMP: Mapping (Pass I) [regular files]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Writing 32 Kilobyte records
  DUMP: Estimated 1630 blocks (815KB).
  DUMP: Dumping (Pass III) [directories]
  DUMP: Dumping (Pass IV) [regular files]
  DUMP: Finished writing last dump volume
  DUMP: Starting verify pass
  DUMP: 1598 blocks (799KB) on 1 volume at 19487 KB/sec
  DUMP: DUMP IS DONE

# ls
file.1  lost+found
# cd /rootpool
# ls
boot
# mkdir test
# ufsrestore rvf /var/tmp/dump.out
Verify volume and initialize maps
Media block size is 126
Dump   date: Tue Apr 03 11:51:19 2007
Dumped from: the epoch
Level 0 dump of /mnt on rousay.Central.Sun.COM:/dev/dsk/c1t0d0s0
Label: none
Begin level 0 restore
Initialize symbol table.
Extract directories from tape
Calculate extraction list.
Make node ./lost+found
Extract new leaves.
Check pointing the restore
extract file ./file.1
Add links
Set directory mode, owner, and times.
Check the symbol table.
Check pointing the restore
# ls -l
total 9
drwxr-xr-x   3 root root   3 Apr  2 08:21 boot
-rw-r--r--+  1 root root   0 Apr  3 11:50 file.1
drwx--   2 root root   2 Apr  3 11:50 lost+found
-rw---   1 root root 2516764 Apr  3 11:51 restoresymtable
drwxr-xr-x   2 root root   2 Apr  3 11:51 test
# ls -V file.1
-rw-r--r--+  1 root root   0 Apr  3 11:50 file.1
owner@:rw-p--aA--cC-s:--:allow
owner@:--x---:--:deny
user:marks:-wxp---A---C--:--:deny
user:marks:rwxp--a---c--s:--:allow
user:marks:---A---C--:--:deny
group@:-wxp---A---C--:--:deny
group@:r-a---c--s:--:allow
group@:-wxp---A---C--:--:deny
 everyone@:r-a---c--s:--:allow
 everyone@:-wxp---A---C--:--:deny
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] FreeBSD's system flags.

[Mark Shellenbaum]

Pawel Jakub Dawidek wrote:

Hi there.

We have something called system flags in FreeBSD. Those are bascially
some additional flags you can set on files/directories (not extended
attributes nor ACLs).


http://www.freebsd.org/cgi/man.cgi?query=chflags&apropos=0&sektion=2&format=html

http://www.freebsd.org/cgi/man.cgi?query=chflags&apropos=0&sektion=1&format=html

Those are not hard to implement (partially), because there are spare
fields in the znode_phys structure, but I'd like to coordinate this with
you guys, so we won't have problems when file system is moved from
FreeBSD to Solaris. The other problem is that there is no spare room in
ZIL structures, ie. I can't add anything to lr_setattr_t, which won't
break on-disk compatibility. The suggested way of moving pools is to
export it, move to antoher box and import it. Once pool is exported
there should be no ZIL records to replay on import, so modifing
lr_setattr_t size isn't really critical, is it?

What are your suggestions?



I am currently working on adding a number of the BSD flags into ZFS.

I will be placing them in the upper half of the z_pflags field.

  -Mark
___
zfs-discuss mailing list
[EMAIL PROTECTED]
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs submounts and permissions with autofs

[Mark Shellenbaum]

Gavin Maltby wrote:

Hi,

Is it expected that if I have filesystem tank/foo and tank/foo/bar
(mounted under /tank) then in order to be able to browse via
/net down into tank/foo/bar I need to have group/other permissions
on /tank/foo open?



You are running into bug:
4697677 permissions of underlying directory affect permissions of mount 
point



# zfs create tank/foo
# zfs create tank/foo/bar
# chown gavinm /tank/foo /tank/foo/bar
# zfs set sharenfs=rw tank/foo

# ls -laR /tank/foo
/tank/foo:
total 9
drwxr-xr-x   3 gavinm   sys3 Apr 24 00:24 .
drwxr-xr-x   9 root sys9 Apr 24 00:23 ..
drwxr-xr-x   2 gavinm   sys2 Apr 24 00:24 bar

/tank/foo/bar:
total 6
drwxr-xr-x   2 gavinm   sys2 Apr 24 00:24 .
drwxr-xr-x   3 gavinm   sys3 Apr 24 00:24 ..

Note that the perms on /tank/foo are 755 at this point.  Now
browse via /net down to the 'bar' level from some nfs client:

([EMAIL PROTECTED]:~ )-> cd /net/TB3.UK.SUN.COM
([EMAIL PROTECTED]:/net/TB3.UK.SUN.COM )-> cd tank/foo
([EMAIL PROTECTED]:/net/TB3.UK.SUN.COM/tank/foo )-> df -h .
Filesystem size   used  avail capacity  Mounted on
TB3.UK.SUN.COM:/tank/foo
   401G25K   401G 1%
/net/TB3.UK.SUN.COM/tank/foo

([EMAIL PROTECTED]:/net/TB3.UK.SUN.COM/tank/foo )-> cd bar

([EMAIL PROTECTED]:/net/TB3.UK.SUN.COM/tank/foo/bar )-> df -h .
Filesystem size   used  avail capacity  Mounted on
TB3.UK.SUN.COM:/tank/foo/bar
   401G24K   401G 1%
/net/TB3.UK.SUN.COM/tank/foo/bar


So I am, as expected, in the tank/foo/bar filesystem.

But now change permissions on /tank/foo so that only I can access it:

# chmod 700 /tank/foo

# ls -laR /tank/foo
/tank/foo:
total 9
drwx--   3 gavinm   sys3 Apr 24 00:24 .
drwxr-xr-x   9 root sys9 Apr 24 00:23 ..
drwxr-xr-x   2 gavinm   sys2 Apr 24 00:24 bar

/tank/foo/bar:
total 6
drwxr-xr-x   2 gavinm   sys2 Apr 24 00:24 .
drwx--   3 gavinm   sys3 Apr 24 00:24 ..

And now I cannot browse into filesystem tank/foo/bar, only into
the mountpoint directory (different capitalisation below to
trigger new automounts under /net):

([EMAIL PROTECTED]:/net/TB3.UK.SUN.COM/tank/foo/bar )-> cd /net/TB3.uk.SUN.COM
([EMAIL PROTECTED]:/net/TB3.uk.SUN.COM )-> cd tank/foo
([EMAIL PROTECTED]:/net/TB3.uk.SUN.COM/tank/foo/bar )-> df -h .
Filesystem size   used  avail capacity  Mounted on
TB3.uk.SUN.COM:/tank/foo
   401G25K   401G 1%
/net/TB3.uk.SUN.COM/tank/foo


Thanks

Gavin
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Delegated Administration?

[Mark Shellenbaum]

Haik Aftandilian wrote:

Is it possible to give a user control of a ZFS filesystem such that the user can create 
their own file systems "within" it, take snapshots, etc.?

Thanks,
Haik
 


Support for this should be available within the next month or two.  You 
should check out PSARC/2006/465


http://www.opensolaris.org/jive/thread.jspa?messageID=47766


  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS delegation script

[Mark Shellenbaum]

Nicolas Williams wrote:

Couldn't wait for ZFS delegation, so I cobbled something together; see
attachment.

Nico



The *real* ZFS delegation code was integrated into Nevada this morning. 
 I've placed a little overview in my blog.


http://blogs.sun.com/marks

  -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Status of Samba/ZFS integration

[Mark Shellenbaum]

Razvan Corneliu VILT wrote:
> Sounds like the right solution to my problem in it solves a few problems, but 
> I am rather curious about how it would integrate with a potential Samba 
> server running on the same system (in case someone needs a domain controller 
> as well as a fileserver).
> 
> 1 - Samba can store the DOS attributes of a file in an xattr. Can sharesmb do 
> that? If so, is it compatible with Samba?
> 2 - Regarding that, are Resource_Forks/xattr/Alternate_data_streams supported?
> 3 - How do I set share ACLs (allowed users, and their rights)?
> 4 - How do I set the share name?
> 5 - Will it support the smb2 protocol?
> 5b - ill it work over IPv6?
> 6 - Is Shadow Copy supported (using zfs snapshots) ?
> 7 - How will it map nss users to domain users? Will it be able to connect to 
> Winbind?
> 8 - Kerberos authentication support?
> 9 - Will it support the NT priviledges? I could select a normal user on my 
> network, and with a simple net rpc rights grant SeBackupPrivilege, 
> SeRestorePrivilege, ACLs can be overridden by that user in a Windows 
> environment. A user of the sharesmb service might expect that.
> 
> In my personal case, I need 1, 2, 3, 4, 6, 7, 8 and 9. And I am sure that 
> more will come-up, as these are the ones that came to my mind right now.
> 
> Anyway, congratulations on the sharesmb thing. If it has a 
> flexible/configurable implementation (for the ones with complex rules in an 
> environment), but with sane defaults (for normal, users), it will be a hit.
> 
> Cheers,
> Razvan
>  


You might find this presentation of interest.  It was presented at the 
CIFS workshop recently.

http://us1.samba.org/samba/ftp/slides/cifs-workshop-2007/cifs_workshop_2007_09_27.pdf

It would be best to ask questions about the features of the CIFS server 
on [EMAIL PROTECTED]

   -Mark

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Status of Samba/ZFS integration

[Mark Shellenbaum]

Rayson Ho wrote:
> Does anyone know whether the following (copied from Wikipedia) is true or 
> not??
> 
> "Solaris has a project called CIFS client for Solaris, based on the
> Mac OS X smbfs."
> 
> Rayson
> 

Yes, that is true.

http://www.opensolaris.org/os/project/smbfs/

   -Mark

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] CIFS and user-visible snapshots

[Mark Shellenbaum]

Dick Davies wrote:
> Does anybody know if the upcoming CIFS integration in b77 will
> provide a mechanism for users to see snapshots (like .zfs/snapshot/
> does for NFS)?
> 

I don't believe that the version in build 77 will traverse down .zfs

It would be a good thing to add though.

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] cifs server?

[Mark Shellenbaum]

Nicolas Williams wrote:
> On Thu, Nov 22, 2007 at 10:27:18AM -0800, Tim Cook wrote:
>> So now that cifs has finally been released in b77, anyone happen to
> 
> It hasn't been released.  It was integrated into build 77.
> 
>> have any documentation on setup.  I know the initial share is
> 
> The documentation will be available in the first SX release to
> officially have the SMB server.
> 
>> relatively simple... but what is the process after that for actually
>> getting users authenticated?  I see in the idmap service there's some
>> configurations for authenticating against an AD server, but is there
>> anyway to get it to authenticate with a local database?  
> 
> There's been a lot of bugfixes, so I higly recommend waiting at least
> until build 79 closes.  What you would do is enable the idmap and
> smb/server services, then run "smbadm join" and go from there.  But like
> I said, I recommend waiting for build 79.
> 
>> In my test environment I only have a couple users, and no AD server,
>> so it seems  a bit silly to set one up simply to get authentication to
>> the cifs shares.  Docs/links, anyone?
> 
> There is a workgroup mode (this is controlled by a property of the
> smb/server service), but I'm not sure how well it works as I've
> not used it.  Perhaps the CIFS server project team can follow up here
> (but keep in mind it's Thanksgiving week...).
> 
> Nico

someone from the CIFS team in storage-discuss should be able to answer 
these questions.



   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Delegating iscsishare zfs permissions (iscsitgtd privileges)

[Mark Shellenbaum]

Stefan de Konink wrote:
> I have created a user 'block' which has the following ZFS permissions on 
> tank/iscsi_luns.
> 
> -bash-3.2# zfs allow tank/iscsi_luns
> -
> Local+Descendent permissions on (tank/iscsi_luns)
> user block 
> clone,create,destroy,mount,mountpoint,promote,rename,reservation,rollback,shareiscsi,snapshot,volsize
> -
> 
> I would like 'block' to give the ability to create volumes under iscsi_luns, 
> so user block can operate without superuser right. But upon create:
> 
> /usr/sbin/zfs create -V 1m tank/iscsi_luns/test
> cannot share 'tank/iscsi_luns/test': iscsitgtd failed request to share
> filesystem successfully created, but not shared
> 
> An error is generated, with the following dmesg:
> 
> Dec  2 15:21:26 troeteldier iscsitgtd[9870]: [ID 998699 user.error] 
> transaction_start start: insufficient privileges for action
> 
> Should my user block be placed in a special group in order to share via 
> iSCSI? Why isn't this working out of the box?
>  

You need to give out 'share' permission as well.  The shareiscsi 
permission only allows you to manipulate the property, whereas 'share' 
lets you share the volume.

   -Mark

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Delegating iscsishare zfs permissions (iscsitgtd privileges)

[Mark Shellenbaum]

Stefan de Konink wrote:
> Hi Mark,
> 
> Local+Descendent permissions on (tank/iscsi_luns)
> user block
> clone,create,destroy,mount,mountpoint,promote,rename,reservation,rollback,share,shareiscsi,snapshot,volsize
> 
> (added share)
> 
> The strange thing is that the command seems to fail:
> 

What opensolaris build are you using?

> -bash-3.2$ ./create.sh skinkie test 1m
> cannot share 'tank/iscsi_luns/skinkie_test': iscsitgtd failed request to
> share
> filesystem successfully created, but not shared
> iqn.1986-03.com.sun:02:51e9b650-6eef-c504-b2ae-8914bafce5e6
> 

I've seen this sort of thing before.  There is a bug in iscitgtd that 
use to cause this sort of error on the first request to share.  I'm not 
sure if that bug has been fixed yet.

> But the luns were made :{
> 
> Target: tank/iscsi_luns/test
> iSCSI Name:
> iqn.1986-03.com.sun:02:319bb303-3b1a-ebde-eb05-f2b3d9adbe86
> Connections: 0
> Target: tank/iscsi_luns/skinkie_test
> iSCSI Name:
> iqn.1986-03.com.sun:02:51e9b650-6eef-c504-b2ae-8914bafce5e6
> Connections: 0
> 
> 
> What I also see is that the LUN is not removed on the destroy command.
> If the destroy command is executed as root it is removed as target.
> 

as long as you have destroy it should remove the target.

> I implemented sudo now as wrapper around my script to get it to work, but
> some follow up on the errors is welcome.
> 

I'm seeing some other issues with delegation+iscisi with the latest 
Nevada bits.  I will need to investigate them and will likely raise some 
bugs once I figure out whats going on.

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Delegating iscsishare zfs permissions (iscsitgtd privileges)

[Mark Shellenbaum]

>> I'm seeing some other issues with delegation+iscisi with the latest
>> Nevada bits.  I will need to investigate them and will likely raise some
>> bugs once I figure out whats going on.
> 
> Thanks. For now my sudo wrapper works, but I would be very happy if this
> can be sorted out without any hacks.
> 
> 

Stefan,

Looks like delegation+iscsi works in snv_74, but not snv_75+.

I've opened the following bug to address this.

6636599 Integration of PSARC/2007/414 broke zfs delegated admin support
 of shareiscsi

The integration PSARC/2007/414 went into build 75.

   -Mark

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] dos programs on a ZFS+CIFS server setup

[Mark Shellenbaum]

Maurilio Longo wrote:
> Hi,
> 
> I'm testing ZFS+CIFS server using nexenta core rc4, everything seems fine and 
> speed is also ok, but DOS programs don't see sub-dirs (command.com sees them, 
> though).
> 
> I've set casesensitivity=insensitive in the ZFS filesystem that I'm sharing.
> 
> I've made this test using Windows2000, Windows2003 Server and Windows XP (to 
> connect to the share) and norton commander for dos plus a vertical 
> application written in clipper 5.2e.
> 
> Is this a known issue? Should I file a bug?
> 

I'm not aware of any such problem.  This problem is better asked in 
[EMAIL PROTECTED] where the CIFS server team hangs out.

  -Mark

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Can ZFS be event-driven or not?

[Mark Shellenbaum]

Kyle McDonald wrote:
> Bill Sommerfeld wrote:
>> On Wed, 2008-02-27 at 13:43 -0500, Kyle McDonald wrote:
>>   
>>> How was it MVFS could do this without any changes to the shells or any 
>>> other programs?
>>>
>>> I ClearCase could  'grep FOO /dir1/dir2/file@@/main/*' to see which 
>>> version of 'file' added FOO.
>>> (I think @@ was the special hidden key. It might have been something 
>>> else though.)
>>> 
>> When I last used clearcase (on the order of 12 years ago) foo@@/ only
>> worked within clearcase mvfs filesystems.
>>
>> It behaved as if the filesystem created a "foo@@" virtual directory for
>> each real "foo" directory entry, but then filtered those names out of
>> directory listings.
>>
>> Doing the same as an alternate "view" on snapshot space would be a
>> simple matter of programming within ZFS, though the magic token/suffix
>> to get you into version/snapshot space would likely not be POSIX
>> compliant..
>>   
> Ahh.
> 
> I suspected it should be 'possible' to code it into ZFS.
> 
> The reason it's been left to runat instead seems to be POSIX compliance 
> then?

Yes, we have runat for POSIX compliance.

An earlier prototype of Solaris extended attributes utilized a /@/ 
syntax to enter enter xattr space.   For example:

/data/file1/@/
/data/file1/@/attr.1
...
or
/data/dir1/@/

A readdir of /data/dir1 wouldn't show the @ directory, but you could 
always request to enter it.

This violated posix in a couple of ways.  One we took away the @ 
filename and two you can't have a directory on a file.

It was a really nice model, and I still kind of wish we could have 
integrated it that way.

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ACL invalid argument from client

[Mark Shellenbaum]

kevin kramer wrote:
> client CentOS 5.1 latest kernel
> mount option for zfs filesystem = 
> rw,nosuid,nodev,remount,noatime,nfsvers=3,udp,intr,bg 
>  ,hard,rsize=8192,wsize=8192
> 
> directory and parent owned by user and users GID, 775
> on client touch /tmp/dummy
> cd to zfs area
> mv /tmp/dummy .
> 
> receive this error
> /bin/mv /tmp/dummy .
> /bin/mv: preserving permissions for `./dummy': Invalid argument
> /bin/mv: preserving ACL for `./dummy': Invalid argument
> /bin/mv: preserving permissions for `./dummy': Invalid argument
> 
> the file does get copied. but it sends exit 0 when similarly used in a script
> 
> zfs pool name = vol1
> zfs get aclmode vol1
> vol1  aclinherit  discard  local
> vol1  aclmode   groupmasklocal
> 
> vol1/scr20 is the mount point on the client
> 
> vol1/scr20  aclinherit  discard  local
> vol1/scr20  aclmode   groupmasklocal
> 
> I've also tried using mount option noacl with no luck.. what do I need to do 
> to ignore ACL's on my clients that support ACL's? and I've tried passthrough 
> mode for aclinherit.
> 
> thanks for any insight
>  

Is your ZFS file system on an S10 system?

You are most likely seeing this bug.

6528189 cp -p invalid argument issue on Redhat linux AS 3.0 NFS client
 against ZFS NFS directory

This was fixed last May.

Assuming you are on an S10 update then you probably want this patch.

127729-02
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ACL invalid argument from client

[Mark Shellenbaum]

Kevin Kramer wrote:
> no. I'm running on a Dell 1950. I'm updating the system now. Do my 
> aclmode,aclinherit look right? I've read the guide and think this is my 
> best option.
> 
> thanks.

the ACL properties have no bearing on this.  The issue is that you are 
using an NFSv3 client and its asking for a POSIX draft ACL which ZFS 
doesn't support.  The ZFS code now returns ENOTSUP which should let the 
linux cp program know that ACLs aren't supported on the file system.

what OS is on the client and what OS is on the server?

   -Mark

> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 11, 2008 10:58 AM
> To: kevin kramer
> Cc: zfs-discuss@opensolaris.org
> Subject: Re: [zfs-discuss] ACL invalid argument from client
> 
> kevin kramer wrote:
>  > client CentOS 5.1 latest kernel
>  > mount option for zfs filesystem = 
> rw,nosuid,nodev,remount,noatime,nfsvers=3,udp,intr,bg 
>  
> ,hard,rsize=8192,wsize=8192
>  >
>  > directory and parent owned by user and users GID, 775
>  > on client touch /tmp/dummy
>  > cd to zfs area
>  > mv /tmp/dummy .
>  >
>  > receive this error
>  > /bin/mv /tmp/dummy .
>  > /bin/mv: preserving permissions for `./dummy': Invalid argument
>  > /bin/mv: preserving ACL for `./dummy': Invalid argument
>  > /bin/mv: preserving permissions for `./dummy': Invalid argument
>  >
>  > the file does get copied. but it sends exit 0 when similarly used in 
> a script
>  >
>  > zfs pool name = vol1
>  > zfs get aclmode vol1
>  > vol1  aclinherit  discard  local
>  > vol1  aclmode   groupmasklocal
>  >
>  > vol1/scr20 is the mount point on the client
>  >
>  > vol1/scr20  aclinherit  discard  local
>  > vol1/scr20  aclmode   groupmasklocal
>  >
>  > I've also tried using mount option noacl with no luck.. what do I 
> need to do to ignore ACL's on my clients that support ACL's? and I've 
> tried passthrough mode for aclinherit.
>  >
>  > thanks for any insight
>  > 
> 
> Is your ZFS file system on an S10 system?
> 
> You are most likely seeing this bug.
> 
> 6528189 cp -p invalid argument issue on Redhat linux AS 3.0 NFS client
>  against ZFS NFS directory
> 
> This was fixed last May.
> 
> Assuming you are on an S10 update then you probably want this patch.
> 
> 127729-02
> 

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ACL invalid argument from client

[Mark Shellenbaum]

Kevin Kramer wrote:
> client is CentOS 5.1
> server is running Sol10
> 

You should look into applying the patch I mentioned earlier on your S10 
server.

   -Mark


>  >
>  > Is your ZFS file system on an S10 system?
>  >
>  > You are most likely seeing this bug.
>  >
>  > 6528189 cp -p invalid argument issue on Redhat linux AS 3.0 NFS client
>  >  against ZFS NFS directory
>  >
>  > This was fixed last May.
>  >
>  > Assuming you are on an S10 update then you probably want this patch.
>  >
>  > 127729-02
>  >
> 
> 

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS ACLs/Samba integration

[Mark Shellenbaum]

Jens Elkner wrote:
> On Thu, Mar 13, 2008 at 11:33:57AM +, Darren J Moffat wrote:
>> Paul B. Henson wrote:
>>> I'm currently prototyping a Solaris file server that will dish out user
>>> home directories and group project directories via NFSv4 and Samba.
>> Why not the in kernel CIFS server ?
> 
> E.g., how would one mimic:
> 
> [office]
> comment = office
> path = /export/vol1/office
> valid users = @office
> force group = office
> create mode = 660
> directory mode = 770
>   ...
> 
> We already lost this functionality with the introduction of the NFSv4
> ACL crap on ZFS and earned a lot of "hate you" feedbacks. Anyway, most
> users and staff switched/switching over to windows (we do not support
> Linux yet and Solaris is wrt. desktop at least 5 years behind the scene),
> so the last 5% of *x users need to live with it.
> However, if we would switch to Solaris CIFS (which AFAIK can not
> accomplish, what is required) we would have no friends anymore ...
> 
> Regards,
> jel.

You mean something like this.

# zpool create sandbox c0t3d0
# zfs set sharesmb=on sandbox

I then set this ACL on the directory

# ls -dV /sandbox
drwxrwxrwx+  2 root root   3 Mar 14 08:27 /sandbox
 group@:rw-pdDaARWcCos:f--:allow
 owner@:rw-pdDaARWcCos:f--:allow
 owner@:--:---:deny
 owner@:rwxp---A-W-Co-:---:allow
 group@:--:---:deny
 group@:rwxp--:---:allow
  everyone@:---A-W-Co-:---:deny
  everyone@:rwxp--a-R-c--s:---:allow


Then I created a file from a windows client

I have this idmap rule setup

# idmap list
add winuser:[EMAIL PROTECTED] unixuser:marks

# ls -V New*
-rw-rw+  1 marks2147483650   0 Mar 14 08:28 New Wordpad 
Document.doc
 group@:rw-pdDaARWcCos:--I:allow
 owner@:rw-pdDaARWcCos:--I:allow


# idmap dump
usid:S-1-5-21-940912991-1138591764-871648236-1138   == 
uid:2147483649
gsid:S-1-5-21-940912991-1138591764-871648236-513== 
gid:2147483650
gsid:S-1-5-11   ==  gid:2147483651
gsid:S-1-5-2==  gid:2147483652
usid:S-1-5-21-940912991-1138591764-871648236-1119   ==  uid:76928
gsid:S-1-5-21-2169176303-1867137939-2363023632-3371165004-2147483658 
==  gid:10


this behavior is only possible from a Windows client.  When creating 
files from unix the POSIX rules apply and the requestors mode must be 
honored, which results in the owner@, group@, and everyone@ entries 
always being set on the files ACL.


   -Mark

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS ACLs/Samba integration

[Mark Shellenbaum]

Paul B. Henson wrote:
> On Fri, 14 Mar 2008, Mark Shellenbaum wrote:
> 
>> this behavior is only possible from a Windows client.  When creating
>> files from unix the POSIX rules apply and the requestors mode must be
>> honored, which results in the owner@, group@, and everyone@ entries
>> always being set on the files ACL.
> 
> It's one thing to feature POSIX compatibility; it's another to force it. I
> was hoping with a pure ACL implementation to be able to disregard the
> legacy POSIX mode bits baggage and have ACLs handled sanely. It doesn't
> look like I can achieve that though :(.
> 
> Upon creation, a brand-new ZFS file system has the following ACL:
> 
> drwxr-xr-x   2 root sys2 Mar 14 14:42 .
> 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
> 
> 
> Given that in my understanding any permission not explicitly allowed is
> denied by default, what is the purpose of the explicitly listed deny
> components? They in no way alter the effective permissions, and result in a
> Windows client accessing the permissions via samba issuing an error
> regarding the ordering.
> 

That is not correct.  The deny entries are necessary for POSIX 
semantics.  In POSIX are only allowed to pick up permissions from the 
owner, group or other class.  You can't pick up part of the permissions 
you are looking for from the group class and then some more from the 
other class.


> The creation of a file in the file system results in the following ACL:
> 
> 
> -rw-r--r--   1 root root   0 Mar 14 14:43 foo
> owner@:--x---:--:deny
> owner@:rw-p---A-W-Co-:--:allow
> group@:-wxp--:--:deny
> group@:r-:--:allow
>  everyone@:-wxp---A-W-Co-:--:deny
>  everyone@:r-a-R-c--s:--:allow
> 
> Again, it seems the deny components are extraneous, serving only to
> complicate the ACL. So, I modified the ACL to look as follows, resulting in
> the exact same effective permissions, but much simpler to parse:
> 
> 
> -rw-r--r--   1 root root   0 Mar 14 14:43 foo
> owner@:rw-p---A-W-Co-:--:allow
> group@:r-:--:allow
>  everyone@:r-a-R-c--s:--:allow
> 
> Note that the above file still has a "trivial" ACL, as indicated by the
> lack of "+" in the permission bits.
> 

That is actually a bug that was recently fixed.

> Now, let's say I wanted to remove group and other readability from that
> file via "chmod og-r foo" -- that results in:
> 
> -rw---+  1 root root   0 Mar 14 14:43 foo
> owner@:---A-W-Co-:--:allow
> group@:--:--:allow
>  everyone@:--a-R-c--s:--:allow
> owner@:--x---:--:deny
> owner@:rw-p---A-W-Co-:--:allow
> group@:rwxp--:--:deny
> group@:--:--:allow
>  everyone@:rwxp---A-W-Co-:--:deny
>  everyone@:--a-R-c--s:--:allow
> 
> WTF? Now there are three entries each for owner, group and everyone. Three
> unnecessary deny ACE's have been added, two of the owner allow entries
> overlap, there is a group allow ACE permitting nothing. And oddly, a file
> that started with a "trivial" ACL, and was modified via mode bit changes,
> suddenly has a nontrivial ACL. That just seems broken...
> 
> Moving on to inherited permissions, lets say I wanted to create a directory
> writable by the group, with newly created files and subdirectories also
> writable by the group. I thought the following ACL should allow that:
> 
> drwxrwxr-x+  2 root root   2 Mar 14 14:46 groupw
>  everyone@:--:f-i---:allow
> group@:rw:f-i---:allow
> owner@:rw:f-i---:allow
> owner@:rwxp---A-W-Co-:-d:allow
> group@:rwxp--:-d:allow
>  everyone@:r-x---a-R-c--s:-d:allow
> 
> Creating a new file in that directory results in:
> 
> 
> -rw-r--r--+  1 root root   0 Mar 14 14:53 groupw/file
>  everyone@:--:--:allow
> group@:--:--:allow
> owner@:--:--:allow
> owner@:--x---:--:deny
> owner@:rw-p---A-W-Co-:--:allow
>

Re: [zfs-discuss] ZFS ACLs/Samba integration

[Mark Shellenbaum]

Paul B. Henson wrote:
> On Fri, 14 Mar 2008, Mark Shellenbaum wrote:
> 
>> That is not correct.  The deny entries are necessary for POSIX semantics.
>> In POSIX are only allowed to pick up permissions from the owner, group or
>> other class.  You can't pick up part of the permissions you are looking
>> for from the group class and then some more from the other class.
> 
> Ah, I was interpreting them from the standpoint of an NFSv4 ACL, not from a
> legacy POSIX perspective.
> 
>>> Note that the above file still has a "trivial" ACL, as indicated by the
>>> lack of "+" in the permission bits.
>> That is actually a bug that was recently fixed.
> 
> What was fixed? That the ACL would no longer be considered trivial?

No longer considered trivial.

> 
>> Thats because the requesters mode must be honored.  You can't disregard
>> the mode the application requests and the ACL needs to be altered to
>> match the mode.  That why the three entries are basically nulled out, but
>> the ACEs are left in place in case you want to change them later.
> 
> Hmm... What's the point of having the ability to inherit ACL entries if you
> can't actually control the permissions on new files and directories that
> will be created?

Inheriting ACEs works better if you don't use owner@, group@ or 
[EMAIL PROTECTED]  Those ACEs affect the mode of the file

> 
>>> Why did my ACE's that were applicable to the parent directory and
>>> marked inheritable be split into two separate ACE's, one inherit only
>>> and one applicable? That seems redundant and overly complicates the
>>> ACL.
>> That necessary for effective propagation of ACEs.  That way the ACE is
>> propagated down as it was set at the first place the ACE was set.
> 
> Ok, if I understand you correctly, they are split such that you can modify
> the ACL pertaining to the actual directory object without modifying the ACL
> that will be inherited by future child objects? That makes sense.
> 
>>> What I would really like to see is a mode that completely ignores
>>> umask/mode bits and simply applies the inherited ACL with no
>>> modification or complication. I don't see any way to do that?
>> No such mode exists.
> 
> Am I mistaken or confused in my thought that such a mode would be highly
> desirable? I would like to be able to configure permissions, particularly
> inherited permissions, such that they would be fully defined by the ACL,
> and not modified in unknown ways by whatever umask happened to be in effect
> when the file or directory was created. I would also like to be able to
> maintain ACLs via either UNIX commands or from a CIFs client and have them
> stay compatible. I think it is a misnomer to call the current
> implementation of ZFS a "pure ACL" system, as clearly the ACLs are heavily
> contaminated by legacy mode bits.
> 

Feel free to open an RFE.  It may be a tough sell with PSARC, but maybe 
if we have enough customer requests maybe they can be won over.


> Thanks for the response...
> 
> 

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS ACLs/Samba integration

[Mark Shellenbaum]

Paul B. Henson wrote:
> On Mon, 17 Mar 2008, Bill Sommerfeld wrote:
> 
>> I suspect at least some of the membership would be interested in this
>> sort of extension and it shouldn't be that hard to "sell" if it's not the
>> default behavior and it's clearly documented that turning it on (probably
>> on a fs-by-fs basis like every other zfs tunable) takes you out of POSIX
>> land.
> 
> I was actually rereading the "Solaris ZFS Administration Guide"; based on
> it the behavior I want should already be available:
> 
> 
> The ZFS file system includes two property modes related to ACLs:
> 
> aclinherit - This property determines the behavior of ACL inheritance.
> 
> Values include the following:
> 
>   passthrough - For new objects, the inheritable ACL entries are
>   inherited with no changes made to them. This mode, in effect,
>   disables secure mode.
> 
> 
> aclmode - This property modifies ACL behavior whenever a file or
> directory's mode is modified by the chmod command or when a file is
> initially created.
> 
> Values include the following:
> 
>   passthrough - For new objects, the inheritable ACL entries are
>   inherited with no changes made to them.
> 
> 
> This documentation would seem to indicate that if both "aclinherit" and
> "aclmode" are set to "passthrough", then "the inheritable ACL entries are
> inherited with no changes made to them".
> 
> However, as I originally posted, the inheritable ACL entries I configured
> are being munged. Based on the documentation, this behavior is broken.
> 
> 

The documentation in the admin guide isn't quite correct.

I will go ahead and do a fastrack to get the behavior that many people 
want.  Basically, if inheritable ACEs are present for owner@, group@, 
everyone@ then the inherited ACE permissions will override the requested 
mode of the application.  If no inheritable ACEs are present for owner@, 
group, or everyone@ then the mode will be used.


   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS ACLs/Samba integration

[Mark Shellenbaum]

Paul B. Henson wrote:
> On Mon, 17 Mar 2008, Mark Shellenbaum wrote:
> 
>> I will go ahead and do a fastrack to get the behavior that many people
>> want.  Basically, if inheritable ACEs are present for owner@, group@,
>> everyone@ then the inherited ACE permissions will override the requested
>> mode of the application.  If no inheritable ACEs are present for owner@,
>> group, or everyone@ then the mode will be used.
> 
> *Sweet*!!! That sounds perfect!
> 
> Is that something that might be backported to production Solaris 10 in a
> patch? Or something that would have to wait for an update release? We are
> currently prototyping an NFSv4/Samba file services implementation for our
> campus, management is requiring official support for the OS so OpenSolaris
> isn't really an option; but I don't think we can deploy without this fix.
> 
> Thanks much...
> 
> 

No guarantees, but I think it should be back portable to Solaris 10.

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Disabling ZFS ACL

[Mark Shellenbaum]

Kyle McDonald wrote:
> Darren J Moffat wrote:
>> Sachin Palav wrote:
>>   
>>> Hello Friends,
>>>
>>> Can some please let me know how I can disable ZFS ACL completely. I want to 
>>> use ZFS  with plain unix permission without ACL support
>>> 
>>
>> I'm really curious as to why you want to do that but it seems that ZFS 
>> allows you to do so.  It is documented in the zfs(1) man page.
>>
>> zfs set aclinherit=discard 
>> zfs set aclmode=discard 
>>
>>   
> Maybe I missed something? Is there something about ZFS ACL's that does 
> allow you to set them for the same effective behavior as 'unix permissions'?
> 

Yes, that should all work as expected.

> By default would anyone expecting and assuming 'unix permissions' were 
> in use even notice that ZFS was really using something else?
> 

If you never set an explicit ACL then you should never notice that it is 
internally using an ACL.

> Does ZFS ACL inheiritance support the same functionality that setting 
> setgid on a directory did in 'unix permissions'?
> 

Inheriting setgid works.

>-Kyle
> 
> 
> 
> 
> 
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] aclinherit property changes fast track

[Mark Shellenbaum]

Here is a draft of the fast track to allow ZFS to inherit mode 
permission via owner@, group@ and everyone@


  -Mark


SUMMARY:

This proposal is to change the ZFS ACL inheritance rules 
when the zfs acl property is set to "passthrough".

PROBLEM:

The ZFS ACL subsystem provides a property aclinherit to control how
ACL inheritance is performed.  The default value "secure" creates 
ACLs that conform to POSIX access control semantics.  Many customers
desire native NFSv4 ACL inheritance.  They want to be able to "force"
the mode that files and directories are created with.  In the past
they would use default ACLs on UFS to achieve this.  The NFSv4 ACL
model can also do this, but the current implementation in ZFS disables
the ACEs owner@, group@, and everyone@ in order to set the mode of
the file to the mode the application requested.  

This problem has been discussed countless times on 
zfs-discuss@opensolaris.org and has caused some customers to not
upgrade to ZFS because they need a way to force the creation mode
for files and directories.  

The current behavior differs from UFS and is unintuitive to users 
and the zfs community consesus is that we should have a mechanism for 
inheriting permissions for ACEs that affect the mode of the file.

PROPOSED SOLUTION:

The aclinherit property already supports a "passthrough" value which
is intended to provide a more native NFSv4 ACL representation, but 
today only allows an application to inherit the control permissions
"write_owner and or write_acl".  If we expand the meaning of this 
property, such that if a parent directory contains inheritable
owner@, group@ or everyone@ ACEs then those permissions will replace
the requested mode for the file or directory create.

This will be similar to UFS default ACLs, except that the administrator
will have to enable the capability on the file system via the 
aclinherit property.  See below for an example of this.

This behavior only affects the initial create of the file or directory.
Subsequent chmod(2) requests will apply the chmod(2) algorithm that
ZFS already uses to enforce POSIX semantics.

ZFS already has other features that take us out of POSIX control.  
For example, the nbmand property, system attributes, such as 
readonly, immutable, nounlink, appendonly, quarantined, and so on.

INHERITANCE EXAMPLES:

First lets look at a UFS default ACL example

For this example I will using user "sys" and "dladm" that are both
in the "sys" group.

# su sys
# mkdir ufs-test
# chmod 775 ufs-test

Now lets create a default ACL that will specify 0666 for new files.

# setfacl -m d:u::rw-,d:g::rw-,d:o:rw-,d:m:rwx ufs-test
# ls -dV ufs-test
drwxrwxr-x+  2 sys  sys  512 Mar 19 13:21 ufs-test
0:user::rwx
1:group::rwx   #effective:rwx
2:mask:rwx
3:other:r-x
4:Default:user::rw-
5:default:group::rw-
6:default:mask:rwx
7:default:other:rw-

Now switch to user dladm and create a new file and set our umask to
066.

# su dladm
dladm$ umask 066
dladm$ cd ufs-test
dladm$ touch a
dladm$ ls -l a
# ls -l x
-rw-rw-rw-   1 dladmsys0 Mar 19 11:36 a


The next example is what most users typical try to do with ZFS to 
achieve the same sort of thing.

# mkdir dir1

Now lets prepend 3 ACEs to the beginning of the ACL on the directory for
owner@, group@ and everyone@ that are specified to inherit to newly
created files and directories.

# mkdir /sandbox/dir1
# chmod 755 /sandbox/dir1
# chmod A+owner@:rw:fd:allow,group@:rw:fd:allow, \
everyone@:rw:fd:allow dir1

# ls -dV dir1
drwxrwxrwx+  2 root root   3 Mar 19 13:04 dir1
owner@:rw:fd-:allow
group@:rw:fd-:allow
 everyone@:rw:fd-:allow
owner@:--:---:deny
owner@:rwxp---A-W-Co-:---:allow
group@:rw-p--:---:deny
group@:--x---:---:allow
 everyone@:rw-p---A-W-Co-:---:deny
 everyone@:--x---a-R-c--s:---:allow

# cd dir1
# touch a

Now lets look at the new file. 

# ls -V a
-rw-r--r--+  1 root root   0 Mar 19 13:04 a
owner@:--:--I:allow
group@:--:--I:allow
 everyone@:--:--I:allow
owner@:--x---

Re: [zfs-discuss] aclinherit property changes fast track

[Mark Shellenbaum]

Marc Bevand wrote:
> Mark Shellenbaum  Sun.COM> writes:
>>  # ls -V a
>>  -rw-r--r--+  1 root root   0 Mar 19 13:04 a
>> owner@:--:--I:allow
>> group@:--:--I:allow
>>  everyone@:--:--I:allow
> 
> The ls(1) manpage (as of snv_82) seems incorrect because it
> says the last inheritance flags is F (Failed access):
> 
>   :rwxpdDaARWcCos:fdinSF:
> 
> Whereas your example shows I (Inherited).
> 
> -marc

Thanks for noticing that.

I've opened a bug to get the man page fixed.

6677920 ls(1) missing information about inherited ACE


   -Mark


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Disabling ZFS ACL

[Mark Shellenbaum]

Sachin Palav wrote:
> We are using this server as NFS & SAMBA server, we created ZFS file systems 
> considering it features. But un-fortunately we are experiencing problems with 
> every NFS client (almost all version os UNIX (AIX/Linux/HP). So I have now 
> set the server to use NFS version 2, as most of the NFS clients work fine on 
> this version. But if I use NFS version 3 they give errors while 
> writing/coping file to these NFS exported ZFS file systems. So I thought of 
> disabling the ACLs completely and using plain unix permissions
> Below is the version Solaris 10 11/06 s10x_u3wos_10 X86 (install the latest 
> path cluster and all the patches for ZFS).
> 
> Thanks
> Sachin Palav
>  
>

This issue was discussed in this thread

http://www.opensolaris.org/jive/thread.jspa?messageID=214069𴐵

you need to apply patch 127729-02

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS ACE limit?

[Mark Shellenbaum]

Paul B. Henson wrote:
> One of my colleagues was testing our ZFS prototype (S10U4), and was
> wondering what was the limit for ACE's on a ZFS ACL.
> 
> Empirically, he determined that he could not add more than 1024 ACE's
> either locally or via NFSv4 from a Solaris client (from a Linux NFSv4
> client, it failed adding the 209th ACL, and for that matter, after the
> failure to add that last entry, it was no longer able to read the ACL,
> Complaining that "getxattr" failed).
> 
> I haven't found any information regarding a documented limit for either ZFS
> itself or NFSv4.
> 
> Is 1024 the limit? Is there any tuning that can be done to either increase
> or decrease that?
> 

The limit is 1024, which is the same for ufs POSIX draft ACLs.  It can't 
currently be changed.

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS cli for REMOTE Administration

[Mark Shellenbaum]

Marcelo Leal wrote:
> No answer... well, do you not have this problem or there is another option to 
> delegate such administration? I was thinking if we can delegate a "single" 
> filesystem administration to some user through ZFS administration web console 
> (67889). 
>  Can i create a user and give him administration rights to a single 
> filesystem (and its snapshots, of course)?
> 
>  Thanks.


we already have the ability to allow users to create/destroy snapshots 
over NFS.  Look at the ZFS delegated administration model.  If all you 
want is snapshot creation/destruction then you will need to grant 
"snapshot,mount,destroy" permissions.

then on the NFS client mount go into .zfs/snapshot and do mkdir 
.  Providing the user has the appropriate permission the 
snapshot will be created.

rmdir can be used to remove the snapshot.


   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS cli for REMOTE Administration

[Mark Shellenbaum]

Paul B. Henson wrote:
> On Thu, 8 May 2008, Mark Shellenbaum wrote:
> 
>> we already have the ability to allow users to create/destroy snapshots
>> over NFS.  Look at the ZFS delegated administration model.  If all you
>> want is snapshot creation/destruction then you will need to grant
>> "snapshot,mount,destroy" permissions.
>>
>> then on the NFS client mount go into .zfs/snapshot and do mkdir
>> .  Providing the user has the appropriate permission the
>> snapshot will be created.
>>
>> rmdir can be used to remove the snapshot.
> 
> Now that is just uber-cool.
> 
> Can you do that through the in kernel CIFS server too?
> 
> 

Yes, it works over CIFS too.



   -Mark

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS cli for REMOTE Administration

[Mark Shellenbaum]

Andy Lubel wrote:
> Paul B. Henson wrote:
>>> On Thu, 8 May 2008, Mark Shellenbaum wrote:
>>>
>>>> we already have the ability to allow users to create/destroy snapshots
>>>> over NFS.  Look at the ZFS delegated administration model.  If all you
>>>> want is snapshot creation/destruction then you will need to grant
>>>> "snapshot,mount,destroy" permissions.
>>>>
>>>> then on the NFS client mount go into .zfs/snapshot and do mkdir
>>>> .  Providing the user has the appropriate permission the
>>>> snapshot will be created.
>>>>
>>>> rmdir can be used to remove the snapshot.
>>> Now that is just uber-cool.
>>>
>>> Can you do that through the in kernel CIFS server too?
>>>
>>>
> 
>> Yes, it works over CIFS too.
> 
>>   -Mark
> 
> Great stuff!
> 
> I confirmed that it does work, but its strange that I don't see the snapshot 
> in 'zfs list' on the zfs box.  Is that a bug or a feature?  Im using XP - 
> another thing is that if you right click in the .zfs/snapshot directory and 
> do new -> folder you will be stuck with a snapshot called "New Folder".  I 
> couldn't rename it and the only way to delete it was to log into the machine 
> and do a lil 'rm -Rf'.  good news is that it is snapshotting :)
> 
> I have a simple backup script where I use robocopy and then at the end I want 
> to do a 'mkdir .zfs/snapshot/xxx', but I would eventually want to delete the 
> oldest snapshot, similar to the zsnap.pl script floating around.
> 
> Cant wait to try this on NFS, the whole reason we objected to snapshots in 
> the first place in our org was because our admins didn't want to be involved 
> with the users for the routine of working with snapshots.
> 
> -Andy
> 


If you want to be able to rename the snapshots then you will need to 
also hand out "rename,create" permission.  Then after windows creates 
the "New Folder" you can rename it to something else.

You can also rename it from the server by doing a "mv" command in 
.zfs/snapshot

I created this bug to address the issue with the space character

6700649 zfs_ctldir snapshot creatation issue with CIFS clients


   -Mark

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Disabling ZFS ACL

[Mark Shellenbaum]

kevin kramer wrote:
> that is my thread and I'm still having issues even after applying that patch. 
> It just came up again this week.
> 
> [locahost] uname -a
> Linux dv-121-25.centtech.com 2.6.18-53.1.14.el5 #1 SMP Wed Mar 5 11:37:38 EST 
> 2008 x86_64 x86_64 x86_64 GNU/Linux
> [localhost] cat /etc/issue
> CentOS release 5 (Final)
> Kernel \r on an \m
> 
> [localhost: /n/scr20] touch test
> [localhost: /n/scr20] mv test /n/scr01/test/ ** this is a UFS mount on FreeBSD
> 
> mv: preserving permissions for `/n/scr01/test/test': Operation not supported
> mv: preserving ACL for `/n/scr01/test/test': Operation not supported
> mv: preserving permissions for `/n/scr01/test/test': Operation not supported
> 

Thats because the UFS mount doesn't support NFSv4 ACLs and 'mv' was 
unable to translate the ACL into an equivalent POSIX draft ACL.

> If I move it to the local /tmp, I get no errors.
>  
>  
> This message posted from opensolaris.org
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore

[Mark Shellenbaum]

Joerg Schilling wrote:
> Darren J Moffat <[EMAIL PROTECTED]> wrote:
> 
>>> The closest equivalent to ufsdump and ufsrestore is "star".
>> I very strongly disagree.  The closest ZFS equivalent to ufsdump is 'zfs 
>> send'.  'zfs send' like ufsdump has initmiate awareness of the the 
>> actual on disk layout and is an integrated part of the filesystem 
>> implementation.
> 
> I strongly disagree. Like ufsdump, star creates archives that allow a file 
> based access. This does not work with zfs send.
> 

But star doesn't support Solaris Extended attributes and ZFS ACLs.  This 
means you *may* loose critical data if you use star.  Whereas zfs send 
preserves everything.

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss