Cheers,
Simon

I was just going over this post again, as I am currently changing my file system structure. What strikes me is that only in one place you create the file system with “casesensitivity=mixed”. Is there any particular reason for that?

FYI: It seems that with snv_131 the “set sharesmb=name=xxxxx” is broken.

Cheers,
Christoph

When you boot your client OS, such as Windows, Mac OS or Linux etc, you need to connect to the shared media file systems using the ‘media’ user.

Cheers,
Simon

Thanks for this great guide for a linux starter like me! I still have one problem: i created a user – like Fred. But everything Fred creates in the media-filesystem is not visible for other users (like wilma), because the files are owned by Fred and the group is also Fred (instead of the media group). How can i change this, so that everything Fred does in the media-filesystem is created with group media ?

Many thanks,
Bart

fascinating ACL writeup, it looks daunting. In my shop they did it bass-ackwards and windows is the (normal) SMB server and NFS server. My sun boxes are the dummy nfs clients. I’m thinking of reversing the roles and making opensolaris the cifs/smb server, and nixing the nfs.

But what I wanted to comment on, was “setting ‘copies’ attribute to 2″ ZFS. Dude – zfs snapshot trump copies=x. zfs clones trump snapshots. zfs SEND to another opensolaris server or offsite trumps clones.

ps – your captachas are too hard!

Thanks for the info. If you mount the shares for (1) tank/home/fred/projects, (2) tank/home/fred/photo & (3) tank/home/fred/video as three separate shares on the client OS then it works fine, at least it works fine for me.

Simon

Sorry about that I did a hack job of copy and pasting. It turns out that what I’m describing is a known limitation in ZFS.

If I create a series of file systems like your fred example and navigate to the parent fred file system over the share (/tank/home/fred) I can only have read/write access to that file system. I will still see the mounted child file systems (e.g. /tank/home/fred/projects) as folders but if I try to read/write to them I will get an access denied message.

Anyway this bug report filed explains it much better than I can.

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

I updated your original comment with your corrections.

A couple of points:

1. I presume you are using SMB/CIFS protocol from your client computer to connect to your shares, and not the actual Samba software which is a free software re-implementation of SMB/CIFS networking protocol?

2. Also, it appears that the ‘zfs set sharesmb=name=fyleow’ within the two blocks above are identical. I presume this is a typo and you have, in fact, used different names for your shares — e.g.:
zfs set sharesmb=name=fyleow tank/home/fyleow
zfs set sharesmb=name=fyleow_music tank/home/fyleow/music

I set up something in a VM using your guide but I’m having trouble with samba. I use OS X 10.5 to access the shares I have set up which are tank/home/fyleow and tank/home/fyleow/music. I use finder to mount tank/home/fyleow and I can see the music directory, but I cannot read or write to it. In order to read and write to music I have to mount tank/home/fyleow/music separately. Any idea what might be the issue here? I don’t want to have to mount each file system under /tank/home/fyleow individually.

I created the following file systems:

zfs create tank/home
zfs create tank/home/fyleow
zfs create tank/home/fyleow/music

Then I applied the following

zfs set aclinherit=passthrough tank/home/fyleow
zfs set aclmode=passthrough tank/home/fyleow
chmod A=owner@:rwxpdDaARWcCos:fd—–:allow,group@:rwxpdDaARWcCos:fd—–:allow,everyone@:rwxpdDaARWcCos:fd—–:deny /tank/home/fyleow/
chown fyleow:fyleow /tank/home/fyleow
zfs set sharesmb=name=fyleow tank/home/fyleow

zfs set aclinherit=passthrough tank/home/fyleow/music
zfs set aclmode=passthrough tank/home/fyleow/music
chmod A=owner@:rwxpdDaARWcCos:fd—–:allow,group@:rwxpdDaARWcCos:fd—–:allow,everyone@:rwxpdDaARWcCos:fd—–:deny /tank/home/fyleow/music
chown fyleow:fyleow /tank/home/fyleow/music
zfs set sharesmb=name=fyleow tank/home/fyleow/music

Cheers,
Simon

# zfs set copies=2 tank/home/fred/photo
# zfs set copies=2 tank/home/fred/video
# zfs set copies=2 tank/home/fred/projects

Early in the post you seem to emphasize the relevance of the media filesystems as being replacable and the home filesystems as being irreplacable, but I don’t see any different in their creation except for access controls.

Can you expand on how else they are treated differently, or at least tell me what I’m missing?

Thanks

root@opensolaris:~# which ls
/usr/gnu/bin/ls

The ACL stuff is pure greek to me so I think I might stick to the regular permission setup for now. Your blog is a great resource for ZFS. Thanks for posting your experiences with it.

If you login as a non-root user, and look where ls and chmod are, you’ll see that they are being found at /usr/gnu/bin:

simon@blackhole:~$ which ls
/usr/gnu/bin/ls
simon@blackhole:~$ which chmod
/usr/gnu/bin/chmod

Whereas if you login as root, you’ll pick up these commands from /usr/bin:

simon@blackhole:~$ su
Password:
simon@blackhole:~# which ls
/usr/bin/ls
simon@blackhole:~# which chmod
/usr/bin/chmod

