Problem tested and verified. Debug started.

It was a problem with mknod, which can't be called when using sshfs. 
Now instead of using mknod, we open and close the file.

Hello, I'm having the same problem. I'm using ChironFS 1.1.1 and it uses mknod:

2008/07/09 18:35 mknod failed accessing /tmp/sync2/rem_sync Permission denied
2008/07/09 18:35 disabling replica failed accessing /tmp/sync2/rem_sync

Can you help me?

Thanks,
Felipe

Hello

1) what is the exact mount command (including options used) of ChironFS?
2) which command reproduces the error?
3) who are the users that:
   a) ran the command that failed?
   b) mounted ChironFS?
   c) authenticated via sshfs on the remote host?

Thank you
Best Regards

Hello, thanks for the fast answer.

1) chironfs loc_sync/=rem_sync/ sync/ - (rem_sync is a remote folder with sshfs)
2) touch sync/a
3)
   a) felipem (my user)
   b) felipem (my user)
   c) felipe (other user)

Thanks,
Felipe

Hi Luis, I downloaded the RC4 version and it don't use mknod. Then, it worked fine.
But I would like to use the 1.1.1 without mknod if possible.

Thanks,
Felipe

Luis, only the verion RC6 worked fine with touch and vi commands. The RC4 has a bug
that vi shows "E667: Fsync failed" when editing a file.

Hello Felipe

I've tested and reproduced the problem you reported.

When you create a file in ChironFS, it has to create a file in each of the
replicas. Because ChironFS is a userspace filesystem and not a kernel module,
all the operations it makes are made as the mounting user. So, as you mounted
as felipem, any operation is made as felipem. Creating a file means creating a
file owned by felipem.  If you mount ChironFS with the option allow_other, you
enable other users (in this case other than felipem) to ACCESS the filesystem.
But the operations in each replicas are made by the ChironFS daemon on behalf
of the caller process. So, if user john creates a file in ChironFS, which was
mounted by user felipem, ChironFS will create it as felipem. This were a 
vulnerability in ChironFS in versions before RC7. So, to avoid this, ChironFS
does a chown in every file created to the uid of the calling process.

This is the problem you are facing now: your local user felipem is telling to
the remote user felipe to change the uid of the file to felipem. But in the remote
machine, the user felipe doesn't have enough rights to do so.

Currently you only have the option of running sshfs with root as the remote
user (sshfs root@remotehost /localpath). You may tell sshfs to map the remote
uid to you local uid using the option "-o idmap=user", so every file owned
remotely by root will appear locally as being owned by felipem.

This may be a solution, but maybe it can't be applied to your real situation
if you doesn't have root access to the remote machine.

So, to deal with it, I will introduce a new command-line option which will tell 
ChironFS to not try to chown the file once it is created. As it will be an 
optional behaviour,  not the default, no security problem will be raised: the 
user will be advised to use it only if he knows what he is doing and warned to 
don't use it in conjunction with allow_other.

This new version will be available soon. I will provide a backport to 1.0 series
later.

Thank you for your attention
Best Regards!

Luis Otavio

Hi Luis, do you have a new RPM Version of ChironFS for OpenSuse? Because I found only
the version 1.0.0 of it.

Thanks,
Felipe

I have contacted Leo Eraly, the ChironFS package maintainer
of SUSE flavors and he will create a package of the 1.1.1
version. So, expect it soon.

Best Regards

Hi Luis, do you know if Leo Eraly already has the Suse RPM ChironFS package for the
1.1.1 version?

Thanks,
Felipe

Hello

I mailed him and he created the package chironfs-snapshot. But the
build had problems with some SUSE versions. It failed to build in
SLE 10, OpenSUSE 11.0 and OpenSUSE_Factory. The packages were 
successfully built only on OpenSUSE 10.2 and 10.3. The links are:

http://download.opensuse.org/repositories/home:/leo_eraly/openSUSE_10.3/
http://download.opensuse.org/repositories/home:/leo_eraly/openSUSE_10.2/

Despite the errors, the build system has generated the packages for 
OpenSUSE_Factory:
http://download.opensuse.org/repositories/home:/leo_eraly/openSUSE_Factory/

I will contact you when more packages build successfully.

Thank you!

Best Regards!

Luis Otavio de Colla Furquim