problem with mount_psshfs

[Carsten Kunze]

Hello,

I'm using NetBSD 6.1.4 amd64 with qemu as a guest on Linux. I access my Linux home dir with

mount_psshfs <user>@<IP>:/ /mnt/linux

On Linux I have a dir with permission 700 owned by <user>. If the same user (id) on NetBSD copies a file with permissions 400 into this Linux dir an empty file is created and error message "Operation not permitted" occurs. No matter if -f is used for cp(1). The only way to copy the file correctly is to give an existing Linux file write permissions or to create a Linux file with write permissions. That does not make sense to me. On local NetBSD filesystem everything works as expected. Could there be a bug in mount_psshfs? (I'm using ssh mounts since years on other systems and never noticed this.)

--Carsten

[Greg Troxel]

Post by Carsten Kunze
I'm using NetBSD 6.1.4 amd64 with qemu as a guest on Linux. I access my Linux home dir with
On Linux I have a dir with permission 700 owned by <user>. If the
same user (id) on NetBSD copies a file with permissions 400 into this
Linux dir an empty file is created and error message "Operation not
permitted" occurs. No matter if -f is used for cp(1). The only way
to copy the file correctly is to give an existing Linux file write
permissions or to create a Linux file with write permissions. That
does not make sense to me. On local NetBSD filesystem everything
works as expected. Could there be a bug in mount_psshfs? (I'm using
ssh mounts since years on other systems and never noticed this.)

Yes, there definitely could be a bug. But it's complicated because
there is mount_psshfs, and puffs, and the kernel VFS.

I would run ktrace on mount_psshfs, and after starting it do just the
operation you think should work. Then see what system calls are used.

Wild guess: It could be that cp is using mmap. I have no idea if
mount_psshfs implements mmap or how that works in puffs. But ktrace
will tell you, and you can see which syscall failed, and then chase that
down.

Presumably you have tried sshfs from something else to your linux
system. You should also try psshfs from NetBSD to NetBSD. I'm not
claiming there isn't a NetBSD bug here, just that getting a tighter
characterization would be useful.

[Carsten Kunze]

What's the full command you use to launch your guest? Is it a a raw
file or a real partition? Have you enabled tunnels? Are you using
bridges, tun/tap, etc.

It's a raw file, did not know that partition also would work ;)

I use a bridge. Don't know about tunnels.

I hav really big problems with perl operating on this sshfs.
(Memory fault and other unexpected internal errors I never
saw before.)
Maybe this has also to do with that.

qemu-kvm\
-m 2048\
-hda /mnt/qemu/nbsd614.qemu\
-netdev bridge,id=hn0\
-device virtio-net-pci,netdev=hn0,id=nic1,mac=52:54:00:12:34:57\
-vga std\
-sdl -no-frame\
-usb -usbdevice mouse\
-name NetBSD\
-alt-grab\
-soundhw all

[Carsten Kunze]

Have you started qemu as root or standard user?

I start it as root.

And, just to make sure the problem is not in the bridge, could you
start qemu with user mode networking and enable redirection (check the
manual for the -redir argument).

Long time ago I used user mode networking but now I don't get it working. The -redir option seems not to be well documented--maybe it's obsoltete? (I use qemu 1.2.0.)

I think I use Linux to mount a NetBSD filesystem for the time being...

Thank you all...

[Ottavio Caruso]

Post by Carsten Kunze

What's the full command you use to launch your guest? Is it a a raw
file or a real partition? Have you enabled tunnels? Are you using
bridges, tun/tap, etc.

It's a raw file, did not know that partition also would work ;)
I use a bridge. Don't know about tunnels.
I hav really big problems with perl operating on this sshfs.
(Memory fault and other unexpected internal errors I never
saw before.)
Maybe this has also to do with that.
qemu-kvm\
-m 2048\
-hda /mnt/qemu/nbsd614.qemu\
-netdev bridge,id=hn0\
-device virtio-net-pci,netdev=hn0,id=nic1,mac=52:54:00:12:34:57\
-vga std\
-sdl -no-frame\
-usb -usbdevice mouse\
-name NetBSD\
-alt-grab\
-soundhw all

Have you started qemu as root or standard user?

And, just to make sure the problem is not in the bridge, could you
start qemu with user mode networking and enable redirection (check the
manual for the -redir argument).

[Greg Troxel]

Post by Carsten Kunze

What's the full command you use to launch your guest? Is it a a raw
file or a real partition? Have you enabled tunnels? Are you using
bridges, tun/tap, etc.

It's a raw file, did not know that partition also would work ;)
I use a bridge. Don't know about tunnels.
I hav really big problems with perl operating on this sshfs.
(Memory fault and other unexpected internal errors I never
saw before.)
Maybe this has also to do with that.
qemu-kvm\
-m 2048\
-hda /mnt/qemu/nbsd614.qemu\
-netdev bridge,id=hn0\
-device virtio-net-pci,netdev=hn0,id=nic1,mac=52:54:00:12:34:57\
-vga std\
-sdl -no-frame\
-usb -usbdevice mouse\
-name NetBSD\
-alt-grab\
-soundhw all

Have you started qemu as root or standard user?
And, just to make sure the problem is not in the bridge, could you
start qemu with user mode networking and enable redirection (check the
manual for the -redir argument).

My guess is that if mount_psshfs is even sort of working, and it's about
ro vs rw files, then the OP is not having a networking problem.

[Ottavio Caruso]

Post by Carsten Kunze
I'm using NetBSD 6.1.4 amd64 with qemu as a guest on Linux

What's the full command you use to launch your guest? Is it a a raw
file or a real partition? Have you enabled tunnels? Are you using
bridges, tun/tap, etc.

[Carsten Kunze]

Post by Greg Troxel
My guess is that if mount_psshfs is even sort of working, and it's about
ro vs rw files, then the OP is not having a networking problem.

That makes sense.

What is strange is that cp(1) does not work when the target file is not present (in a 700 dir).
It does only work if a writeable file is present.

Unfortunately I can't use it anyway at the moment. My backup system uses p5-Tk
which seems to cause random memory faults which I saw when testing with ktrace(1).

[Greg Troxel]

Post by Carsten Kunze
What is strange is that cp(1) does not work when the target file is
not present (in a 700 dir). It does only work if a writeable file is
present.

That does not sound so odd to me. cp likely has different code paths to open
an existing file for writing vs a new file.

If the directory is 755, or some other mode, did this not happen?

[Carsten Kunze]

Post by Greg Troxel
That does not sound so odd to me. cp likely has different code paths to open
an existing file for writing vs a new file.
If the directory is 755, or some other mode, did this not happen?

When I copy a file (NetBSD) with 644 perms and owner 1000:0 into a dir (Linux)
with 700 perms and owner 1000:1000 I get:

$ ls -al
total 36028797018963967
drwx------ 2 carsten carsten 60 Aug 7 17:38 ./
drwxrwxrwt 8 root wheel 180 Aug 7 17:36 ../
-rw-r--r-- 1 4294967295 4294967295 6 Aug 7 17:43 a

This scares me... (the number after "total" and the senseless owner ids)

When I now change the local file to 400 I get:

$ cp /tmp/a .
cp: ./a: Operation not permitted

But the file is created *empty* (dir had been empty):

$ ls -la
total 0
drwx------ 2 carsten carsten 60 Aug 7 17:43 ./
drwxrwxrwt 8 root wheel 180 Aug 7 17:36 ../
-r-------- 1 carsten carsten 0 Aug 7 17:44 a

If the dir has 755 it is the same. The problem is the 400 of the source
file. If the source file is 600 it works.

After some tests also the owner ids are ok. Not very reliable...