Thanks for alerting me to this, I’ll have to fix my user’s path to use the more useful ones at /usr/bin which are capable of handling NFSv4 ACLs!

Anyway, out of the box with the default OpenSolaris 2009.06 installation, as root you will have no problems running the commands listed above.

Taking a look at the PATH environment variable for a non-root user we can see that /usr/gnu/bin precedes /usr/bin by default, so I suppose swapping them round should work, with hopefully no strange side-effects… :

simon@blackhole:~$ env | grep ^PATH
PATH=/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin

And for root, we see this:

# env | grep ^PATH
PATH=/usr/sbin:/usr/bin

So root has no /usr/gnu/bin directory in its PATH.

From memory, they changed the functionality of the ‘ls’ and ‘chmod’ commands to handle the ‘new’ NFSv4 ACLs to avoid having to use getacl and setacl commands, but the commands in the default path might be the ‘old’ non-NFSv4 ACL-capable commands, if you see what I mean.

I have recently installed OpenSolaris 2009.06 so I’ll try out these commands a little later tonight when I have time. If you’re in a hurry though, check to see if multiple (probably two) versions of ‘ls’ and ‘chmod’ exist on your OpenSolaris system, and if so, run the commands found at the other location.

Cheers,
Simon

Sorry if this is a dumb question but does your guide only work for Solaris 10 and not Open Solaris? I am trying some commands with Open Solaris 2009.06 and I’m encountering issues.

The ls command doesn’t have the -V option

$ touch test
$ ls -V test
ls: invalid option — V
Try `ls –help’ for more information.

The chmod command doesn’t seem to work.

/tank/media$ chmod A=\
> owner@:rwxpdDaARWcCos:fd—–:allow,\
> group@:rwxpdDaARWcCos:fd—–:allow,\
> everyone@:rwxpdDaARWcCos:fd—–:deny \
> /tank/home/media
chmod: invalid mode: `A=owner@:rwxpdDaARWcCos:fd—–:allow,group@:rwxpdDaARWcCos:fd—–:allow,everyone@:rwxpdDaARWcCos:fd—–:deny’
Try `chmod –help’ for more information.

Additionally when I copy files over from my OS X machine over SMB I get some weird permissions. The files show up as ———- permissions but I can still access them fine. This is a bit different from what I’m used to because if a file had that permission on Linux it would not be readable even by the owner.

Thanks for the info relating to ACLs for making CIFS shares reliably accessible from Windows environments.

When I spend more time investigating access from Windows environments I will take your comments into account.

When I was researching the ACL subject a couple of months ago, I found a very useful forum comment written by an experienced Windows systems administrator, and this is what he said (abbreviated):

Ok, as a long term windows admin, I’m going to chip in with a couple of comments here.

Firstly, I should make clear that I think the CIFS team have done a cracking job with this. An OpenSolaris file server works pretty much exactly like a windows fileserver, which is a huge improvement over Samba.

We looked at Samba and found that it was completely unworkable in a Windows environment. OpenSolaris on the other hand allows us to keep our existing windows permissions and migrate them directly over.

Windows and Unix treat deny entries very differently. Personally, every time I set up a CIFS share, I grant rights to everybody and from that point on do all my permission setting from windows. From the top of my head, the syntax is something like:

# chmod A=everyone@:full_set:fd /path

…

Yes, it gets complex if you’re working with files both in Windows and Unix, but that’s what the user mapping functionality is for.

…

On the contrary, standard permissions working just like a windows server, and managable with the windows tools is *exactly* what I expected. Yes, there’s a bit of a learning curve to get OpenSolaris working, but I’ve been a windows admin for many years now, and I’m very, very impressed with this.

Ross

For more details, see the comment from myxiplx (Ross) @ Apr 9, 2009 5:27 AM here:
http://opensolaris.org/jive/message.jspa?messageID=365620#365620

At least you shouldn’t DENY (aRcs) for everyone@. It should work to leave these flags undefined in deny and allow for @everyone so later ACL entries can do the work…
The last question would be how to finally deny these rights for unauthorized users?

I’ve looked around a little bit in ACL docs and (hopefully) understand the reason for my above mentioned problems:

Windows ACL handling differs from ZFS: Windows first applies all DENY rules and only afterwards the ALLOW rules while ZFS handles ACLs in the given order. Thats the reason why you need to grant at least the above rights (aRcS) to everyone@ when using Windows clients.

Otherwise your access may be denied before your intended ALLOW comes into place.

you may run in problems, when denying ALL rights for group everyone (chmod A=everyone@:full_set:fd:deny). We encountered repeated access problems while working on shares from XP clients. This results in write/application errors on the client side even when you are owner and have owner@:full_set:fd:allow permissions on file and directory.

Although I must admit that for the above reason I don’t exactly understand why, we keep at least the following allowed to avoid these problems
everyone@:——a-R-c–s:——-:allow

Furthermore on 2008.11 we encountered strange ACL inheritance behaviour when setting ACL rights on server side via chmod. We ended in
1. doing full_set allows for @owner/@group/@everyone on CIFS share
2. revoking (and afterwards setting) rights on client side

I found hints to do so here: http://www.aspdeveloper.net/tiki-index.php?page=SolarisCIFSPermissions
(Thank you “steveradich”!)