Michael,
In fact, I was doing some testing with permissions using
storage.owner-gid and storage.owner-uid too.
The confusion seems to really be totally related to permissions.
I guess, I have to equalize them in any way.
Em 27-06-2014 10:19, Michael DePaulo escreveu:
1st of all, IMHO, if Volnei is having a permissions problem, and he is
instead getting the I/O error message he mentioned in his 1st email,
then that is a bug.
2nd, Volnei
From the manpage (4.1.6):
public
This parameter is a synonym for guest ok.
guest ok (S)
If this parameter is yes for a service, then no password is
required to connect to the service. Privileges will be those of the
guest account.
This parameter nullifies the benefits of setting restrict
anonymous = 2
See the section below on security for more information
about this option.
Default: guest ok = no
guest ok / public does not grant any particular level of privileges to
the samba guest account. The samba guest account is still mapped to
the UNIX "nobody" account by default. (see the manpage entry for
"guest account"). "force user = root" overrides that mapping.
Similarly, "writable" does not imply that every user account that can
access the share can write to it. It means that they can write to it
if they have write permissions. "writable" is simply a way of making
the entire share read-only or not read-only. Either way, users can
only read from it if they have read (and execute) permissions. IMHO,
now that "security = share" has been removed from samba, "writable"
should default to "yes".
It sounds like the following is the problem/solution:
1. You need to give write permissions on the root dir to either the
guest account mapped user ("nobody" by default), or to all users.
2. You need to set the following so that guests can write to newly
created subdirs:
directory mask = 777
The manpage on "create mask" states: This parameter does not affect
directory masks. See the parameter "directory mask" for details.
Let us know if this works,
-Mike
On Fri, Jun 27, 2014 at 8:00 AM, Volnei <volnei@xxxxxxxxxxxxxxx> wrote:
Well..
I did some more tests and found the following:
In the root folder can't really write data, but only read.
I noticed that if I use the parameters "force user = root" and "force
group = root", I can read and write, but what strikes me is that this
share is set as "public".
I will continue to do tests
On Fri, June 27, 2014 2:41 am, Daniel Müller wrote:
glusterfs:volume= yourmountedglustervol
glusterfs:volfile_server = 172.17.1.1 <--simetimes needed the ip
Good Luck
Daniel
EDV Daniel Müller
EDV Daniel Müller
Leitung EDV
Tropenklinik Paul-Lechler-Krankenhaus
Paul-Lechler-Str. 24
72076 Tübingen
Tel.: 07071/206-463, Fax: 07071/206-499
eMail: mueller@xxxxxxxxxxxxxxx
Internet: www.tropenklinik.de
-----Ursprüngliche Nachricht-----
Von: gluster-users-bounces@xxxxxxxxxxx
[mailto:gluster-users-bounces@xxxxxxxxxxx] Im Auftrag von Lalatendu
Mohanty
Gesendet: Freitag, 27. Juni 2014 06:45
An: Michael DePaulo; Volnei
Cc: gluster-users@xxxxxxxxxxx
Betreff: Re: Strange problem using samba_vfs_gluster
On 06/27/2014 06:04 AM, Michael DePaulo wrote:
On Thu, Jun 26, 2014 at 8:20 AM, Volnei <volnei@xxxxxxxxxxxxxxx> wrote:
Hi,
If I use the configuration method "vfs" I can see the share, But I
cannot write anything into it. On Windows7, for example, the following
message is showed:
Error 0x8007045D: the request could not be performed because of an
I/O device error ever I try create a folder or a file.
If I use the configuration at mount point, then everything works
perfectly.
This is a bug or I'm doing something wrong.
Thanks a lot
(smb.conf)
[GV0-GLUSTERFS]
comment = For samba share of volume gv0 path = / writable = Yes read only
= No
guest ok = Yes browseable = yes create mask = 0777 kernel share modes =
No
vfs objects = glusterfs glusterfs:loglevel = 7
glusterfs:logfile = /var/log/samba/glusterfs-testvol.log
glusterfs:volume = gv0
# This works fine
#[GLUSTERFS_DATAS]
# comment = glusterfs via mountpoint
# path = /mnt/dados
# writable = Yes
# guest ok = Yes
# browseable = yes
# create mask = 0777
Erro message when I use vfs_gluster
[2014-06-26 12:06:57.293530] E
[afr-self-heal-common.c:233:afr_sh_print_split_brain_log]
0-gv0-replicate-0:
Unable to self-heal contents of '/.' (possible split-brain). Please
delete the file from all but the preferred subvolume.- Pending matrix:
[ [ 0 2 ] [
2 0 ] ]
[2014-06-26 12:06:57.294679] E
[afr-self-heal-common.c:2859:afr_log_self_heal_completion_status]
0-gv0-replicate-0: metadata self heal failed, on /.
Versions:
samba-4.1.9-3.fc20.x86_64 samba-vfs-glusterfs-4.1.9-3.fc20.x86_64
samba-common-4.1.9-3.fc20.x86_64 samba-winbind-4.1.9-3.fc20.x86_64
samba-winbind-clients-4.1.9-3.fc20.x86_64
samba-libs-4.1.9-3.fc20.x86_64
samba-winbind-modules-4.1.9-3.fc20.x86_64
samba-winbind-krb5-locator-4.1.9-3.fc20.x86_64
samba-client-4.1.9-3.fc20.x86_64
glusterfs-fuse-3.5.0-3.fc20.x86_64
glusterfs-server-3.5.0-3.fc20.x86_64
glusterfs-libs-3.5.0-3.fc20.x86_64 glusterfs-api-3.5.0-3.fc20.x86_64
glusterfs-cli-3.5.0-3.fc20.x86_64 glusterfs-3.5.0-3.fc20.x86_64
On a related note, has anyone had success using samba_vfs_gluster with
glusterfs 3.5.x instead of 3.4.x? Is it even supported?
The example post uses 3.4.x:
http://lalatendumohanty.wordpress.com/2014/02/11/using-glusterfs-with-
samba-and-samba-vfs-plugin-for-glusterfs-on-fedora-20/
_______________________________________________
I think I had tested early versions of glusterfs 3.5.0 with samba vfs
plugin and it had worked fine. It should work as mentioned in the above
blog post. If it is not working, then it might be a genuine bug or
configuration issue.
-Lala
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-users
