Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Can't export rar2fs filesystem via kernel-nfsd on freebsd #7

Closed
hasse69 opened this issue Mar 13, 2015 · 28 comments
Closed

Can't export rar2fs filesystem via kernel-nfsd on freebsd #7

hasse69 opened this issue Mar 13, 2015 · 28 comments
Labels
Defect Priority-Medium

Comments

@hasse69
Copy link
Owner

hasse69 commented Mar 13, 2015 

When trying to export a rar2fs filesystem via freebsd's kernel-nfsd I get:

Jun  2 00:27:58 collected mountd[14470]: getvfsbyname() failed for fusefs.rar2fs
Jun  2 00:27:58 collected mountd[14470]: can't export /mnt/RMedia 
Jun  2 00:27:58 collected mountd[14470]: bad exports list line /mnt/RMedia      -network 192.168.1 -mask 255.255.255.0

(that export line is correct, works for the original fs).

I think the first line is key here ;)

Original issue reported on code.google.com by wiebel on 2011-06-01
@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

And again, it seems not to be limmited to rar2fs, fuse-mhddfs fails in a same manner.

Original issue reported on code.google.com by wiebel on 2011-06-01 22:38:55

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Try this one

Original issue reported on code.google.com by hasse69 on 2011-06-01 22:40:35

- _Attachment: [rar2fs.c](https://storage.googleapis.com/google-code-attachments/rar2fs/issue-7/comment-3/rar2fs.c)_

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Same error and same messages in logs

Original issue reported on code.google.com by wiebel on 2011-06-01 22:44:38

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

hmm no the vfs error is gone btw.

Original issue reported on code.google.com by wiebel on 2011-06-01 22:48:10

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Also tested with sshfs , same errors

Original issue reported on code.google.com by wiebel on 2011-06-01 22:51:21

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Googling on this error message gave some hints.
But if it applies to your system or not is hard to tell.
Exactly what version of FreeBSD are you running ?

Original issue reported on code.google.com by hasse69 on 2011-06-01 22:52:16

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

I'm running FreeBSD 8.2 , 64 bits

Original issue reported on code.google.com by wiebel on 2011-06-01 22:55:45

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

How does your export file look like?
If I recall correctly, fuse requires the fsid option to be set.

I checked the getvfsbyname() man page and the error it can throw is

ERRORS
     The following errors may be reported:

     [EFAULT]           The vfc pointer contains an invalid address.

     [ENOENT]           The name specifies a filesystem that is unknown or not configured
in the kernel.


You probably got ENOENT because rar2fs.fuse is not known to the system, but fuse is
which is the deafult. But since you still get the problem that is probably not the
real reason why it fails.
This is my /etc/exports line for a rar2fs folder:
"/share/HDA_DATA/export11" *(ro,async,no_root_squash,fsid=9)

Original issue reported on code.google.com by hasse69 on 2011-06-01 23:02:48

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

I'm guessing your export line is from linux?
Bsd export looks like:

/mnt/RMedia     -network 192.168.1 -mask 255.255.255.0

Original issue reported on code.google.com by wiebel on 2011-06-01 23:05:32

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Yes, but fsid is still a NFS export option so BSD should be able to provide it somehow.

Original issue reported on code.google.com by hasse69 on 2011-06-01 23:08:28

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Nothing in the exports manual is giving me something useful on this.

Original issue reported on code.google.com by wiebel on 2011-06-01 23:16:51

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

On http://fuse4bsd.creo.hu/doc/html_single_out/doc.html I read:

"In BSD, some of the arguments of the readdir handler are there only for the sake of
NFS: you have to process them appropriately if you want your filesystem to be NFS exportable.
You can ignore them if that’s not a concern."

Does this make any sense to you? :)

Original issue reported on code.google.com by wiebel on 2011-06-01 23:19:20

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Ok, but how do you provide export options like rw, no_root_squash etc ?

Original issue reported on code.google.com by hasse69 on 2011-06-01 23:20:48

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

there is an -maproot option and -rw/-ro option

Original issue reported on code.google.com by wiebel on 2011-06-01 23:25:32

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Ok, I doubled checked the FreeBSD man page and you are right. Nothing is mentioned about
this. Maybe the fsid option is Linux specific (again!).
Need to take a short break now (=sleep) but we can continue this tomorrow...

Original issue reported on code.google.com by hasse69 on 2011-06-01 23:35:23

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Sleep, that's a good idea :)
Tomorrow I might be less responsive since it's a holiday over here and i might need
to give my wife and kid some extra attention :P

Original issue reported on code.google.com by wiebel on 2011-06-01 23:37:25

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Could this also be a permission problem ?

