-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I''ve got a pool, and a fs called public. Public should contain various directories which I would like to keep on separate zfs''s for backup reasons. Public should be shared so users can map that as a drive in windows xp. The problem is that the zfs''s under public cannot be accessed when public is mapped. I don''t want to have to map each section of public to a separate drive letter. Is this a limitation that I cannot access a fs inside a share or is there something up with how I''m trying to do it? If this is a restriction and I really can''t access individual zfs''s under one share, i guess i will have to have 6 network drives instead of one but this will of course confuse the users no end. Thanks - -- Matt Harrison iwasinnamuknow at genestate.com http://mattharrison.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkhh5qoACgkQxNZfa+YAUWF1RACdG62/V6kXHgC6zdec8EZIXT0W O54An3a1C+18el0uMhGk1XgTHvMpTc3H =It+X -----END PGP SIGNATURE-----
Your terminology is a bit confusing for me, so: you have 1 pool (zpool create) you have a FS called public (zfs create?) what do you mean by "keep on separate zfs''s"? You mean ZFS snapshot? Thanks, Afshin Matt Harrison wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I''ve got a pool, and a fs called public. Public should contain various > directories which I would like to keep on separate zfs''s for backup reasons. > > Public should be shared so users can map that as a drive in windows xp. > The problem is that the zfs''s under public cannot be accessed when > public is mapped. I don''t want to have to map each section of public to > a separate drive letter. > > Is this a limitation that I cannot access a fs inside a share or is > there something up with how I''m trying to do it? > > If this is a restriction and I really can''t access individual zfs''s > under one share, i guess i will have to have 6 network drives instead of > one but this will of course confuse the users no end. > > Thanks > > - -- > Matt Harrison > iwasinnamuknow at genestate.com > http://mattharrison.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAkhh5qoACgkQxNZfa+YAUWF1RACdG62/V6kXHgC6zdec8EZIXT0W > O54An3a1C+18el0uMhGk1XgTHvMpTc3H > =It+X > -----END PGP SIGNATURE----- > _______________________________________________ > cifs-discuss mailing list > cifs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Afshin Salek wrote: | Your terminology is a bit confusing for me, so: Sorry i should have worded this much better, | you have 1 pool (zpool create) | you have a FS called public (zfs create?) | | what do you mean by "keep on separate zfs''s"? You | mean ZFS snapshot? Ok, I''ll start again: I have a pool "zpool create tank [...]" Then I made a zfs "zfs create [...] tank/public" Now I want to keep the sections of public separate, i.e on individual zfs. So I do "zfs create [...] tank/public/audio" The problem is that if public is shared via smb, the user is unable to access audio. It seems that if a zfs is shared, the child zfs'' are not accessible as it would if they were just subdirectories. So I can do "cd /tank/public; mkdir audio" which gives users access to public/audio via the public share, but it doesn''t allow detailed management of audio as it would with individual zfs''. I hope this is a better explanation, Thanks - -- Matt Harrison iwasinnamuknow at genestate.com http://mattharrison.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkhjEBAACgkQxNZfa+YAUWFSfwCfQxvONHtrqsf5F2FcUNYIRA8L SDYAoL2vFdRx0WNN5wn7jnBY1ddIYod+ =zKm1 -----END PGP SIGNATURE-----
Chris Cosby
2008-Jun-26 04:21 UTC
[zfs-discuss] Fwd: [cifs-discuss] sharesmb on multiple fs
On Wed, Jun 25, 2008 at 11:42 PM, Matt Harrison < iwasinnamuknow at genestate.com> wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Afshin Salek wrote: > | Your terminology is a bit confusing for me, so: > > Sorry i should have worded this much better, > > | you have 1 pool (zpool create) > | you have a FS called public (zfs create?) > | > | what do you mean by "keep on separate zfs''s"? You > | mean ZFS snapshot? > > Ok, I''ll start again: > > I have a pool "zpool create tank [...]" > > Then I made a zfs "zfs create [...] tank/public" > > Now I want to keep the sections of public separate, i.e on individual zfs. > > So I do "zfs create [...] tank/public/audio" > > The problem is that if public is shared via smb, the user is unable to > access audio. It seems that if a zfs is shared, the child zfs'' are not > accessible as it would if they were just subdirectories. >You''re absolutely correct - and it''s because the "child zfs''", we''ll call them "filesystems" since that''s what they are, are not directories. The OS treats mount points differently than it does simple directories. Think of each of those ZFS entities just as you would if they weren''t mounted under the same parent. i.e. If you had /home/floyd and /usr/local/pink - you wouldn''t try to setup a smb share under / and descend all of the way down. The way you describe your wants, you want to create a different share for each of the children anyway, so just do it. Oh, and this isn''t a ZFS limitation, it''s an architecture limitation. i.e. You''re Doing It Wrong (TM).> > So I can do "cd /tank/public; mkdir audio" which gives users access to > public/audio via the public share, but it doesn''t allow detailed > management of audio as it would with individual zfs''. > > I hope this is a better explanation, > > Thanks > > - -- > Matt Harrison > iwasinnamuknow at genestate.com > http://mattharrison.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAkhjEBAACgkQxNZfa+YAUWFSfwCfQxvONHtrqsf5F2FcUNYIRA8L > SDYAoL2vFdRx0WNN5wn7jnBY1ddIYod+ > =zKm1 > -----END PGP SIGNATURE----- > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >-- chris -at- microcozm -dot- net === Si Hoc Legere Scis Nimium Eruditionis Habes -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20080626/8727838d/attachment.html>