Gluster users - Jan 2019 - Can't write to volume using vim/nano

Check permissions on the mount. I have multiple dozens of systems
mounting 18 "exports" using fuse and it works for multiple user
read/write based on user access permissions to the mount point space.
/home is mounted for 150+ users plus another dozen+ lab storage spaces.
I do manage user access with freeIPA across all systems to keep things
consistent.
On Wed, 2019-01-23 at 19:31 -0200, Lindolfo Meira wrote:
> Am I missing something here? A mere write operation, using vim or
> nano, cannot be performed on a gluster volume mounted over fuse! What
> gives?
> Lindolfo Meira, MScDiretor Geral, Centro Nacional de
> Supercomputa??oUniversidade Federal do Rio Grande do Sul+55 (51)
> 3308-3139_______________________________________________Gluster-users 
> mailing listGluster-users at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-users
-- 
James P. Kinney III

Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain

http://heretothereideas.blogspot.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20190123/771e199a/attachment.html>

Hi Jim. Thanks for taking the time.

Sorry I didn't express myself properly. It's not a simple matter of 
permissions. Users can write to the volume alright. It's when vim and nano 
are used, or when small file writes are performed (by cat or echo), that 
it doesn't work. The file is updated with the write in the server, but it 
shows up as empty in the client.

I guess it has something to do with the size of the write, because I ran a 
test writing to a file one byte at a time, and it never showed up as 
having any content in the client (although in the server it kept growing 
accordingly).

I should point out that I'm using a sharded volume. But when I was testing 
a striped volume, it also happened. Output of "gluster volume info" 
follows bellow:

Volume Name: gfs
Type: Distribute
Volume ID: b5ef065f-1ba2-481f-8108-e8f6d2d3f036
Status: Started
Snapshot Count: 0
Number of Bricks: 6
Transport-type: rdma
Bricks:
Brick1: pfs01-ib:/mnt/data
Brick2: pfs02-ib:/mnt/data
Brick3: pfs03-ib:/mnt/data
Brick4: pfs04-ib:/mnt/data
Brick5: pfs05-ib:/mnt/data
Brick6: pfs06-ib:/mnt/data
Options Reconfigured:
nfs.disable: on
features.shard: on



Lindolfo Meira, MSc
Diretor Geral, Centro Nacional de Supercomputa??o
Universidade Federal do Rio Grande do Sul
+55 (51) 3308-3139

On Wed, 23 Jan 2019, Jim Kinney wrote:
> Check permissions on the mount. I have multiple dozens of systems
> mounting 18 "exports" using fuse and it works for multiple user
> read/write based on user access permissions to the mount point space.
> /home is mounted for 150+ users plus another dozen+ lab storage spaces.
> I do manage user access with freeIPA across all systems to keep things
> consistent.
> On Wed, 2019-01-23 at 19:31 -0200, Lindolfo Meira wrote:
> > Am I missing something here? A mere write operation, using vim or
> > nano, cannot be performed on a gluster volume mounted over fuse! What
> > gives?
> > Lindolfo Meira, MScDiretor Geral, Centro Nacional de
> > Supercomputa??oUniversidade Federal do Rio Grande do Sul+55 (51)
> > 3308-3139_______________________________________________Gluster-users 
> > mailing listGluster-users at gluster.org
> > https://lists.gluster.org/mailman/listinfo/gluster-users
> -- 
> James P. Kinney III
> 
> Every time you stop a school, you will have to build a jail. What you
> gain at one end you lose at the other. It's like feeding a dog on his
> own tail. It won't fatten the dog.
> - Speech 11/23/1900 Mark Twain
> 
> http://heretothereideas.blogspot.com/
> 
>