Original issue reported on code.google.com by hasse69 on 2011-06-02 10:24:13

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

I Don't think so, since nfsd runs as root and other filesystems work fine as long as
they are not fuse :)

Original issue reported on code.google.com by wiebel on 2011-06-02 10:33:52

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Yes, maybe. 
I will try from here too. I have a FreeBSD vmware image, only 32-bit though but it
should not matter. Do not know when I get the time though, holliday in Sweden as well
;)

Original issue reported on code.google.com by hasse69 on 2011-06-02 11:24:35

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Take your time, maybe you'll find love for freebsd in the process :P

Original issue reported on code.google.com by wiebel on 2011-06-02 11:44:52

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Well I get another problem when mounting from Linux.
Might be related though. In this case there seems to be something with permission.

root@ubuntu:~# mount -t nfs -o defaults 192.168.0.113:/exportfs export
mount.nfs: access denied by server while mounting 192.168.0.113:/exportfs

It works fine if I do not mount my fuse file system on top of /exportfs :(

Original issue reported on code.google.com by hasse69 on 2011-06-03 19:21:46

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Where do you mount it then? and what is the difference between /exportfs and the other
mountpoint?

Original issue reported on code.google.com by wiebel on 2011-06-05 14:45:38

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

/exportfs is the exported folder on the FreeBSD server. export is the target folder
on the client. All folders are uid=0,gid=0. I have no problem mounting the folder if
exportfs is not a FUSE mount point. So there is something with kernel NFS and fuse4freebsd.
I use kernel NFS when both client and server is Linux and it works fine.

Original issue reported on code.google.com by hasse69 on 2011-06-06 07:20:33

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

This is what I noticed as well :) 
I'm just not smart enough to figure out how to fix it, if even possible :D

Original issue reported on code.google.com by wiebel on 2011-06-06 16:15:19

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Well, I tried to figure out why the server gives me a permission denied. But so far
no luck :( I can see some callbacks being made by FUSE during the connection attempt,
but the last call is statfs() and I see nothing wrong with it. Neither nfsd nor mountd
in debug mode provide any hints to why the client is refused access. This could be
yet another limitation in the FreeBSD port of FUSE. Maybe there is where the answers
can be found?

Original issue reported on code.google.com by hasse69 on 2011-06-06 20:15:31

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

I'm afraid that will be the case indeed :/
We'll have to do with unfsd then :)

Original issue reported on code.google.com by wiebel on 2011-06-06 21:26:49

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Ok, this is not a unique problem to freebsd. I used to be a problem also for older Linux
kernels. But there was a patch made for it and the kernel module also needs to be built
to support NFS export through the kernel interface. My guess is that fuse4freebsd has
neither ? 
See this thread for more information
http://old.nabble.com/export-fuse-for-NFS-td27357628.html

Original issue reported on code.google.com by hasse69 on 2011-06-07 08:05:21

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015 

Hmmz that's to bad. I tried mailing the dev of fuse4bsd, but no reply so far...

Original issue reported on code.google.com by wiebel on 2011-06-07 15:45:07

@hasse69 hasse69 closed this as completed May 2, 2015
@zappepappe zappepappe mentioned this issue Jan 24, 2017
Closed
hasse69 pushed a commit that referenced this issue Feb 15, 2021
Fix race condition at directory cache invalidation
0cad225 
Commit 33af7aa did not completely
solve the problem(s) reported in issue #151.
After running valgrind/helgrind a race condition was spotted with
the following signature:

==29979== Possible data race during write of size 8 at 0x62E2F20 by thread #7
==29979== Locks held: none
==29979==    at 0x411D6B: hashtable_entry_delete_hash (string3.h:52)
==29979==    by 0x412180: hashtable_entry_delete_subkeys (hashtable.c:250)
==29979==    by 0x4126EE: dircache_get (dircache.c:195)
==29979==    by 0x41BC63: syncdir (rar2fs.c:3082)
==29979==    by 0x41BF12: rar2_getattr (rar2fs.c:3203)
==29979==    by 0x4E4534F: lookup_path (fuse.c:2472)

The problem is caused by a missing rwlock when detecting stale cache
entries and when such entries were invalidated.
This patch also adds a few missing locks spotted by pure inspection
of the code and which were not part of the use-case covered by the
valgrind/helgrind test run.

Resolves-issue: #151
Signed-off-by: Hans Beckerus <hans.beckerus at gmail.com>
@andree392 andree392 mentioned this issue Jul 13, 2021
Closed
@Nischi85 Nischi85 mentioned this issue Oct 9, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Defect Priority-Medium
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@hasse69