Re: [zfs-discuss] What are .$EXTEND directories?
On 1/3/11 10:51 AM, Chris Ridd wrote: On 3 Jan 2011, at 17:08, Volker A. Brandt wrote: On our build 147 server (pool version 22) I've noticed that some directories called ".$EXTEND" (no quotes) are appearing underneath some shared NFS filesystems, containing an empty file called "$QUOTA". We aren't using quotas. What are these ? Googling for the names doesn't really work too well :-( I don't think they're doing any harm, but I'm curious. Someone's bound to notice and ask me as well :-) Well, googling for '.$EXTEND' and '$QUOTA' does give some results, especially when combined with 'NTFS'. :-) Aha! Foolishly I'd used zfs in my search string :-) Check out the table on "Metafiles" here: http://en.wikipedia.org/wiki/NTFS OK, so they're probably an artefact of having set sharesmb=on, even though I've not joined the box to a domain yet. Those objects are created automatically when you share a dataset over SMB to support remote ZFS user/group quota management from the Windows desktop. The dot in .$EXTEND is to make the directory less intrusive on Solaris. There is no Solaris or ZFS functionality associated with those objects and you can safely delete them on ZFS: they will be recreated as required whenever the dataset is shared over SMB. For more information on those files, look for Quota Tracking in http://msdn.microsoft.com/en-us/library/ms995846.aspx Alan ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Interesting/Strange Problem
The chown may affect access - possibly due to user ACE versus owner@ ACE behavior. A user ACE always refers to the specific user mentioned in the ACE. An owner@ ACE applies to the current owner of the file, which changes with chown. owner@ represents the typical, expected behavior on UNIX but can produce confusing results on Windows. Alan On 12/17/10 1:24 AM, artiepen wrote: I'm using zfs/osol snv_134. I have 2 zfs volumes: /zpool1/test/share1 and /zpool1/test/share2. share1 is using CIFS, share2: nfs. I've recently put a cronjob in place that changes the ownership of share2 to a user and a group, on the test filer every 5 minutes. The cron job actually runs in opensolaris on the storage unit. After a day or two, I started noticing that an application I have that lives on share1 will no longer open because it can't find its dll's. The only way to fix it is to reset the ownership of the entire subdir...from a Windows client. I don't even have to change it, just reset it. Security->Advanced->Owner->Replace owner on... Soon afterwards, I notice that the program doesn't work, for the same reason. I have to reset the permissions over and over again to get the application to load its dlls. I've also noticed that resetting the owner isn't the only thing that "fixes" it. I can also add, apply and remove the "Archive" attribute from Windows. It wasn't too long before I put 2 and 2 together and removed my cron job from crontab. Magically, the application, which lives on a completely different share, started working again without needing to be reset. Can anyone explain this bizarreness to me? Is there a reason or is it just a bug with this development version? Has it happened to anyone else? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] vidoe files residing on zfs used from cifs fail to work
What are the property settings on your dataset? Alan On 11/22/10 6:34 AM, Harry Putnam wrote: Harry wrote: When *.mov file reside on a windows host, and assuming your browser has the right plugins, you can open them with either quicktime player or firefox (which also uses the quicktime player). But I find if the files are on a zfs server the same files fail to play. Is it a local phenomena or a common problem/ I've also had similar problems with *.avi contained files (not sure of compressor). Ian Collins writes: Not for me, I've been sharing all forms of media via CIFS to windows clients for a couple of years or more. Good news there thanks for the input. Harry wrote: On 11/21/10 Nov 21, 8:43 PM, "Harry Putnam" wrote: When *.mov file reside on a windows host, and assuming your browser has the right plugins, you can open them with either quicktime player or firefox (which also uses the quicktime player). But I find if the files are on a zfs server the same files fail to play. Is it a local phenomena or a common problem? Dave Pooser writes: We don't have that problem, and we have roughly 25TB of QuickTime files on an OpenSolaris box shared over CIFS to mostly Mac clients. Good news again. Good to know it can work just as I hoped it would. You say `mostly Mac' so I guess some windows clients are involved as well. And no problems with them either? Just to be sure of something here. Are either or both of you sharing these files in the sense of storing them on zfs and moving to whatever OS for usage or do you mean that files are used in place... that is, the zfs fs is not just storing files but the files are being used by other OSs in place? It sounds like maybe both situation would apply to either of you. If that is true then any ideas where to start digging as to why I see the problem. I realize that will be OT here but maybe a suggestion of URL or a pointer to a newsgroup where the topic would be more friendly? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharesmb should be ignored if filesystem is not mounted
On 11/ 4/10 03:54 AM, Richard L. Hamilton wrote: On 10/28/10 08:40 AM, Richard L. Hamilton wrote: I have sharesmb=on set for a bunch of filesystems, including three that weren't mounted. Nevertheless, all of those are advertised. Needless to say, the one that isn't mounted can't be accessed remotely, even though since advertised, it looks like it could be. When you say "advertised" do you mean that it appears in /etc/dfs/sharetab when the dataset is not mounted and/or you can see it from a client with 'net view' on a client? I'm using a recent build and I see the smb share disappear from both when the dataset is unmounted. I could see it in Finder on a Mac client; presumably were I on a Windows client, it would have appeared with "net view". I've since turned off the sharesmb property on those filesystems, so I may need to reboot (which I'd much rather not) to re-create the problem. That's fine. If you see it again, try svcadm restart smb/server My guess is that smbd had stale cache entries for those shares. This area was reworked in snv_149 and that smbd cache was eliminated. But if recent builds don't have the problem, that's the main thing. The following update was pushed to snv_149: PSARC/2010/154 Unified sharing system call 6968897 sharefs: Unified sharing system call Alan ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharesmb should be ignored if filesystem is not mounted
On 10/28/10 08:40 AM, Richard L. Hamilton wrote: I have sharesmb=on set for a bunch of filesystems, including three that weren't mounted. Nevertheless, all of those are advertised. Needless to say, the one that isn't mounted can't be accessed remotely, even though since advertised, it looks like it could be. When you say "advertised" do you mean that it appears in /etc/dfs/sharetab when the dataset is not mounted and/or you can see it from a client with 'net view' on a client? I'm using a recent build and I see the smb share disappear from both when the dataset is unmounted. Alan # zfs list -o name,mountpoint,sharesmb,mounted|awk '$(NF-1)!="off"&& $(NF-1)!="-"&& $NF!="yes"' NAME MOUNTPOINT SHARESMB MOUNTED rpool/ROOT legacy on no rpool/ROOT/snv_129 / on no rpool/ROOT/snv_93 /tmp/.alt.luupdall.22709on no # So I think that if a zfs filesystem is not mounted, sharesmb should be ignored. This is in snv_97 (SXCE; with a pending LU BE not yet activated, and an old one no longer active); I don't know if it's still a problem in current builds that unmounted filesystems are advertised, but if it is, I can see how it could confuse clients. So I thought I'd mention it. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Basic ACL usage in group environment
On 10/26/10 06:25 AM, Andy Graybeal wrote: Yes, if you set up the directory ACLs for inheritance (include :fd: when you specify the ACEs), the ACLs on copied files will be inherited from the parent folder (probably best not to use cp -p). Alan Alan, thank you for the response. For my example, I have two users that need to share files, candida and andy. I've created both users andy and candida, I've created a finance group I've added andy and candida to the 'finance' group I've created /srv/Finance directory I've set: chown candida:finance /srv/Finance I've then done: /bin/chmod g+s /srv/Finance Then I've done: /bin/chmod A=owner@:full_set:fd:allow,group@:full_set:fd:allow,everyone@:read_set:fd:allow Finance When I touch files in the Finance folder they don't seem to inherit the group's "Full Set". The user candida can read but not edit files I make as the user andy. I suspect you want aclinherit=passthrough Alan what am I doing wrong? is it a umask thing? my umask is 0022, and I thought ACL's override umask. Please help my confusion :) -Andy ___ 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] Basic ACL usage in group environment
On 10/23/10 08:03 AM, Andy Graybeal wrote: Greetings, First off, I'm new to this and don't quite understand what I'm doing. I would like different groups in my workplace to have their own folders. I would like each file and folder underneath the parent folders to inherit the ACL and group ownership of the directory. I'm using ACL's in Ubuntu (ext4) right now and having the problem when someone copies a file from their personal flash drive (People take work home at night and bring it back in the morning) to the drive with ACL's it doesn't inherit the ACL's. SetGID is setting the proper group id though, so this is working. I've used cp in gnome-termimal and drag-n-drop w/ Gnome's filemanager, Nautilus, both have the same effect. When a file is created in the folder, it works great, all the ACL's and ownership is perfect. I'm wondering if I move to ZFS (Opensolaris or Indiana or something ZFS compatible) and use the ACL's in this operating system will it work in the manner I'm anticipating? ie files inherit ACL's no matter if they are created in the folder or copied to the folder, the ACL is the same. Yes, if you set up the directory ACLs for inheritance (include :fd: when you specify the ACEs), the ACLs on copied files will be inherited from the parent folder (probably best not to use cp -p). Alan Am I headed the wrong direction? I need some hand-holding. Thank you, -Andy ___ 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] file-inherit and dir-inherit at toplevel of ZFS CIFS share
On 10/25/10 07:23 AM, David Dyer-Bennet wrote: It looks like permissions don't descend properly from the top-level share in CIFS; I had to set them on the next level down to get the intended results (including on lower levels; they seem to inherit properly from the second level, just not from the top). Is this a known behavior, or am I confused and setting myself up for trouble later? You probably have simple UNIX permission set on the top-level directory. Use ACLs not specific UNIX permissions. If you're not comfortable with setting ACLs via chmod, start with one of the following and tune from Windows: /bin/chmod A=everyone@:full_set:fd:allow /pool/fs or /bin/chmod A=owner@:full_set:fd:allow /pool/fs /bin/chmod A+=group@:read_set/execute:fd:allow /pool/fs /bin/chmod A+=everyone@:read_set/execute:fd:allow /pool/fs More broadly, is there anything good about "best practices" for using ACLS with ZFS and CIFS shares? For example, there are so many defined attributes, some of them with the same short-form letter (I think one is for directories and one is for files in that case, but that's not documented that I can find), that I find myself wondering what "standard bundles" of permissions would be useful. Is it generally better to have separate permissions to inherit for files and directories, or can most things you want be accomplished with just one? The attributes should all be described in the chmod(1) man page. Back to specifics again -- I was running into a problem where a user on the Solaris box could rename a file or directory, but an XP box authenticating as the same user could not. This was the one that seemed to be solved by setting the permissions again one level down (dunno what happens with new top-level items yet). Is this normal behavior of something that makes sense? It's terribly weird. (In windows, I could right-click and create the "new directory" or whatever, but when I then filled in the name I wanted and hit enter, I got a permission error. I could just leave it named "new directory", though. And I could rename it on the Linux side as the same user that failed to rename it from the Windows side.) If you want a Windows-like permission experience: use ACLs rather than perms and ensure 'fd' is set when you set that initial ACL (see above). Alan ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] nfs share of nested zfs directories?
On 05/27/10 09:49 PM, Haudy Kazemi wrote: Brandon High wrote: On Thu, May 27, 2010 at 1:02 PM, Cassandra Pugh wrote: I was wondering if there is a special option to share out a set of nested directories? Currently if I share out a directory with /pool/mydir1/mydir2 on a system, mydir1 shows up, and I can see mydir2, but nothing in mydir2. mydir1 and mydir2 are each a zfs filesystem, each shared with the proper sharenfs permissions. Did I miss a browse or traverse option somewhere? What kind of client are you mounting on? Linux clients don't properly follow nested exports. -B This behavior is not limited to Linux clients nor to nfs shares. I've seen it with Windows (SMB) clients and CIFS shares. The CIFS version is referenced here: Nested ZFS Filesystems in a CIFS Share http://mail.opensolaris.org/pipermail/cifs-discuss/2008-June/000358.html http://bugs.opensolaris.org/view_bug.do?bug_id=6582165 Is there any commonality besides the observed behaviors? No, the SMB/CIFS share limitation is that we have not yet added support for child mounts over SMB; this is completely unrelated to any configuration problems encountered with NFS. Alan ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
