subject:"Nfs"

On Thu, Jun 01, 2023 at 06:15:35AM +0800, Jazzi Hong wrote:

> Fixed, thanks Otto. I checked this drive and found an error of "BAD
> SUPER BLOCK: MAGIC NUMBER WRONG", it's fixed in the end. So I changed
> the last option of the fstab file from ZERO to TWO thus the command
> fsck can check it automatically. Thank you all for the great help, I
> am so happy my little NAS works again. The OpenBSD community is so
> helpful and there are so many nice people here, hopefully I can serve
> you all a cup of the tea I made from the mountain, actually I am
> making tea today.
> 
> > $ doas fsck -v -t ffs sd0i
> start sd0i wait fsck_ffs sd0i
> ** /dev/sd0i (sd0i)
> 
> BAD SUPER BLOCK: MAGIC NUMBER WRONG
> 
> LOOK FOR ALTERNATE SUPERBLOCKS? [Fyn?] y
> USING ALTERNATE SUPERBLOCK AT 256
> 
> ** File system is already clean
> ** Last Mounted on
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
> FREE BLK COUNT(S) WRONG IN SUPERBLK
> SALVAGE? [Fyn?] y
> 32580 files, 68466851 used, 40554992 free (312 frags, 5069335 blocks,
> 0.0% fragmentation)
> UPDATE STANDARD SUPERBLOCK? [Fyn?] y
> 
> * FILE SYSTEM WAS MODIFIED *
> 
> ===
> Check the drive after fsck
> ===
> ibox$ doas mount /mnt/hdd
> ibox$ ls /mnt/hdd
> Book   Picture???

Good. Some background info: soomething corrupted the standard
(primary) superblock. You might want to think what that could be. 

ffs and ffs2 have extra copies of the of the superblock available and
fskc used the 1st alternate to fix the primary superblock. Only the
summary information then has to be updated, as only the primary
superbock records summary information. This is done by computing a new
summary based on the actual disk contents.

Please use 2 as the last number in fstab lines (except for the root
fs, which whould be 1), unless you have a very good reason to use 0.

-Otto


> 
> On Wed, May 31, 2023 at 10:41 PM Otto Moerbeek  wrote:
> >
> > On Wed, May 31, 2023 at 10:25:06PM +0800, Jazzi Hong wrote:
> >
> > > Thanks for all the help. Hereby is the result of command `disklabel
> > > sd0`, seems the drive is well detected by failed mounted:
> > >
> > > > $ doas disklabel sd0
> > > # /dev/rsd0c:
> > > type: SCSI
> > > disk: SCSI disk
> > > label: SAMSANG ST1000LM
> > > duid: 2b6c2b5b929f9a55
> > >
> > > 16 partitions:
> > > #size   offset  fstype [fsize bsize   cpg]
> > >
> > >   c:   19535251680  unused
> > >   i:   1758185664   64  4.2BSD   8192 65536 52270 # 
> > > /mnt/hdd
> >
> > In your fstab, sd0i is marked ar "do not run fsck on it" (last zero in
> > its fstab line). That is bad.
> >
> > Try running fsck on sd0i. It might be that the filesystem is damaged
> > so mount does not like it, but fsck still has a chance to repair it.
> >
> > -Otto
> >
> > >
> > > On Wed, May 31, 2023 at 7:56 PM Otto Moerbeek  wrote:
> > > >
> > > > On Wed, May 31, 2023 at 11:21:15AM +0100, Zé Loff wrote:
> > > >
> > > > > On Wed, May 31, 2023 at 05:25:07PM +0800, Jazzi Hong wrote:
> > > > > > You made the point, thank you Maksim.
> > > > > > I checked /mnt/hdd and nothing there.
> > > > > > > # cat /etc/fstab
> > > > > > 1593ab2ee369c420.b none swap sw
> > > > > > 1593ab2ee369c420.a / ffs rw 1 1
> > > > > > 1593ab2ee369c420.e /var ffs rw,nodev,nosuid 1 2
> > > > > > 2b6c2b5b929f9a55.i /mnt/hdd ffs rw,noexec,nosuid,nodev 0 0
> > > > > > > # doas sysctl hw.disknames
> > > > > > hw.disknames=sd0:2b6c2b5b929f9a55,sd1:1593ab2ee369c420
> > > > > > > # doas fdisk sd0
> > > > > > Disk: sd0 geometry: 121601/255/63 [1953525168 Sectors]
> > > > > > Offset: 0 Signature: 0xAA55
> > > > > >     Starting Ending LBA Info:
> > > > > >  #: id  C   H   S -  C   H   S [   start:size ]
> > > > > > ---
> > > > > >  0: 00  0   0   0 -  0   0   0 [   0:   0 ] 
> > > > > > unused
> > > > > >  1: 00  0   0   0 -

Re: NFS mounted but shows nothing even df -h has it

2023-05-31 Thread Jazzi Hong

Fixed, thanks Otto. I checked this drive and found an error of "BAD
SUPER BLOCK: MAGIC NUMBER WRONG", it's fixed in the end. So I changed
the last option of the fstab file from ZERO to TWO thus the command
fsck can check it automatically. Thank you all for the great help, I
am so happy my little NAS works again. The OpenBSD community is so
helpful and there are so many nice people here, hopefully I can serve
you all a cup of the tea I made from the mountain, actually I am
making tea today.

> $ doas fsck -v -t ffs sd0i
start sd0i wait fsck_ffs sd0i
** /dev/sd0i (sd0i)

BAD SUPER BLOCK: MAGIC NUMBER WRONG

LOOK FOR ALTERNATE SUPERBLOCKS? [Fyn?] y
USING ALTERNATE SUPERBLOCK AT 256

** File system is already clean
** Last Mounted on
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? [Fyn?] y
32580 files, 68466851 used, 40554992 free (312 frags, 5069335 blocks,
0.0% fragmentation)
UPDATE STANDARD SUPERBLOCK? [Fyn?] y

* FILE SYSTEM WAS MODIFIED *

===
Check the drive after fsck
===
ibox$ doas mount /mnt/hdd
ibox$ ls /mnt/hdd
Book   Picture???

On Wed, May 31, 2023 at 10:41 PM Otto Moerbeek  wrote:
>
> On Wed, May 31, 2023 at 10:25:06PM +0800, Jazzi Hong wrote:
>
> > Thanks for all the help. Hereby is the result of command `disklabel
> > sd0`, seems the drive is well detected by failed mounted:
> >
> > > $ doas disklabel sd0
> > # /dev/rsd0c:
> > type: SCSI
> > disk: SCSI disk
> > label: SAMSANG ST1000LM
> > duid: 2b6c2b5b929f9a55
> >
> > 16 partitions:
> > #size   offset  fstype [fsize bsize   cpg]
> >
> >   c:   19535251680  unused
> >   i:   1758185664   64  4.2BSD   8192 65536 52270 # /mnt/hdd
>
> In your fstab, sd0i is marked ar "do not run fsck on it" (last zero in
> its fstab line). That is bad.
>
> Try running fsck on sd0i. It might be that the filesystem is damaged
> so mount does not like it, but fsck still has a chance to repair it.
>
> -Otto
>
> >
> > On Wed, May 31, 2023 at 7:56 PM Otto Moerbeek  wrote:
> > >
> > > On Wed, May 31, 2023 at 11:21:15AM +0100, Zé Loff wrote:
> > >
> > > > On Wed, May 31, 2023 at 05:25:07PM +0800, Jazzi Hong wrote:
> > > > > You made the point, thank you Maksim.
> > > > > I checked /mnt/hdd and nothing there.
> > > > > > # cat /etc/fstab
> > > > > 1593ab2ee369c420.b none swap sw
> > > > > 1593ab2ee369c420.a / ffs rw 1 1
> > > > > 1593ab2ee369c420.e /var ffs rw,nodev,nosuid 1 2
> > > > > 2b6c2b5b929f9a55.i /mnt/hdd ffs rw,noexec,nosuid,nodev 0 0
> > > > > > # doas sysctl hw.disknames
> > > > > hw.disknames=sd0:2b6c2b5b929f9a55,sd1:1593ab2ee369c420
> > > > > > # doas fdisk sd0
> > > > > Disk: sd0 geometry: 121601/255/63 [1953525168 Sectors]
> > > > > Offset: 0 Signature: 0xAA55
> > > > > Starting Ending LBA Info:
> > > > >  #: id  C   H   S -  C   H   S [   start:size ]
> > > > > ---
> > > > >  0: 00  0   0   0 -  0   0   0 [   0:   0 ] 
> > > > > unused
> > > > >  1: 00  0   0   0 -  0   0   0 [   0:   0 ] 
> > > > > unused
> > > > >  2: 00  0   0   0 -  0   0   0 [   0:   0 ] 
> > > > > unused
> > > > > *3: A6  0   1   2 - 121601  80  63 [  64:  1953525104 ] 
> > > > > OpenBSD
> > > > > 
> > > > > So /dev/sd0 is my NFS share hard disk, and when I tried to mount it 
> > > > > manually:
> > > > > > # doas mount /mnt/hdd
> > > > > mount_ffs: 2b6c2b5b929f9a55.i on /mnt/hdd: Invalid argument
> > > > > +++
> > > > > The error message mentioned about "Invalid argument" of mount, 
> > > > > anything wrong?
> > > > > So the problem now is why can not mount the drive even it's detected?
> > > >
> > > > It can detect the drive, but it doesn't find the i partition.  What does
> > > > disklabel sd0 say?
> > >
> > > Or it can find the i partition but mount_ffs does not like it for some 
> > > reason.
> > > By convention i partitions are often FAT. But we need the dislabel to
> > > see what type it has.
> > >
> > > -Otto
> >
> >
> >
> > --
> > jazzi
> >
> > Best Regard,



-- 
jazzi

Best Regard,

Re: NFS mounted but shows nothing even df -h has it

On Wed, May 31, 2023 at 10:25:06PM +0800, Jazzi Hong wrote:

> Thanks for all the help. Hereby is the result of command `disklabel
> sd0`, seems the drive is well detected by failed mounted:
> 
> > $ doas disklabel sd0
> # /dev/rsd0c:
> type: SCSI
> disk: SCSI disk
> label: SAMSANG ST1000LM
> duid: 2b6c2b5b929f9a55
> 
> 16 partitions:
> #size   offset  fstype [fsize bsize   cpg]
> 
>   c:   19535251680  unused
>   i:   1758185664   64  4.2BSD   8192 65536 52270 # /mnt/hdd

In your fstab, sd0i is marked ar "do not run fsck on it" (last zero in
its fstab line). That is bad.

Try running fsck on sd0i. It might be that the filesystem is damaged
so mount does not like it, but fsck still has a chance to repair it.

-Otto

> 
> On Wed, May 31, 2023 at 7:56 PM Otto Moerbeek  wrote:
> >
> > On Wed, May 31, 2023 at 11:21:15AM +0100, Zé Loff wrote:
> >
> > > On Wed, May 31, 2023 at 05:25:07PM +0800, Jazzi Hong wrote:
> > > > You made the point, thank you Maksim.
> > > > I checked /mnt/hdd and nothing there.
> > > > > # cat /etc/fstab
> > > > 1593ab2ee369c420.b none swap sw
> > > > 1593ab2ee369c420.a / ffs rw 1 1
> > > > 1593ab2ee369c420.e /var ffs rw,nodev,nosuid 1 2
> > > > 2b6c2b5b929f9a55.i /mnt/hdd ffs rw,noexec,nosuid,nodev 0 0
> > > > > # doas sysctl hw.disknames
> > > > hw.disknames=sd0:2b6c2b5b929f9a55,sd1:1593ab2ee369c420
> > > > > # doas fdisk sd0
> > > > Disk: sd0 geometry: 121601/255/63 [1953525168 Sectors]
> > > > Offset: 0 Signature: 0xAA55
> > > > Starting Ending LBA Info:
> > > >  #: id  C   H   S -  C   H   S [   start:size ]
> > > > ---
> > > >  0: 00  0   0   0 -  0   0   0 [   0:   0 ] 
> > > > unused
> > > >  1: 00  0   0   0 -  0   0   0 [   0:   0 ] 
> > > > unused
> > > >  2: 00  0   0   0 -  0   0   0 [   0:   0 ] 
> > > > unused
> > > > *3: A6  0   1   2 - 121601  80  63 [  64:  1953525104 ] 
> > > > OpenBSD
> > > > 
> > > > So /dev/sd0 is my NFS share hard disk, and when I tried to mount it 
> > > > manually:
> > > > > # doas mount /mnt/hdd
> > > > mount_ffs: 2b6c2b5b929f9a55.i on /mnt/hdd: Invalid argument
> > > > +++
> > > > The error message mentioned about "Invalid argument" of mount, anything 
> > > > wrong?
> > > > So the problem now is why can not mount the drive even it's detected?
> > >
> > > It can detect the drive, but it doesn't find the i partition.  What does
> > > disklabel sd0 say?
> >
> > Or it can find the i partition but mount_ffs does not like it for some 
> > reason.
> > By convention i partitions are often FAT. But we need the dislabel to
> > see what type it has.
> >
> > -Otto
> 
> 
> 
> -- 
> jazzi
> 
> Best Regard,

Re: NFS mounted but shows nothing even df -h has it

2023-05-31 Thread Jazzi Hong

Thanks for all the help. Hereby is the result of command `disklabel
sd0`, seems the drive is well detected by failed mounted:

> $ doas disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: SAMSANG ST1000LM
duid: 2b6c2b5b929f9a55

16 partitions:
#size   offset  fstype [fsize bsize   cpg]

  c:   19535251680  unused
  i:   1758185664   64  4.2BSD   8192 65536 52270 # /mnt/hdd

On Wed, May 31, 2023 at 7:56 PM Otto Moerbeek  wrote:
>
> On Wed, May 31, 2023 at 11:21:15AM +0100, Zé Loff wrote:
>
> > On Wed, May 31, 2023 at 05:25:07PM +0800, Jazzi Hong wrote:
> > > You made the point, thank you Maksim.
> > > I checked /mnt/hdd and nothing there.
> > > > # cat /etc/fstab
> > > 1593ab2ee369c420.b none swap sw
> > > 1593ab2ee369c420.a / ffs rw 1 1
> > > 1593ab2ee369c420.e /var ffs rw,nodev,nosuid 1 2
> > > 2b6c2b5b929f9a55.i /mnt/hdd ffs rw,noexec,nosuid,nodev 0 0
> > > > # doas sysctl hw.disknames
> > > hw.disknames=sd0:2b6c2b5b929f9a55,sd1:1593ab2ee369c420
> > > > # doas fdisk sd0
> > > Disk: sd0 geometry: 121601/255/63 [1953525168 Sectors]
> > > Offset: 0 Signature: 0xAA55
> > > Starting Ending LBA Info:
> > >  #: id  C   H   S -  C   H   S [   start:size ]
> > > ---
> > >  0: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> > >  1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> > >  2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> > > *3: A6  0   1   2 - 121601  80  63 [  64:  1953525104 ] 
> > > OpenBSD
> > > 
> > > So /dev/sd0 is my NFS share hard disk, and when I tried to mount it 
> > > manually:
> > > > # doas mount /mnt/hdd
> > > mount_ffs: 2b6c2b5b929f9a55.i on /mnt/hdd: Invalid argument
> > > +++
> > > The error message mentioned about "Invalid argument" of mount, anything 
> > > wrong?
> > > So the problem now is why can not mount the drive even it's detected?
> >
> > It can detect the drive, but it doesn't find the i partition.  What does
> > disklabel sd0 say?
>
> Or it can find the i partition but mount_ffs does not like it for some reason.
> By convention i partitions are often FAT. But we need the dislabel to
> see what type it has.
>
> -Otto



-- 
jazzi

Best Regard,

Re: NFS mounted but shows nothing even df -h has it

On Wed, May 31, 2023 at 11:21:15AM +0100, Zé Loff wrote:

> On Wed, May 31, 2023 at 05:25:07PM +0800, Jazzi Hong wrote:
> > You made the point, thank you Maksim.
> > I checked /mnt/hdd and nothing there.
> > > # cat /etc/fstab
> > 1593ab2ee369c420.b none swap sw
> > 1593ab2ee369c420.a / ffs rw 1 1
> > 1593ab2ee369c420.e /var ffs rw,nodev,nosuid 1 2
> > 2b6c2b5b929f9a55.i /mnt/hdd ffs rw,noexec,nosuid,nodev 0 0
> > > # doas sysctl hw.disknames
> > hw.disknames=sd0:2b6c2b5b929f9a55,sd1:1593ab2ee369c420
> > > # doas fdisk sd0
> > Disk: sd0 geometry: 121601/255/63 [1953525168 Sectors]
> > Offset: 0 Signature: 0xAA55
> > Starting Ending LBA Info:
> >  #: id  C   H   S -  C   H   S [   start:size ]
> > ---
> >  0: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> >  1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> >  2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> > *3: A6  0   1   2 - 121601  80  63 [  64:  1953525104 ] OpenBSD
> > 
> > So /dev/sd0 is my NFS share hard disk, and when I tried to mount it 
> > manually:
> > > # doas mount /mnt/hdd
> > mount_ffs: 2b6c2b5b929f9a55.i on /mnt/hdd: Invalid argument
> > +++
> > The error message mentioned about "Invalid argument" of mount, anything 
> > wrong?
> > So the problem now is why can not mount the drive even it's detected?
> 
> It can detect the drive, but it doesn't find the i partition.  What does
> disklabel sd0 say?

Or it can find the i partition but mount_ffs does not like it for some reason.
By convention i partitions are often FAT. But we need the dislabel to
see what type it has.

-Otto

Re: NFS mounted but shows nothing even df -h has it

2023-05-31 Thread Zé Loff

On Wed, May 31, 2023 at 05:25:07PM +0800, Jazzi Hong wrote:
> You made the point, thank you Maksim.
> I checked /mnt/hdd and nothing there.
> > # cat /etc/fstab
> 1593ab2ee369c420.b none swap sw
> 1593ab2ee369c420.a / ffs rw 1 1
> 1593ab2ee369c420.e /var ffs rw,nodev,nosuid 1 2
> 2b6c2b5b929f9a55.i /mnt/hdd ffs rw,noexec,nosuid,nodev 0 0
> > # doas sysctl hw.disknames
> hw.disknames=sd0:2b6c2b5b929f9a55,sd1:1593ab2ee369c420
> > # doas fdisk sd0
> Disk: sd0 geometry: 121601/255/63 [1953525168 Sectors]
> Offset: 0 Signature: 0xAA55
> Starting Ending LBA Info:
>  #: id  C   H   S -  C   H   S [   start:size ]
> ---
>  0: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
>  1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
>  2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> *3: A6  0   1   2 - 121601  80  63 [      64:  1953525104 ] OpenBSD
> 
> So /dev/sd0 is my NFS share hard disk, and when I tried to mount it manually:
> > # doas mount /mnt/hdd
> mount_ffs: 2b6c2b5b929f9a55.i on /mnt/hdd: Invalid argument
> +++
> The error message mentioned about "Invalid argument" of mount, anything wrong?
> So the problem now is why can not mount the drive even it's detected?

It can detect the drive, but it doesn't find the i partition.  What does
disklabel sd0 say?


--

Re: NFS mounted but shows nothing even df -h has it

On Wed, May 31, 2023 at 05:25:07PM +0800, Jazzi Hong wrote:

> You made the point, thank you Maksim.
> 
> I checked /mnt/hdd and nothing there.
> 
> > # cat /etc/fstab
> 1593ab2ee369c420.b none swap sw
> 1593ab2ee369c420.a / ffs rw 1 1
> 1593ab2ee369c420.e /var ffs rw,nodev,nosuid 1 2
> 2b6c2b5b929f9a55.i /mnt/hdd ffs rw,noexec,nosuid,nodev 0 0
> 
> > # doas sysctl hw.disknames
> hw.disknames=sd0:2b6c2b5b929f9a55,sd1:1593ab2ee369c420
> 
> > # doas fdisk sd0
> 
> Disk: sd0 geometry: 121601/255/63 [1953525168 Sectors]
> Offset: 0 Signature: 0xAA55
> 
> Starting Ending LBA Info:
> 
>  #: id  C   H   S -  C   H   S [   start:size ]
> 
> ---
> 
>  0: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> 
>  1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> 
>  2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> 
> *3: A6  0   1   2 - 121601  80  63 [  64:  1953525104 ] OpenBSD
> 
> 
> 
> So /dev/sd0 is my NFS share hard disk, and when I tried to mount it manually:
> 
> > # doas mount /mnt/hdd
> mount_ffs: 2b6c2b5b929f9a55.i on /mnt/hdd: Invalid argument
> 
> +++
> The error message mentioned about "Invalid argument" of mount, anything wrong?
> 
> So the problem now is why can not mount the drive even it's detected?

Show thsi disklabel of sd0:

# disklabel sd0

-Otto

> 
> Thank you,
> jazzi
> 
> On Wed, May 31, 2023 at 2:38 PM Maksim Rodin  wrote:
> >
> > The /mnt/hdd partition on your NFS server might just be not mounted
> > which does not prevent nfs service from successfully serving an empty
> > directory.
> > Or one of your two nfs clients might have deleted all your files and you
> > did not notice this.
> >
> > On Wed May 31 09:27:04 2023, Maksim Rodin wrote:
> > > Hello,
> > > Silly question but...
> > > Are you sure that your NFS server still has any files on /mnt/hdd?
> > >
> > > On Wed May 31 09:07:15 2023, Jazzi Hong wrote:
> > > > Hello,
> > > >
> > > > I have OpenBSD 7.2 installed and NFS service running on Cubieboard2,
> > > > one Linux client and one MacOS client, everything works fine for the
> > > > last 6 months.
> > > >
> > > > Yesterday as usual I mounted NFS share and showed mounting
> > > > successfully even command `df -h` got it, but `ls /Users/jazzi/nfs`
> > > > showed nothing. Tried on both Linux and MacOS.
> > > >
> > > > OpenBSD is 24*7 running and I didn't do anything to change the system,
> > > > maybe it's too hot so I shut it down for the whole night and power on
> > > > the next day but it didn't work.
> > > >
> > > > +++
> > > > Here is how I mount it on MacOS:
> > > >
> > > > > sudo mount -t nfs -o 
> > > > > resvport,async,nolocks,locallocks,soft,wsize=32768,rsize=32768 
> > > > > 192.168.31.231:/mnt/hdd /Users/jazzi/nfs
> > > >
> > > > +++
> > > > Here is the settings on OpenBSD NFS server:
> > > >
> > > > # $ cat /etc/exports
> > > >
> > > > # For Macbook Air
> > > > /mnt/hdd -alldirs -mapall=root 192.168.31.76
> > > >
> > > > # For Linux desktop
> > > > /mnt/hdd -alldirs -mapall=root 192.168.31.77
> > > >
> > > > 
> > > >
> > > > Any help will be appreciated, thank you.
> > > >
> > > >
> > > >
> > > > --
> > > > jazzi
> > > >
> > > > Best Regard,
> > > >
> > >
> > > --
> > > С уважением,
> > > Родин Максим
> >
> > --
> > С уважением,
> > Родин Максим
> 
> 
> 
> -- 
> jazzi
> 
> Best Regard,
>

Re: NFS mounted but shows nothing even df -h has it

2023-05-31 Thread Jon Fineman

What do you get if you run the below commands? OpenBSD defaults to
using UDP for NFS. Linux I believe defaults to using TCP. I would have
expected a more explicit Portmap error though if it was that.

showmount -e hostname

rpcinfo -t hostname mountd
rpcinfo -u hostname mountd
rpcinfo -t hostname nfs
rpcinfo -u hostname nfs


Jazzi Hong  writes:

> You made the point, thank you Maksim.
>
> I checked /mnt/hdd and nothing there.
>
>> # cat /etc/fstab
> 1593ab2ee369c420.b none swap sw
> 1593ab2ee369c420.a / ffs rw 1 1
> 1593ab2ee369c420.e /var ffs rw,nodev,nosuid 1 2
> 2b6c2b5b929f9a55.i /mnt/hdd ffs rw,noexec,nosuid,nodev 0 0
>
>> # doas sysctl hw.disknames
> hw.disknames=sd0:2b6c2b5b929f9a55,sd1:1593ab2ee369c420
>
>> # doas fdisk sd0
>
> Disk: sd0 geometry: 121601/255/63 [1953525168 Sectors]
> Offset: 0 Signature: 0xAA55
>
> Starting Ending LBA Info:
>
>  #: id  C   H   S -  C   H   S [   start:size ]
>
> ---
>
>  0: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
>
>  1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
>
>  2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
>
> *3: A6  0   1   2 - 121601  80  63 [  64:  1953525104 ] OpenBSD
>
>
> 
> So /dev/sd0 is my NFS share hard disk, and when I tried to mount it manually:
>
>> # doas mount /mnt/hdd
> mount_ffs: 2b6c2b5b929f9a55.i on /mnt/hdd: Invalid argument
>
> +++
> The error message mentioned about "Invalid argument" of mount, anything wrong?
>
> So the problem now is why can not mount the drive even it's detected?
>
> Thank you,
> jazzi
>
> On Wed, May 31, 2023 at 2:38 PM Maksim Rodin  wrote:
>>
>> The /mnt/hdd partition on your NFS server might just be not mounted
>> which does not prevent nfs service from successfully serving an empty
>> directory.
>> Or one of your two nfs clients might have deleted all your files and you
>> did not notice this.
>>
>> On Wed May 31 09:27:04 2023, Maksim Rodin wrote:
>> > Hello,
>> > Silly question but...
>> > Are you sure that your NFS server still has any files on /mnt/hdd?
>> >
>> > On Wed May 31 09:07:15 2023, Jazzi Hong wrote:
>> > > Hello,
>> > >
>> > > I have OpenBSD 7.2 installed and NFS service running on Cubieboard2,
>> > > one Linux client and one MacOS client, everything works fine for the
>> > > last 6 months.
>> > >
>> > > Yesterday as usual I mounted NFS share and showed mounting
>> > > successfully even command `df -h` got it, but `ls /Users/jazzi/nfs`
>> > > showed nothing. Tried on both Linux and MacOS.
>> > >
>> > > OpenBSD is 24*7 running and I didn't do anything to change the system,
>> > > maybe it's too hot so I shut it down for the whole night and power on
>> > > the next day but it didn't work.
>> > >
>> > > +++
>> > > Here is how I mount it on MacOS:
>> > >
>> > > > sudo mount -t nfs -o 
>> > > > resvport,async,nolocks,locallocks,soft,wsize=32768,rsize=32768 
>> > > > 192.168.31.231:/mnt/hdd /Users/jazzi/nfs
>> > >
>> > > +++
>> > > Here is the settings on OpenBSD NFS server:
>> > >
>> > > # $ cat /etc/exports
>> > >
>> > > # For Macbook Air
>> > > /mnt/hdd -alldirs -mapall=root 192.168.31.76
>> > >
>> > > # For Linux desktop
>> > > /mnt/hdd -alldirs -mapall=root 192.168.31.77
>> > >
>> > > 
>> > >
>> > > Any help will be appreciated, thank you.
>> > >
>> > >
>> > >
>> > > --
>> > > jazzi
>> > >
>> > > Best Regard,
>> > >
>> >
>> > --
>> > С уважением,
>> > Родин Максим
>>
>> --
>> С уважением,
>> Родин Максим
>
>
>
> -- 
> jazzi
>
> Best Regard,

Re: NFS mounted but shows nothing even df -h has it

2023-05-31 Thread Jazzi Hong

You made the point, thank you Maksim.

I checked /mnt/hdd and nothing there.

> # cat /etc/fstab
1593ab2ee369c420.b none swap sw
1593ab2ee369c420.a / ffs rw 1 1
1593ab2ee369c420.e /var ffs rw,nodev,nosuid 1 2
2b6c2b5b929f9a55.i /mnt/hdd ffs rw,noexec,nosuid,nodev 0 0

> # doas sysctl hw.disknames
hw.disknames=sd0:2b6c2b5b929f9a55,sd1:1593ab2ee369c420

> # doas fdisk sd0

Disk: sd0 geometry: 121601/255/63 [1953525168 Sectors]
Offset: 0 Signature: 0xAA55

Starting Ending LBA Info:

 #: id  C   H   S -  C   H   S [   start:size ]

---

 0: 00  0   0   0 -  0   0   0 [   0:   0 ] unused

 1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused

 2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused

*3: A6  0   1   2 - 121601  80  63 [  64:  1953525104 ] OpenBSD



So /dev/sd0 is my NFS share hard disk, and when I tried to mount it manually:

> # doas mount /mnt/hdd
mount_ffs: 2b6c2b5b929f9a55.i on /mnt/hdd: Invalid argument

+++
The error message mentioned about "Invalid argument" of mount, anything wrong?

So the problem now is why can not mount the drive even it's detected?

Thank you,
jazzi

On Wed, May 31, 2023 at 2:38 PM Maksim Rodin  wrote:
>
> The /mnt/hdd partition on your NFS server might just be not mounted
> which does not prevent nfs service from successfully serving an empty
> directory.
> Or one of your two nfs clients might have deleted all your files and you
> did not notice this.
>
> On Wed May 31 09:27:04 2023, Maksim Rodin wrote:
> > Hello,
> > Silly question but...
> > Are you sure that your NFS server still has any files on /mnt/hdd?
> >
> > On Wed May 31 09:07:15 2023, Jazzi Hong wrote:
> > > Hello,
> > >
> > > I have OpenBSD 7.2 installed and NFS service running on Cubieboard2,
> > > one Linux client and one MacOS client, everything works fine for the
> > > last 6 months.
> > >
> > > Yesterday as usual I mounted NFS share and showed mounting
> > > successfully even command `df -h` got it, but `ls /Users/jazzi/nfs`
> > > showed nothing. Tried on both Linux and MacOS.
> > >
> > > OpenBSD is 24*7 running and I didn't do anything to change the system,
> > > maybe it's too hot so I shut it down for the whole night and power on
> > > the next day but it didn't work.
> > >
> > > +++++++
> > > Here is how I mount it on MacOS:
> > >
> > > > sudo mount -t nfs -o 
> > > > resvport,async,nolocks,locallocks,soft,wsize=32768,rsize=32768 
> > > > 192.168.31.231:/mnt/hdd /Users/jazzi/nfs
> > >
> > > +++
> > > Here is the settings on OpenBSD NFS server:
> > >
> > > # $ cat /etc/exports
> > >
> > > # For Macbook Air
> > > /mnt/hdd -alldirs -mapall=root 192.168.31.76
> > >
> > > # For Linux desktop
> > > /mnt/hdd -alldirs -mapall=root 192.168.31.77
> > >
> > > 
> > >
> > > Any help will be appreciated, thank you.
> > >
> > >
> > >
> > > --
> > > jazzi
> > >
> > > Best Regard,
> > >
> >
> > --
> > С уважением,
> > Родин Максим
>
> --
> С уважением,
> Родин Максим



-- 
jazzi

Best Regard,

Re: NFS mounted but shows nothing even df -h has it

2023-05-31 Thread Maksim Rodin

The /mnt/hdd partition on your NFS server might just be not mounted
which does not prevent nfs service from successfully serving an empty
directory.
Or one of your two nfs clients might have deleted all your files and you
did not notice this.

On Wed May 31 09:27:04 2023, Maksim Rodin wrote:
> Hello,
> Silly question but...
> Are you sure that your NFS server still has any files on /mnt/hdd?
> 
> On Wed May 31 09:07:15 2023, Jazzi Hong wrote:
> > Hello,
> > 
> > I have OpenBSD 7.2 installed and NFS service running on Cubieboard2,
> > one Linux client and one MacOS client, everything works fine for the
> > last 6 months.
> > 
> > Yesterday as usual I mounted NFS share and showed mounting
> > successfully even command `df -h` got it, but `ls /Users/jazzi/nfs`
> > showed nothing. Tried on both Linux and MacOS.
> > 
> > OpenBSD is 24*7 running and I didn't do anything to change the system,
> > maybe it's too hot so I shut it down for the whole night and power on
> > the next day but it didn't work.
> > 
> > +++
> > Here is how I mount it on MacOS:
> > 
> > > sudo mount -t nfs -o 
> > > resvport,async,nolocks,locallocks,soft,wsize=32768,rsize=32768 
> > > 192.168.31.231:/mnt/hdd /Users/jazzi/nfs
> > 
> > +++
> > Here is the settings on OpenBSD NFS server:
> > 
> > # $ cat /etc/exports
> > 
> > # For Macbook Air
> > /mnt/hdd -alldirs -mapall=root 192.168.31.76
> > 
> > # For Linux desktop
> > /mnt/hdd -alldirs -mapall=root 192.168.31.77
> > 
> > 
> > 
> > Any help will be appreciated, thank you.
> > 
> > 
> > 
> > -- 
> > jazzi
> > 
> > Best Regard,
> > 
> 
> -- 
> С уважением,
> Родин Максим

-- 
С уважением,
Родин Максим

Re: NFS mounted but shows nothing even df -h has it

2023-05-31 Thread Maksim Rodin

Hello,
Silly question but...
Are you sure that your NFS server still has any files on /mnt/hdd?

On Wed May 31 09:07:15 2023, Jazzi Hong wrote:
> Hello,
> 
> I have OpenBSD 7.2 installed and NFS service running on Cubieboard2,
> one Linux client and one MacOS client, everything works fine for the
> last 6 months.
> 
> Yesterday as usual I mounted NFS share and showed mounting
> successfully even command `df -h` got it, but `ls /Users/jazzi/nfs`
> showed nothing. Tried on both Linux and MacOS.
> 
> OpenBSD is 24*7 running and I didn't do anything to change the system,
> maybe it's too hot so I shut it down for the whole night and power on
> the next day but it didn't work.
> 
> +++
> Here is how I mount it on MacOS:
> 
> > sudo mount -t nfs -o 
> > resvport,async,nolocks,locallocks,soft,wsize=32768,rsize=32768 
> > 192.168.31.231:/mnt/hdd /Users/jazzi/nfs
> 
> +++
> Here is the settings on OpenBSD NFS server:
> 
> # $ cat /etc/exports
> 
> # For Macbook Air
> /mnt/hdd -alldirs -mapall=root 192.168.31.76
> 
> # For Linux desktop
> /mnt/hdd -alldirs -mapall=root 192.168.31.77
> 
> 
> 
> Any help will be appreciated, thank you.
> 
> 
> 
> -- 
> jazzi
> 
> Best Regard,
> 

-- 
С уважением,
Родин Максим

NFS mounted but shows nothing even df -h has it

2023-05-30 Thread Jazzi Hong

Hello,

I have OpenBSD 7.2 installed and NFS service running on Cubieboard2,
one Linux client and one MacOS client, everything works fine for the
last 6 months.

Yesterday as usual I mounted NFS share and showed mounting
successfully even command `df -h` got it, but `ls /Users/jazzi/nfs`
showed nothing. Tried on both Linux and MacOS.

OpenBSD is 24*7 running and I didn't do anything to change the system,
maybe it's too hot so I shut it down for the whole night and power on
the next day but it didn't work.

+++
Here is how I mount it on MacOS:

> sudo mount -t nfs -o 
> resvport,async,nolocks,locallocks,soft,wsize=32768,rsize=32768 
> 192.168.31.231:/mnt/hdd /Users/jazzi/nfs

+++
Here is the settings on OpenBSD NFS server:

# $ cat /etc/exports

# For Macbook Air
/mnt/hdd -alldirs -mapall=root 192.168.31.76

# For Linux desktop
/mnt/hdd -alldirs -mapall=root 192.168.31.77



Any help will be appreciated, thank you.



-- 
jazzi

Best Regard,

NFS hangs with FIN_WAIT_2

2023-03-05 Thread Erwan Hingant

Dear community,

I have a problem with my openbsd nfsd server. My client (ubuntu) after a while,
sent a packet with flag F which to do not receive a correct response to close
the connection or something like that because it get stuck with FIN_WAIT_2
states. Here is the packet sent by client to server :

12:16:45.022393 192.168.100.2.998 > 192.168.100.1.2049: F 141:141(0) ack 117 win
1284  (DF)

Then the traffic consists in these lines (indefinitely):

12:16:45.022470 192.168.100.1.2049 > 192.168.100.2.998: . ack 142 win 1030
 12:17:45.187125 192.168.100.2.998 >

192.168.100.1.2049: . ack 117 win 1284 
(DF) 12:17:45.187153 192.168.100.1.2049 > 192.168.100.2.998: . ack 142 win 1030
 12:18:45.849519 192.168.100.2.998 >

192.168.100.1.2049: . ack 117 win 1284 
(DF) 12:18:45.849548 192.168.100.1.2049 > 192.168.100.2.998: . ack 142 win 1030
 12:19:47.294335 192.168.100.2.998 >

192.168.100.1.2049: . ack 117 win 1284 
(DF) 12:19:47.294359 192.168.100.1.2049 > 192.168.100.2.998: . ack 142 win 1030


...

Inspecting the states of the connection I have, on the client :

client$ netstat -an | grep 2049
tcp0  0 192.168.100.2:998   192.168.100.1:2049  FIN_WAIT2 

and on the server

server$ doas pfctl -s states | grep 2049 
all tcp 192.168.100.1:2049 <- 192.168.100.2:998   ESTABLISHED:FIN_WAIT_2

Somebody has an hint to solve this problem ?

Thanks for your help.
Airwan.

Re: permission denied when writing to mounted directory exported by NFS server

2023-02-10 Thread Otto Moerbeek

On Fri, Feb 10, 2023 at 09:10:55AM +0100, carsten.re...@t-online.de wrote:

> On Fri, Feb 10, 2023 at 12:58:21PM +0530, Sandeep Gupta wrote:
> > On test setup I got this fixed. I will try to see if it works on actual
> > system.
> > 
> > I made following changes:
> > - modified /etc/exports entry
> > `
> > /nfs/testdir -alldirs  -maproot=root:wheel -network=192.168.0
> > -mask=255.255.255.0
> 
> This sounds like the typical "fix your access rights" problem
> 
> > `
> > The not-working version used "-maproot=root".
> > 
> 
> probably your "not-working" user wasn't root ? but is a member of the group 
> wheel ?

I asked that already. As NFS in general to seems work (at least for
r/o access), this is almost 100% a permission issue. But other went of
to chase geese.

So again, run in the dir:

ls -ld
id

And show the output.

-Otto

> 
> > - started nfsd from command line
> > `
> > doas /sbin/nfsd -tun 4
> > `
> > For some reason starting using rcctl fails as can be seen below:
> > ```
> > You have new mail.
> > openbsd$ doas rcctl start portmap mountd nfsd
> > nfsd(failed)
> 
> nfsd(failed) is bad ...
> 
> > openbsd$ doas /sbin/nfsd -tun 4
> > openbsd$ ps aux | grep nfsd
> > root 21178  0.0  0.1   480  1132 ??  S  12:51PM0:00.01 nfsd:
> > master
> > root 95864  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
> > server
> > root 29237  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
> > server
> > root 37092  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
> > server
> > root 40371  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
> > server
> > adming   20594  0.0  0.1   524  1264 00  S+p12:51PM0:00.02 grep nfsd
> > ```
> > 
> > For debugs, here is output of rpcinfo:
> > [adming@cluster-node2]~% rpcinfo -p 192.168.0.122
> >program vers proto   port  service
> > 102   tcp111  portmapper
> > 10    2   udp111  portmapper
> >     151   udp859  mountd
> > 153   udp859  mountd
> > 151   tcp806  mountd
> > 1000053   tcp806  mountd
> > 132   udp   2049  nfs
> > 133   udp   2049  nfs
> > 132   tcp   2049  nfs
> > 133   tcp   2049  nfs
> > 
> > Since, on both client and server, the root is writing -- the uid and gid is
> > 0.
> 
> Never do this ... I don't remember exactly, but NFS might not like it ...
> 
> Never play with root
> 
> 
> > 
> > On Fri, Feb 10, 2023 at 5:13 AM  wrote:
> > 
> > > On Thu, Feb 09, 2023 at 08:40:50AM +0100, Daniele B. wrote:
> > > > Unfortunately - personal experience - NFS is not the best offering from
> > > OpenBSD: it is enough
> > > > combersome to setup and easy to lose grip: something unsafe to keep me
> > > away from it.
> > > >
> > >
> > >
> > > What exactly do you mean ?
> > >
> > > rcctl enable portmap mountd nfsd
> > >
> > > what is so cumbersome with that ?
> > >
> > > What can we do better ?
> > >
> > >
> > > > However, for your testing purposes, I can suggest you there is a
> > > specific tool to test, server and client
> > > > status. looking to the man I guess it should be nfsstat pointed to one
> > > or the other host same time.
> > > > Probably some other people could be more detailed.
> > > >
> > > > -- Daniele Bonini
> > > >
> > > > Feb 8, 2023 17:00:09 Sandeep Gupta :
> > > >
> > > > > Looking at the docs I am not able
> > > > > to find any otherconfig options for access control on the client side.
> > > > > There is nothing in the logs on the server side as well. Any pointers
> > > to
> > > > > debug/fix would be of great help.
> > > >
> > >
> > >
>

Re: permission denied when writing to mounted directory exported by NFS server

2023-02-10 Thread carsten . reith

On Fri, Feb 10, 2023 at 12:58:21PM +0530, Sandeep Gupta wrote:
> On test setup I got this fixed. I will try to see if it works on actual
> system.
> 
> I made following changes:
> - modified /etc/exports entry
> `
> /nfs/testdir -alldirs  -maproot=root:wheel -network=192.168.0
> -mask=255.255.255.0

This sounds like the typical "fix your access rights" problem

> `
> The not-working version used "-maproot=root".
> 

probably your "not-working" user wasn't root ? but is a member of the group 
wheel ?

> - started nfsd from command line
> `
> doas /sbin/nfsd -tun 4
> `
> For some reason starting using rcctl fails as can be seen below:
> ```
> You have new mail.
> openbsd$ doas rcctl start portmap mountd nfsd
> nfsd(failed)

nfsd(failed) is bad ...

> openbsd$ doas /sbin/nfsd -tun 4
> openbsd$ ps aux | grep nfsd
> root 21178  0.0  0.1   480  1132 ??  S  12:51PM0:00.01 nfsd:
> master
> root 95864  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
> server
> root 29237  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
> server
> root 37092  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
> server
> root 40371  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
> server
> adming   20594  0.0  0.1   524  1264 00  S+p12:51PM0:00.02 grep nfsd
> ```
> 
> For debugs, here is output of rpcinfo:
> [adming@cluster-node2]~% rpcinfo -p 192.168.0.122
>program vers proto   port  service
> 102   tcp111  portmapper
> 102   udp111  portmapper
> 151   udp859  mountd
> 153   udp859  mountd
> 151   tcp    806  mountd
> 153   tcp806  mountd
> 132   udp   2049  nfs
> 133   udp   2049  nfs
> 132   tcp   2049  nfs
> 133   tcp   2049  nfs
> 
> Since, on both client and server, the root is writing -- the uid and gid is
> 0.

Never do this ... I don't remember exactly, but NFS might not like it ...

Never play with root


> 
> On Fri, Feb 10, 2023 at 5:13 AM  wrote:
> 
> > On Thu, Feb 09, 2023 at 08:40:50AM +0100, Daniele B. wrote:
> > > Unfortunately - personal experience - NFS is not the best offering from
> > OpenBSD: it is enough
> > > combersome to setup and easy to lose grip: something unsafe to keep me
> > away from it.
> > >
> >
> >
> > What exactly do you mean ?
> >
> > rcctl enable portmap mountd nfsd
> >
> > what is so cumbersome with that ?
> >
> > What can we do better ?
> >
> >
> > > However, for your testing purposes, I can suggest you there is a
> > specific tool to test, server and client
> > > status. looking to the man I guess it should be nfsstat pointed to one
> > or the other host same time.
> > > Probably some other people could be more detailed.
> > >
> > > -- Daniele Bonini
> > >
> > > Feb 8, 2023 17:00:09 Sandeep Gupta :
> > >
> > > > Looking at the docs I am not able
> > > > to find any otherconfig options for access control on the client side.
> > > > There is nothing in the logs on the server side as well. Any pointers
> > to
> > > > debug/fix would be of great help.
> > >
> >
> >

Re: permission denied when writing to mounted directory exported by NFS server

2023-02-09 Thread Sandeep Gupta

On test setup I got this fixed. I will try to see if it works on actual
system.

I made following changes:
- modified /etc/exports entry
`
/nfs/testdir -alldirs  -maproot=root:wheel -network=192.168.0
-mask=255.255.255.0
`
The not-working version used "-maproot=root".

- started nfsd from command line
`
doas /sbin/nfsd -tun 4
`
For some reason starting using rcctl fails as can be seen below:
```
You have new mail.
openbsd$ doas rcctl start portmap mountd nfsd
nfsd(failed)
openbsd$ doas /sbin/nfsd -tun 4
openbsd$ ps aux | grep nfsd
root 21178  0.0  0.1   480  1132 ??  S  12:51PM0:00.01 nfsd:
master
root 95864  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
server
root 29237  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
server
root 37092  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
server
root 40371  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
server
adming   20594  0.0  0.1   524  1264 00  S+p12:51PM0:00.02 grep nfsd
```

For debugs, here is output of rpcinfo:
[adming@cluster-node2]~% rpcinfo -p 192.168.0.122
   program vers proto   port  service
102   tcp111  portmapper
102   udp111  portmapper
151   udp859  mountd
153   udp859  mountd
151   tcp806  mountd
153   tcp806  mountd
132   udp   2049  nfs
133   udp   2049  nfs
132   tcp   2049  nfs
133   tcp   2049  nfs

Since, on both client and server, the root is writing -- the uid and gid is
0.

On Fri, Feb 10, 2023 at 5:13 AM  wrote:

> On Thu, Feb 09, 2023 at 08:40:50AM +0100, Daniele B. wrote:
> > Unfortunately - personal experience - NFS is not the best offering from
> OpenBSD: it is enough
> > combersome to setup and easy to lose grip: something unsafe to keep me
> away from it.
> >
>
>
> What exactly do you mean ?
>
> rcctl enable portmap mountd nfsd
>
> what is so cumbersome with that ?
>
> What can we do better ?
>
>
> > However, for your testing purposes, I can suggest you there is a
> specific tool to test, server and client
> > status. looking to the man I guess it should be nfsstat pointed to one
> or the other host same time.
> > Probably some other people could be more detailed.
> >
> > -- Daniele Bonini
> >
> > Feb 8, 2023 17:00:09 Sandeep Gupta :
> >
> > > Looking at the docs I am not able
> > > to find any otherconfig options for access control on the client side.
> > > There is nothing in the logs on the server side as well. Any pointers
> to
> > > debug/fix would be of great help.
> >
>
>

Re: permission denied when writing to mounted directory exported by NFS server

On Thu, Feb 09, 2023 at 08:40:50AM +0100, Daniele B. wrote:
> Unfortunately - personal experience - NFS is not the best offering from 
> OpenBSD: it is enough
> combersome to setup and easy to lose grip: something unsafe to keep me away 
> from it.
>


What exactly do you mean ?

rcctl enable portmap mountd nfsd 

what is so cumbersome with that ?

What can we do better ? 

 
> However, for your testing purposes, I can suggest you there is a specific 
> tool to test, server and client
> status. looking to the man I guess it should be nfsstat pointed to one or the 
> other host same time.
> Probably some other people could be more detailed.
> 
> -- Daniele Bonini
> 
> Feb 8, 2023 17:00:09 Sandeep Gupta :
> 
> > Looking at the docs I am not able
> > to find any otherconfig options for access control on the client side.
> > There is nothing in the logs on the server side as well. Any pointers to
> > debug/fix would be of great help.
>

Re: permission denied when writing to mounted directory exported by NFS server

On Thu, Feb 09, 2023 at 08:40:50AM +0100, Daniele B. wrote:
> Unfortunately - personal experience - NFS is not the best offering from 
> OpenBSD: it is enough
> combersome to setup and easy to lose grip: something unsafe to keep me away 
> from it.
>

What is cumbersome ?

$ rcctl enable portmap mountd nfsd

Create a directory
Create a /etc/exports

rcctl start portmap mountd nfsd 

Here we go ...

What can we do better ?

 
> However, for your testing purposes, I can suggest you there is a specific 
> tool to test, server and client
> status. looking to the man I guess it should be nfsstat pointed to one or the 
> other host same time.
> Probably some other people could be more detailed.
> 
> -- Daniele Bonini
> 
> Feb 8, 2023 17:00:09 Sandeep Gupta :
> 
> > Looking at the docs I am not able
> > to find any otherconfig options for access control on the client side.
> > There is nothing in the logs on the server side as well. Any pointers to
> > debug/fix would be of great help.
>

Re: permission denied when writing to mounted directory exported by NFS server

On Wed, Feb 08, 2023 at 09:27:34PM +0530, Sandeep Gupta wrote:
> I have a default installation of openbsd, with portmap, mountd, nfsd
> services started via rcctl. I have following entry in /etc/exports
> 
> /nfs/testdir -alldirs  -maproot=root -network=192.168.0 -mask=255.255.255.0
> 
> I am able to mount the exported share on client (centos) as follows:
> 
> sudo mount -t nfs -o rw,noauto -v 192.168.0.122:/nfs/testdir mntpt3
> 
> From the client, I can read the contents. But writing inside the mounted
> directory yields permission denied error. Looking at the docs I am not able
> to find any otherconfig options for access control on the client side.
> There is nothing in the logs on the server side as well. Any pointers to
> debug/fix would be of great help.

Can you check the uid and gid of the user on the client and the server ?

The user needs to have the same uid on both systems as NFS works with the 
numerical IDs (uid/gid.)

This won't work:

Server: 
bambi$ doas useradd -m -u 1 -g 1 test
bambi$ doas mkdir /exports/test3

bambi$ doas chown test:test /exports/test3  


Client:
creith@molloy:~$ sudo useradd -m -u 10001 -g 10001 test
creith@molloy:~$ sudo su - test
test@molloy:~$ touch /mnt/test3/hallo
touch: '/mnt/test3/hallo' kann nicht ber??hrt werden: Keine Berechtigung

Sorry for the German, it means: Permission denied.

:wq
Carsten

Re: permission denied when writing to mounted directory exported by NFS server

On Thu, Feb 09, 2023 at 11:41:12AM +0530, Sandeep Gupta wrote:
> Following up on this. I looked into the /var/log/messages/ and
> /var/log/daemon. Both are quite after starting the portmap, mountd, and
> nfsd services.
> 
> Here is verbose output from the client side when mounting the share:
> ```
> [adming@cluster-node2]~% sudo mount -t nfs -o rw,noauto -v
> 192.168.0.122:/nfs/testdir
>  /home/adming/mntpt2
> mount.nfs: timeout set for Thu Feb  9 11:34:52 2023
> 
> mount.nfs: trying text-based options
> 'vers=4.2,addr=192.168.0.122,clientaddr=192.168.0.187'
> mount.nfs: mount(2): Protocol not supported
> mount.nfs: trying text-based options
> 'vers=4,minorversion=1,addr=192.168.0.122,clientaddr=192.168.0.187'
> mount.nfs: mount(2): Protocol not supported
> mount.nfs: trying text-based options
> 'vers=4,addr=192.168.0.122,clientaddr=192.168.0.187'
> mount.nfs: mount(2): Protocol not supported
> Created symlink
> /run/systemd/system/remote-fs.target.wants/rpc-statd.service ?
> /usr/lib/systemd/system/rpc-statd.service.
> mount.nfs: trying text-based options 'addr=192.168.0.122'
> mount.nfs: prog 13, trying vers=3, prot=6
> mount.nfs: trying 192.168.0.122 prog 13 vers 3 prot TCP port 2049
> mount.nfs: prog 15, trying vers=3, prot=17
> mount.nfs: trying 192.168.0.122 prog 15 vers 3 prot UDP port 724
> [adming@cluster-node2]~% cd mntpt2
> [adming@cluster-node2]~/mntpt2% ls
> alfpha  testfile
> [adming@cluster-node2]~/mntpt2% touch y
> touch: cannot touch 'y': Permission denied
> ```
> 
> Am out of ideas as what to test/debug.
>

can you try the following command on the client ?

rpcinfo -p 

The output should look something like this:

   program vers proto   port  service
102   tcp111  portmapper
102   udp111  portmapper
151   udp702  mountd
153   udp702  mountd
151   tcp   1017  mountd
153   tcp   1017  mountd
132   udp   2049  nfs
133   udp   2049  nfs
132   tcp   2049  nfs
133   tcp   2049  nfs


:wq
Carsten

Re: permission denied when writing to mounted directory exported by NFS server

On Thu, Feb 09, 2023 at 11:41:55AM +0530, Sandeep Gupta wrote:
> Not a problem. I am glad  that you looked into it.
> 
> On Thu, Feb 9, 2023 at 7:48 AM  wrote:
> 
> > sorry, for having you replied directly. I set up this system today, I
> > still have some twerks.
> >

Can you check the uid and gid of the user on the client and the server ?
 
The uid and/or gid must be the same on both systems as NFS works with the 
numerical IDs (uid/gid.)
 
This won't work:
 
Server:

bambi$ doas useradd -m -u 1 -g 1 test
bambi$ doas mkdir /exports/test3
bambi$ doas chown test:test /exports/test3

Client:
creith@molloy:~$ sudo useradd -m -u 10001 -g 10001 test
creith@molloy:~$ sudo su - test
test@molloy:~$ touch /mnt/test3/hallo
touch: '/mnt/test3/hallo' kann nicht ber??hrt werden: Keine Berechtigung

Sorry for the German, it means: Permission denied.

:wq
Carsten

Re: permission denied when writing to mounted directory exported by NFS server

2023-02-08 Thread Otto Moerbeek

On Thu, Feb 09, 2023 at 11:41:12AM +0530, Sandeep Gupta wrote:

> Following up on this. I looked into the /var/log/messages/ and
> /var/log/daemon. Both are quite after starting the portmap, mountd, and
> nfsd services.
> 
> Here is verbose output from the client side when mounting the share:
> ```
> [adming@cluster-node2]~% sudo mount -t nfs -o rw,noauto -v
> 192.168.0.122:/nfs/testdir
>  /home/adming/mntpt2
> mount.nfs: timeout set for Thu Feb  9 11:34:52 2023
> 
> mount.nfs: trying text-based options
> 'vers=4.2,addr=192.168.0.122,clientaddr=192.168.0.187'
> mount.nfs: mount(2): Protocol not supported
> mount.nfs: trying text-based options
> 'vers=4,minorversion=1,addr=192.168.0.122,clientaddr=192.168.0.187'
> mount.nfs: mount(2): Protocol not supported
> mount.nfs: trying text-based options
> 'vers=4,addr=192.168.0.122,clientaddr=192.168.0.187'
> mount.nfs: mount(2): Protocol not supported
> Created symlink
> /run/systemd/system/remote-fs.target.wants/rpc-statd.service →
> /usr/lib/systemd/system/rpc-statd.service.
> mount.nfs: trying text-based options 'addr=192.168.0.122'
> mount.nfs: prog 13, trying vers=3, prot=6
> mount.nfs: trying 192.168.0.122 prog 13 vers 3 prot TCP port 2049
> mount.nfs: prog 15, trying vers=3, prot=17
> mount.nfs: trying 192.168.0.122 prog 15 vers 3 prot UDP port 724
> [adming@cluster-node2]~% cd mntpt2
> [adming@cluster-node2]~/mntpt2% ls
> alfpha  testfile
> [adming@cluster-node2]~/mntpt2% touch y
> touch: cannot touch 'y': Permission denied
> ```
> 
> Am out of ideas as what to test/debug.

run the commands
$ ls -ld 
$ id

to see what the permissions are on te dir and what user you are running as.

-Otto

> 
> 
> 
> On Wed, Feb 8, 2023 at 9:27 PM Sandeep Gupta 
> wrote:
> 
> > I have a default installation of openbsd, with portmap, mountd, nfsd
> > services started via rcctl. I have following entry in /etc/exports
> >
> > /nfs/testdir -alldirs  -maproot=root -network=192.168.0 -mask=255.255.255.0
> >
> > I am able to mount the exported share on client (centos) as follows:
> >
> > sudo mount -t nfs -o rw,noauto -v 192.168.0.122:/nfs/testdir mntpt3
> >
> > From the client, I can read the contents. But writing inside the mounted
> > directory yields permission denied error. Looking at the docs I am not able
> > to find any otherconfig options for access control on the client side.
> > There is nothing in the logs on the server side as well. Any pointers to
> > debug/fix would be of great help.
> >

permission denied when writing to mounted directory exported by NFS server

2023-02-08 Thread Daniele B.

Unfortunately - personal experience - NFS is not the best offering from 
OpenBSD: it is enough
combersome to setup and easy to lose grip: something unsafe to keep me away 
from it.

However, for your testing purposes, I can suggest you there is a specific tool 
to test, server and client
status. looking to the man I guess it should be nfsstat pointed to one or the 
other host same time.
Probably some other people could be more detailed.

-- Daniele Bonini

Feb 8, 2023 17:00:09 Sandeep Gupta :

> Looking at the docs I am not able
> to find any otherconfig options for access control on the client side.
> There is nothing in the logs on the server side as well. Any pointers to
> debug/fix would be of great help.

Re: permission denied when writing to mounted directory exported by NFS server

2023-02-08 Thread Sandeep Gupta

Following up on this. I looked into the /var/log/messages/ and
/var/log/daemon. Both are quite after starting the portmap, mountd, and
nfsd services.

Here is verbose output from the client side when mounting the share:
```
[adming@cluster-node2]~% sudo mount -t nfs -o rw,noauto -v
192.168.0.122:/nfs/testdir
 /home/adming/mntpt2
mount.nfs: timeout set for Thu Feb  9 11:34:52 2023

mount.nfs: trying text-based options
'vers=4.2,addr=192.168.0.122,clientaddr=192.168.0.187'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options
'vers=4,minorversion=1,addr=192.168.0.122,clientaddr=192.168.0.187'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options
'vers=4,addr=192.168.0.122,clientaddr=192.168.0.187'
mount.nfs: mount(2): Protocol not supported
Created symlink
/run/systemd/system/remote-fs.target.wants/rpc-statd.service →
/usr/lib/systemd/system/rpc-statd.service.
mount.nfs: trying text-based options 'addr=192.168.0.122'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: trying 192.168.0.122 prog 13 vers 3 prot TCP port 2049
mount.nfs: prog 15, trying vers=3, prot=17
mount.nfs: trying 192.168.0.122 prog 15 vers 3 prot UDP port 724
[adming@cluster-node2]~% cd mntpt2
[adming@cluster-node2]~/mntpt2% ls
alfpha  testfile
[adming@cluster-node2]~/mntpt2% touch y
touch: cannot touch 'y': Permission denied
```

Am out of ideas as what to test/debug.

On Wed, Feb 8, 2023 at 9:27 PM Sandeep Gupta 
wrote:

> I have a default installation of openbsd, with portmap, mountd, nfsd
> services started via rcctl. I have following entry in /etc/exports
>
> /nfs/testdir -alldirs  -maproot=root -network=192.168.0 -mask=255.255.255.0
>
> I am able to mount the exported share on client (centos) as follows:
>
> sudo mount -t nfs -o rw,noauto -v 192.168.0.122:/nfs/testdir mntpt3
>
> From the client, I can read the contents. But writing inside the mounted
> directory yields permission denied error. Looking at the docs I am not able
> to find any otherconfig options for access control on the client side.
> There is nothing in the logs on the server side as well. Any pointers to
> debug/fix would be of great help.
>

Re: permission denied when writing to mounted directory exported by NFS server

2023-02-08 Thread carsten . reith

On Wed, Feb 08, 2023 at 10:30:17PM +0100, cre...@macbeth.creith.de wrote:
> On Wed, Feb 08, 2023 at 09:27:34PM +0530, Sandeep Gupta wrote:
> > I have a default installation of openbsd, with portmap, mountd, nfsd
> > services started via rcctl. I have following entry in /etc/exports
> > 
> > /nfs/testdir -alldirs  -maproot=root -network=192.168.0 -mask=255.255.255.0
> > 
> > I am able to mount the exported share on client (centos) as follows:
> > 
> > sudo mount -t nfs -o rw,noauto -v 192.168.0.122:/nfs/testdir mntpt3
> > 
> > From the client, I can read the contents. But writing inside the mounted
> > directory yields permission denied error. Looking at the docs I am not able
> > to find any otherconfig options for access control on the client side.
> > There is nothing in the logs on the server side as well. Any pointers to
> > debug/fix would be of great help.
> 
> Is /var/log/daemon happy, when you start the mountd ?
>

permission denied when writing to mounted directory exported by NFS server

2023-02-08 Thread Sandeep Gupta

I have a default installation of openbsd, with portmap, mountd, nfsd
services started via rcctl. I have following entry in /etc/exports

/nfs/testdir -alldirs  -maproot=root -network=192.168.0 -mask=255.255.255.0

I am able to mount the exported share on client (centos) as follows:

sudo mount -t nfs -o rw,noauto -v 192.168.0.122:/nfs/testdir mntpt3

>From the client, I can read the contents. But writing inside the mounted
directory yields permission denied error. Looking at the docs I am not able
to find any otherconfig options for access control on the client side.
There is nothing in the logs on the server side as well. Any pointers to
debug/fix would be of great help.

Re: Some NFS clients won't mount

2023-01-01 Thread vitmau...@gmail.com

Theo helped solve my main concern. In my mind, I was kinda comparing
NFS and HTTP: no one requires a browser (which is essentially a
HTTPclient) to be run as root, so why require a NFS client to be run
this way? But the point is that we have securely written HTTP servers,
so we don't need to be so strict when it comes to who talks to these
servers. Unfortunately, the same cannot be said of NFS servers.

Thank you guys for the help and for making things clearer for me.

Best,
Vitor

Em dom., 1 de jan. de 2023 às 06:39, Theo de Raadt
 escreveu:
>
> vitmau...@gmail.com  wrote:
>
> > I did some tests and I'm now pretty sure the problem revolves around
> > the point naddy made: Kodi and VLC try to mount my NFS share through a
> > non-privileged port. As both Kodi and VLC use the same NFS client
> > library (libnfs), I tried to find out a bit more about how it works.
> > According to its readme, libnfs uses standard NFS ports when run as
> > root and non-privileged ports when run non-root. Here is the relevant
> > part of the readme file: "When running as root, libnfs tries to
> > allocate a system port for its connection to the NFS server. When
> > running as non-root it will use a normal ephemeral port". I find it
> > strange that a client library should be run as root in order to use a
> > privileged port. My (very poor, I confess) understanding was that only
> > server processes should be run as root in order to use privileged
> > ports. Anyway, as things stand I can only mount my OpenBSD NFS shares
> > if the client is run as root, since the usual way to circumvent this
> > problem on the server side (set the insecure flag on exports) is not
> > available on OpenBSD and, I hope, won't ever be. As I don't have root
> > access to my Fire Stick TV, there is no way to mount my OpenBSD NFS
> > shares on it. As I'm no expert on security though, I'd like an opinion
> > from you guys regarding this: is it reasonable to require an NFS
> > client to be run as root?
>
> Yes, it is very reasonable, because after five decades noone has written
> a bug-free NFS server, so this mechanism limiting who can talk to it
> makes sense.
>
> More general comment on this matter: The use of reserved ports for
> numerous protocols will continue to make sense FOREVER, no matter what
> the naysayers say, because there are protocols with insufficient
> alternative authentication methods or services you don't want generic
> users to startup on a shared system and behave as the cannonical
> offering of that service from such a shared system machine.  If anyone
> things we are wrong, go to IETF and convince then to move http and https
> to non-reserved well-known ports *by default*.  Anyone who tries this
> will get nowhere there, and will get nowhere here either... practical
> matters force this.
>
> Sorry.

Re: Some NFS clients won't mount

2023-01-01 Thread Theo de Raadt

vitmau...@gmail.com  wrote:

> I did some tests and I'm now pretty sure the problem revolves around
> the point naddy made: Kodi and VLC try to mount my NFS share through a
> non-privileged port. As both Kodi and VLC use the same NFS client
> library (libnfs), I tried to find out a bit more about how it works.
> According to its readme, libnfs uses standard NFS ports when run as
> root and non-privileged ports when run non-root. Here is the relevant
> part of the readme file: "When running as root, libnfs tries to
> allocate a system port for its connection to the NFS server. When
> running as non-root it will use a normal ephemeral port". I find it
> strange that a client library should be run as root in order to use a
> privileged port. My (very poor, I confess) understanding was that only
> server processes should be run as root in order to use privileged
> ports. Anyway, as things stand I can only mount my OpenBSD NFS shares
> if the client is run as root, since the usual way to circumvent this
> problem on the server side (set the insecure flag on exports) is not
> available on OpenBSD and, I hope, won't ever be. As I don't have root
> access to my Fire Stick TV, there is no way to mount my OpenBSD NFS
> shares on it. As I'm no expert on security though, I'd like an opinion
> from you guys regarding this: is it reasonable to require an NFS
> client to be run as root?

Yes, it is very reasonable, because after five decades noone has written
a bug-free NFS server, so this mechanism limiting who can talk to it
makes sense.

More general comment on this matter: The use of reserved ports for
numerous protocols will continue to make sense FOREVER, no matter what
the naysayers say, because there are protocols with insufficient
alternative authentication methods or services you don't want generic
users to startup on a shared system and behave as the cannonical
offering of that service from such a shared system machine.  If anyone
things we are wrong, go to IETF and convince then to move http and https
to non-reserved well-known ports *by default*.  Anyone who tries this
will get nowhere there, and will get nowhere here either... practical
matters force this.

Sorry.

Re: Some NFS clients won't mount

2022-12-31 Thread vitmau...@gmail.com

I did some tests and I'm now pretty sure the problem revolves around
the point naddy made: Kodi and VLC try to mount my NFS share through a
non-privileged port. As both Kodi and VLC use the same NFS client
library (libnfs), I tried to find out a bit more about how it works.
According to its readme, libnfs uses standard NFS ports when run as
root and non-privileged ports when run non-root. Here is the relevant
part of the readme file: "When running as root, libnfs tries to
allocate a system port for its connection to the NFS server. When
running as non-root it will use a normal ephemeral port". I find it
strange that a client library should be run as root in order to use a
privileged port. My (very poor, I confess) understanding was that only
server processes should be run as root in order to use privileged
ports. Anyway, as things stand I can only mount my OpenBSD NFS shares
if the client is run as root, since the usual way to circumvent this
problem on the server side (set the insecure flag on exports) is not
available on OpenBSD and, I hope, won't ever be. As I don't have root
access to my Fire Stick TV, there is no way to mount my OpenBSD NFS
shares on it. As I'm no expert on security though, I'd like an opinion
from you guys regarding this: is it reasonable to require an NFS
client to be run as root?

Best,
Vitor

Em sex., 30 de dez. de 2022 às 15:20, Bodie  escreveu:
>
> On Fri Dec 30, 2022 at 3:59 PM CET, vitmau...@gmail.com wrote:
> > Thank you guys for the tips. I think naddy is right, which means I was
> > wrong in thinking that I finally had a doubt that couldn't be solved
> > by OpenBSD's manuals. I'll do some tests and report back on this
> > thread soon.
>
> Don't forget to check firewall as NFSv4 from your Fedora 34 has
> way less requirements then NFSv3 served by OpenBSD
>
> You can compare 'rpcinfo -p localhost' on your OpenBSD server
> vs same command remotely from client (with proper hostname/IP)
>
> And NFSv3 is by default UDP while NFSv4 is TCP
>
> >
> > Best,
> > Vitor
> >
> > Em qui., 29 de dez. de 2022 às 16:55, Christian Weisgerber
> >  escreveu:
> > >
> > > "vitmau...@gmail.com":
> > >
> > > > My /var/log/daemon regarding the issue:
> > > > mountd[91001]: Refused mount RPC from host 192.168.1.4 port 57264
> > >
> > > The client's mount request didn't come from a reserved port, i.e. <1024.
> > > OpenBSD's mountd(8) does not accept this.
> > >
> > > --
> > > Christian "naddy" Weisgerber  na...@mips.inka.de
>

Re: Some NFS clients won't mount

2022-12-30 Thread Bodie

On Fri Dec 30, 2022 at 3:59 PM CET, vitmau...@gmail.com wrote:
> Thank you guys for the tips. I think naddy is right, which means I was
> wrong in thinking that I finally had a doubt that couldn't be solved
> by OpenBSD's manuals. I'll do some tests and report back on this
> thread soon.

Don't forget to check firewall as NFSv4 from your Fedora 34 has
way less requirements then NFSv3 served by OpenBSD

You can compare 'rpcinfo -p localhost' on your OpenBSD server
vs same command remotely from client (with proper hostname/IP)

And NFSv3 is by default UDP while NFSv4 is TCP

>
> Best,
> Vitor
>
> Em qui., 29 de dez. de 2022 às 16:55, Christian Weisgerber
>  escreveu:
> >
> > "vitmau...@gmail.com":
> >
> > > My /var/log/daemon regarding the issue:
> > > mountd[91001]: Refused mount RPC from host 192.168.1.4 port 57264
> >
> > The client's mount request didn't come from a reserved port, i.e. <1024.
> > OpenBSD's mountd(8) does not accept this.
> >
> > --
> > Christian "naddy" Weisgerber  na...@mips.inka.de

Re: Some NFS clients won't mount

2022-12-30 Thread vitmau...@gmail.com

Thank you guys for the tips. I think naddy is right, which means I was
wrong in thinking that I finally had a doubt that couldn't be solved
by OpenBSD's manuals. I'll do some tests and report back on this
thread soon.

Best,
Vitor

Em qui., 29 de dez. de 2022 às 16:55, Christian Weisgerber
 escreveu:
>
> "vitmau...@gmail.com":
>
> > My /var/log/daemon regarding the issue:
> > mountd[91001]: Refused mount RPC from host 192.168.1.4 port 57264
>
> The client's mount request didn't come from a reserved port, i.e. <1024.
> OpenBSD's mountd(8) does not accept this.
>
> --
> Christian "naddy" Weisgerber  na...@mips.inka.de

Re: Some NFS clients won't mount

2022-12-29 Thread Christian Weisgerber

"vitmau...@gmail.com":

> My /var/log/daemon regarding the issue:
> mountd[91001]: Refused mount RPC from host 192.168.1.4 port 57264

The client's mount request didn't come from a reserved port, i.e. <1024.
OpenBSD's mountd(8) does not accept this.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: Some NFS clients won't mount

2022-12-29 Thread Łukasz Moskała


W dniu 29.12.2022 o 17:29, vitmau...@gmail.com pisze:

I have a NFS share on OpenBSD with a Windows 10 and a FireOS clients
(through VLC and Kodi). Windows 10 mounts the NFS share without issue,
but the Fire OS can't mount it either through VLC or Kodi. Before
moving to OpenBSD I had a NFS share on Fedora 34 and all my systems
could mount it.

I've found a similar problem on the lists, but it came down to NAT
issues and I don't think that is my case, since the Windows client
mounts the share successfully. Here's the entry:
https://www.mail-archive.com/bugs@openbsd.org/msg15280.html

I considered a version problem (NFSv3 vs NFSv4 or something of the
sort), but the version of libnfs used by both Kodi and VLC implements
NFSv3.

My exports file (tried mapall to my user, to root, and to nobody; none worked):
/home/vitor/server -alldirs -ro -network=192.168.1.0 -mask=255.255.255.0

My /var/log/daemon regarding the issue:
mountd[91001]: Refused mount RPC from host 192.168.1.4 port 57264

VLC for Android (version 3.5.3) log:
[8fdb48f0/39db] libvlc stream: nfs_mount_cb failed: -14, 'RPC Packet
not accepted by the server'

Kodi (version 19.5) log:
NFS: Failed to mount nfs share: /home/vitor/server (mount_cb: )
GetDirectory - Error getting nfs://192.168.1.14/home/vitor/server/
CGUIDialogFileBrowser::GetDirectory(nfs://192.168.1.14/home/vitor/server/)
failed

Server version:
OpenBSD 7.2 GENERIC.MP#758 amd64

Any help will be much appreciated.

Best,
Vitor



Just a guess, I don't know much about openbsd's nfs server

Is both server and client trying to use the same protocol (UDP or TCP)?

From man 8 nfsd: "Unless otherwise specified, four servers for UDP 
transport are started."


So, maybe windows uses udp (or at least falls back to udp) while vlc 
does not?


AFAIK linux's NFS server uses TCP by default (at least on archlinux, 
according to man 8 nfsd) so this could explain why it worked when server 
was on fedora.


Hope this helps


Regards,
--
Łukasz Moskała

Some NFS clients won't mount

2022-12-29 Thread vitmau...@gmail.com

I have a NFS share on OpenBSD with a Windows 10 and a FireOS clients
(through VLC and Kodi). Windows 10 mounts the NFS share without issue,
but the Fire OS can't mount it either through VLC or Kodi. Before
moving to OpenBSD I had a NFS share on Fedora 34 and all my systems
could mount it.

I've found a similar problem on the lists, but it came down to NAT
issues and I don't think that is my case, since the Windows client
mounts the share successfully. Here's the entry:
https://www.mail-archive.com/bugs@openbsd.org/msg15280.html

I considered a version problem (NFSv3 vs NFSv4 or something of the
sort), but the version of libnfs used by both Kodi and VLC implements
NFSv3.

My exports file (tried mapall to my user, to root, and to nobody; none worked):
/home/vitor/server -alldirs -ro -network=192.168.1.0 -mask=255.255.255.0

My /var/log/daemon regarding the issue:
mountd[91001]: Refused mount RPC from host 192.168.1.4 port 57264

VLC for Android (version 3.5.3) log:
[8fdb48f0/39db] libvlc stream: nfs_mount_cb failed: -14, 'RPC Packet
not accepted by the server'

Kodi (version 19.5) log:
NFS: Failed to mount nfs share: /home/vitor/server (mount_cb: )
GetDirectory - Error getting nfs://192.168.1.14/home/vitor/server/
CGUIDialogFileBrowser::GetDirectory(nfs://192.168.1.14/home/vitor/server/)
failed

Server version:
OpenBSD 7.2 GENERIC.MP#758 amd64

Any help will be much appreciated.

Best,
Vitor

Fujitsu Futuro S920 as nfs client strange behaviour

2022-05-31 Thread T K

I have strange behaviour while using Futuro S920 / release 7.1
as an nfs client. I have two nfsd servers in my lan: FreeBSD 13.1
with ZFS and for comparsion purposes similar Futuro s920 running
release 7.1.
I tested many mount options and as the most transfer-effective (and usable
at all) option
I have (mount output):

SERVERIP:/exportedshare on /clientmountpoint type nfs (noatime, nodev,
noexec,
nosuid, v3, tcp, intr, wsize=1024, rsize=32768, rdirsize=32768, timeo=100,
retrans=101, readahead=0)

With such config I can reach read speeds at 32 mB/s which is comparable to
internal transfers
between two SDDs inside  the Futuro. But write speed is around 10 times
slower no matter if I write to
OpenBSD nfs server or FreeBSD. I also tried wsize=32768, no visible change.

As for now I did not found any way to reach higher write speeds.
While writting multiple small files everything goes slow but smooth,
writting file
bigger than around 18 megabytes I have lags in the middle and at the end of
the transfer process.
Depending on the file size it can be few seconds or even more than a minute
to finish the whole process,
not including random iddles and rebirths.
I tested it with Midnight Commander (progress meter showing speed) and also
with rsync --progress
--stats: both ways look similar. I allready tried to set MTU = 9000 on both
ends of communication
with also no visible effect. Same with different NIC's - no change.

Finally I tried to use other PC machine with Debian Linux as client, and
writes/reads with FreeBSD server works like a charm,
but communication with the above mentioned second Futuro/OpenBSD has the
same write speed issues.

I suppose it is some kind of hardware issue at the Futuro side, looks like
"some kind" of "write buffer"
is overflowing while the sending file size exceeds 18 MB.
No idea what can I do to solve my problem, any suggestion appreciated.
Below is dmesg from client Futuro:

OpenBSD 7.1 (GENERIC.MP) #1: Tue May  3 09:11:23 MDT 2022
r...@syspatch-71-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
GENERIC.MP
real mem = 3916890112 (3735MB)
avail mem = 3780894720 (3605MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xacec8018 (55 entries)
bios0: vendor FUJITSU // American Megatrends Inc. version "V4.6.5.4 R1.14.0
for D3313-G1x" date 09/21/2017
bios0: FUJITSU FUTRO S920
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT TCPA MCFG HPET SSDT SSDT SSDT SSDT
SSDT
acpi0: wakeup devices LAN1(S4) LAN2(S4) LAN3(S4) SBAZ(S4) EHC1(S4) EHC2(S4)
EHC3(S4) XHC0(S4) GFX_(S3)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD GX-222GC SOC with Radeon(TM) R5E Graphics, 2196.18 MHz, 16-30-01
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 1MB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD GX-222GC SOC with Radeon(TM) R5E Graphics, 2195.89 MHz, 16-30-01
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 1MB
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 3 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 4 pa 0xfec01000, version 21, 32 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (GPP0)
acpiprt2 at acpi0: bus -1 (GPP1)
acpiprt3 at acpi0: bus -1 (GPP2)
acpiprt4 at acpi0: bus -1 (GPP3)
acpiprt5 at acpi0: bus 1 (GFX_)
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
com0 at acpi0 UAR0 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
acpicmos0 at acpi0
com1 at acpi0 UAR1 addr 0x2f8/0x8 irq 3: ns16550a, 1

Re: No longer able to mount NFS shares

2022-04-11 Thread Alexander Hall

Is reverse DNS properly working at all sides?

On April 7, 2022 1:17:00 AM GMT+02:00, Aric Gregson  wrote:
>Hello,
>
>I have several NFS mount points shared on my local network from a
>FreeNAS server running version 11.1-U7. My OBSD client computer is
>running 7.0 GENERIC#224 amd64. 
>
>For the past year or so it has been very slow to connect to the NFS
>server, so slow in fact that I use the '-b' option to fork to the
>background and stopped trying to mount at boot. About six months ago I
>moved our home network to an Ubiquiti set-up. Since then my OBSD client
>is even slower to connect. I have Macs running different levels of Mac
>OS that, while now take up to 15s to connect, all do connect. Also, a
>Raspberry Pi 4 server can connect quickly to the same shares. 
>
>Once connected, writes are fast and I do not lose connection. 
>
>For the last 48h I have not been able to connect from the OBSD client
>at all. I have restarted the server to no effect. All other clients on
>the network can connect to the NFS shares. 
>
>Example of what happens with the command:
>
>doas mount_nfs -T -i -b 192.168.1.21:mnt/XFree/backups/share
>/share 
>
>mount_nfs: bad MNT RPC: RPC: Timed out
>
>Any suggestions would be greatly appreciated. 
>
>Thanks, Aric
>
>
>OpenBSD 7.0 (GENERIC) #224: Thu Sep 30 14:13:34 MDT 2021
>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
>real mem = 17037697024 (16248MB)
>avail mem = 16505421824 (15740MB)
>random: boothowto does not indicate good seed
>mpath0 at root
>scsibus0 at mpath0: 256 targets
>mainbus0 at root
>bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7a696000 (62 entries)
>bios0: vendor LENOVO version "N1QET85W (1.60 )" date 08/30/2019
>bios0: LENOVO 20HDCTO1WW
>acpi0 at bios0: ACPI 5.0
>acpi0: sleep states S0 S3 S4 S5
>acpi0: tables DSDT FACP SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT
>SSDT SSDT BOOT BATB SLIC SSDT SSDT SSDT WSMT SSDT SSDT DBGP DBG2 MSDM
>DMAR ASF! FPDT UEFI acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4)
>HDAS(S4) RP01(S4) RP02(S4) RP03(S4) RP04(S4) RP05(S4) RP06(S4) RP08(S4)
>RP09(S4) RP10(S4) RP11(S4) RP12(S4) RP13(S4) [...] acpitimer0 at acpi0:
>3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0
>addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor)
>cpu0: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz, 2687.58 MHz, 06-8e-09
>cpu0:
>FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
>cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0
>mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0:
>apic clock running at 24MHz cpu0: mwait min=64, max=64,
>C-substates=0.2.1.2.4.1.1.1, IBE cpu at mainbus0: not configured
>cpu at mainbus0: not configured
>cpu at mainbus0: not configured
>ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
>acpimcfg0 at acpi0
>acpimcfg0: addr 0xf000, bus 0-63
>acpiec0 at acpi0
>acpiprt0 at acpi0: bus 0 (PCI0)
>acpiprt1 at acpi0: bus 2 (RP01)
>acpiprt2 at acpi0: bus -1 (RP02)
>acpiprt3 at acpi0: bus -1 (RP03)
>acpiprt4 at acpi0: bus -1 (RP04)
>acpiprt5 at acpi0: bus -1 (RP05)
>acpiprt6 at acpi0: bus -1 (RP06)
>acpiprt7 at acpi0: bus 4 (RP07)
>acpiprt8 at acpi0: bus -1 (RP08)
>acpiprt9 at acpi0: bus 5 (RP09)
>acpiprt10 at acpi0: bus -1 (RP10)
>acpiprt11 at acpi0: bus 62 (RP11)
>acpiprt12 at acpi0: bus -1 (RP12)
>acpiprt13 at acpi0: bus -1 (RP13)
>acpiprt14 at acpi0: bus -1 (RP14)
>acpiprt15 at acpi0: bus -1 (RP15)
>acpiprt16 at acpi0: bus -1 (RP16)
>acpiprt17 at acpi0: bus -1 (RP17)
>acpiprt18 at acpi0: bus -1 (RP18)
>acpiprt19 at acpi0: bus -1 (RP19)
>acpiprt20 at acpi0: bus -1 (RP20)
>acpiprt21 at acpi0: bus -1 (RP21)
>acpiprt22 at acpi0: bus -1 (RP22)
>acpiprt23 at acpi0: bus -1 (RP23)
>acpiprt24 at acpi0: bus -1 (RP24)
>acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
>acpithinkpad0 at acpi0: version 2.0
>acpiac0 at acpi0: AC unit online
>acpibat0 at acpi0: BAT0 model "01AV421" serial  3690 type LiP oem "SMP"
>acpibat1 at acpi0: BAT1 model "01AV492" serial  4004 type LION oem "LGC"
>acpicmos0 at acpi0
>acpibtn0 at acpi0: SLPB
>"PNP0C14" at acpi0 not configured
>acpibtn1 at acpi0: LID_
>"PNP0C14" at acpi0 not c

Re: No longer able to mount NFS shares

2022-04-05 Thread Danny Wilkins

The nfs server isn't running Linux, is it?

Try adding -o tcp as a mount option

On April 4, 2022 5:54:22 PM EDT, Aric Gregson  wrote:
>Hello,
>
>I have several NFS mount points shared on my local network from a
>FreeNAS server running version 11.1-U7. My OBSD client computer is
>running 7.0 GENERIC#224 amd64. 
>
>For the past year or so it has been very slow to connect to the NFS
>server, so slow in fact that I use the '-b' option to fork to the
>background and stopped trying to mount at boot. About six months ago I
>moved our home network to an Ubiquiti set-up. Since then my OBSD client
>is even slower to connect. I have Macs running different levels of Mac
>OS that, while now take up to 15s to connect, all do connect. Also, a
>Raspberry Pi 4 server can connect quickly to the same shares. 
>
>Once connected, writes are fast and I do not lose connection. 
>
>For the last 48h I have not been able to connect from the OBSD client
>at all. I have restarted the server to no effect. All other clients on
>the network can connect to the NFS shares. 
>
>Example of what happens with the command:
>
>doas mount_nfs -T -i -b 192.168.1.21:/mnt/XFree/backups/share
>/share 
>
>mount_nfs: bad MNT RPC: RPC: Timed out
>
>Any suggestions would be greatly appreciated. 
>
>Thanks, Aric
>

Re: help debug NFS

2021-04-12 Thread Родин Максим

Hi, James
Thank you for the link.
Since the problem really exists, the only option is to
use a periodical querying the mount point like you recommend or like
I did using while-loop.

11.04.2021 21:11, James Stark пишет:

Hi Maxim,

I ran into the problem with the nfs mounts on linux hanging a few
months ago, when the Linux distro that I'm running (Void) on the NFS
client dropped UDP NFS mounts. At the time I found this post that
explains the situation:

http://openbsd-archive.7691.n7.nabble.com/nfsd-hangs-Linux-tcp-clients-after-5-minutes-idle-td402844.html

As a work around, I've set up a cron script that stat's the mount
point every four minutes. That stops the mount from hanging.

I hope that helps.

James

On Sun, Apr 11, 2021 at 2:04 AM Родин Максим wrote:

Hello
I have an NFS server on OpenBSD 6.8 stable
which exports a folder with default settings.
I have a linux mint client which mounts a share from this NFS server
with these settings:
sudo mount -o wsize=8192,rsize=8192 192.168.1.65:/big
/home/user/store
which gives a decent speed at about 50-60MB/s both sides which seem ok
for me.
The problem is: when the mount point is not used for a while (5 minutes
and more) the share becomes unresponsive and the only way to unmount the
share is to do
sudo umount -lf /home/user/store
After that I can mount the share once again.
When I imitate using the share on client using
while :; do ls /home/user/store/ && echo "OK" && sleep 3 ; done;
the share remains responsive all the time and shows no problems.

What tweaks(settings) on the client(server) am I missing in my setup
to keep the mount point responsive?
--
Best regards
Maksim Rodin

--
С уважением,
Родин Максим

Re: help debug NFS

2021-04-11 Thread James Stark

Hi Maxim,

I ran into the problem with the nfs mounts on linux hanging a few
months ago, when the Linux distro that I'm running (Void) on the NFS
client dropped UDP NFS mounts.  At the time I found this post that
explains the situation:

http://openbsd-archive.7691.n7.nabble.com/nfsd-hangs-Linux-tcp-clients-after-5-minutes-idle-td402844.html

As a work around, I've set up a cron script that stat's the mount
point every four minutes.  That stops the mount from hanging.

I hope that helps.

James

On Sun, Apr 11, 2021 at 2:04 AM Родин Максим  wrote:
>
> Hello
> I have an NFS server on OpenBSD 6.8 stable
> which exports a folder with default settings.
> I have a linux mint client which mounts a share from this NFS server
> with these settings:
> sudo mount -o wsize=8192,rsize=8192 192.168.1.65:/big
> /home/user/store
>   which gives a decent speed at about 50-60MB/s both sides which seem ok
> for me.
> The problem is: when the mount point is not used for a while (5 minutes
> and more) the share becomes unresponsive and the only way to unmount the
> share is to do
> sudo umount -lf /home/user/store
> After that I can mount the share once again.
> When I imitate using the share on client using
> while :; do ls /home/user/store/ && echo "OK" && sleep 3 ; done;
> the share remains responsive all the time and shows no problems.
>
> What tweaks(settings) on the client(server) am I missing in my setup
> to keep the mount point responsive?
> --
> Best regards
> Maksim Rodin
>

Re: help debug NFS

2021-04-11 Thread Ed Gray

Hi Maxim,

I cannot help you fix this as I don't have a similar set-up but I can tell
you this isn't normal behaviour for NFS. You should not need to tweak
anything to get a stable mount at least in my experience.

It sounds like a bug somewhere to me.

You could try using the gnu watch command or similar while loop to run an
ls of the share from the client to confirm if it hangs after non use or
after five minutes regardless of use or non-use.

You could also try testing the network connection between the two machines
to make sure there is no connectivity or cable problem.

You could use the same while loop to run rpcinfo or showmount commands from
the client and server to see if it stops working after the same delay.

Someone with more knowledge of NFS might suggest some better debugging
steps...

Regards
Ed Gray

On Sun, 11 Apr 2021, 10:07 am Родин Максим,  wrote:

> Hello
> I have an NFS server on OpenBSD 6.8 stable
> which exports a folder with default settings.
> I have a linux mint client which mounts a share from this NFS server
> with these settings:
> sudo mount -o wsize=8192,rsize=8192 192.168.1.65:/big
> /home/user/store
>   which gives a decent speed at about 50-60MB/s both sides which seem ok
> for me.
> The problem is: when the mount point is not used for a while (5 minutes
> and more) the share becomes unresponsive and the only way to unmount the
> share is to do
> sudo umount -lf /home/user/store
> After that I can mount the share once again.
> When I imitate using the share on client using
> while :; do ls /home/user/store/ && echo "OK" && sleep 3 ; done;
> the share remains responsive all the time and shows no problems.
>
> What tweaks(settings) on the client(server) am I missing in my setup
> to keep the mount point responsive?
> --
> Best regards
> Maksim Rodin
>
>

help debug NFS

2021-04-11 Thread Родин Максим


Hello
I have an NFS server on OpenBSD 6.8 stable
which exports a folder with default settings.
I have a linux mint client which mounts a share from this NFS server 
with these settings:

sudo mount -o wsize=8192,rsize=8192 192.168.1.65:/big
/home/user/store
 which gives a decent speed at about 50-60MB/s both sides which seem ok 
for me.
The problem is: when the mount point is not used for a while (5 minutes 
and more) the share becomes unresponsive and the only way to unmount the 
share is to do

sudo umount -lf /home/user/store
After that I can mount the share once again.
When I imitate using the share on client using
while :; do ls /home/user/store/ && echo "OK" && sleep 3 ; done;
the share remains responsive all the time and shows no problems.

What tweaks(settings) on the client(server) am I missing in my setup
to keep the mount point responsive?
--
Best regards
Maksim Rodin

Re: Help debugging slow nfs (40kB/s); linux client

2020-04-18 Thread Nathan Clement

Wow! Lowering rsize helped a lot! I can get about 4-5MB/s now.
I had tried increasing rsize before, but I didn't imagine lowering
it would help. Thank you!

I'll mess around with some of the other parameters now to
optimize:
* rsize set in client mount command
* nconnect set in client mount command
* num_servers set by nfsd flag on the server
* vfs.nfs.iothreads set in the sysctl.conf of the server

But I welcome any other suggestions of parameters to tune.

-Nathan

On Sat, Apr 18, 2020 at 2:55 AM Родин Максим  wrote:
>
> Hello,
> Try these options:
>
> sudo mount.nfs -o wsize=8192,rsize=8192 IPADDRESS:/shara /home/myuser/shara/
>
> Play with wsize and rsize to achieve better speed.
> These are mines.
>
> 18.04.2020 02:31, Nathan Clement пишет:
> > Hello,
> >
> > I am trying to get an Intel atom mini itx board running as an OpenBSD 6.6
> > NAS.
> > I've got the necessary daemons running on the mini itx board:
> >
> >> doas rcctl ls started
> > cron
> > httpd
> > mountd
> > nfsd
> > ntpd
> > pflogd
> > portmap
> > slaacd
> > smtpd
> > sndiod
> > sshd
> > syslogd
> >
> > and exports is set up:
> >
> >> cat /etc/exports
> > /home/nathan/shared -alldirs -ro
> >
> > I am mounting this from my laptop which runs on arch linux at the moment.
> > On the linux client machine, this is the relevant line from mount:
> >
> > 192.168.1.4:/home/nathan/shared on /home/nathan/mnt type nfs
> > (rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.4,mountvers=3,mountport=997,mountproto=udp,local_lock=none,addr=192.168.1.4)
> >
> > I can copy small files over nfs, but anything large takes way too long.
> > I've read rsync isn't necessarily the best way to gauge transfer speed, but
> > rsync shows I'm getting about 38kB/s transfer speed. For comparison, I
> > tried using sshfs to mount the same directory on the itx to the same
> > location on the linux system and I get ~1.1MB/s, wow! Even that isn't
> > great, but I'm the laptop is on wifi and I figure I can get to more tuning
> > later.
> >
> > It seems clear I'm not (just) dealing with hardware limitations in this nfs
> > mount. What else can I do to debug this?
> >
> > Thanks,
> > Nathan
> >
>
> --
> С уважением,
> Родин Максим

Re: Help debugging slow nfs (40kB/s); linux client

2020-04-18 Thread Alessandro De Laurenzis


Hello Nathan,

On 17/04/2020 - 19:31, Nathan Clement wrote:
[...]
I am mounting this from my laptop which runs on arch linux at the 
moment.

On the linux client machine, this is the relevant line from mount:

192.168.1.4:/home/nathan/shared on /home/nathan/mnt type nfs
(rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.4,mountvers=3,mountport=997,mountproto=udp,local_lock=none,addr=192.168.1.4)


[...]

I recently observed (unfortunately, I'm not able to say from when 
exactly, because I don't use my exports so often...) NSF connection 
slowing down to the point that it was impossible to make common 
operations like playing a video or transferring files with significant 
dimensions.


I reverted to the previous performances changing (on the client side) 
the protocol from TCP to UDP. Of course, YMMV.


In my case, both server and client(s) are running OpenBSD (6.6 the 
server, -current the clients).


The point is that I was not able to gather enough information to send an 
e-mail to bugs@...


--
Alessandro De Laurenzis
[mailto:jus...@atlantide.mooo.com]
Web: http://www.atlantide.mooo.com
LinkedIn: http://it.linkedin.com/in/delaurenzis

Re: Help debugging slow nfs (40kB/s); linux client

2020-04-18 Thread Родин Максим

Hello,
Try these options:

sudo mount.nfs -o wsize=8192,rsize=8192 IPADDRESS:/shara /home/myuser/shara/

Play with wsize and rsize to achieve better speed.
These are mines.

18.04.2020 02:31, Nathan Clement пишет:

Hello,

I am trying to get an Intel atom mini itx board running as an OpenBSD 6.6
NAS.
I've got the necessary daemons running on the mini itx board:

doas rcctl ls started

cron
httpd
mountd
nfsd
ntpd
pflogd
portmap
slaacd
smtpd
sndiod
sshd
syslogd

and exports is set up:

cat /etc/exports

/home/nathan/shared -alldirs -ro

I am mounting this from my laptop which runs on arch linux at the moment.
On the linux client machine, this is the relevant line from mount:

192.168.1.4:/home/nathan/shared on /home/nathan/mnt type nfs
(rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.4,mountvers=3,mountport=997,mountproto=udp,local_lock=none,addr=192.168.1.4)

I can copy small files over nfs, but anything large takes way too long.
I've read rsync isn't necessarily the best way to gauge transfer speed, but
rsync shows I'm getting about 38kB/s transfer speed. For comparison, I
tried using sshfs to mount the same directory on the itx to the same
location on the linux system and I get ~1.1MB/s, wow! Even that isn't
great, but I'm the laptop is on wifi and I figure I can get to more tuning
later.

It seems clear I'm not (just) dealing with hardware limitations in this nfs
mount. What else can I do to debug this?

Thanks,
Nathan

--
С уважением,
Родин Максим

Help debugging slow nfs (40kB/s); linux client

2020-04-17 Thread Nathan Clement

Hello,

I am trying to get an Intel atom mini itx board running as an OpenBSD 6.6
NAS.
I've got the necessary daemons running on the mini itx board:

> doas rcctl ls started
cron
httpd
mountd
nfsd
ntpd
pflogd
portmap
slaacd
smtpd
sndiod
sshd
syslogd

and exports is set up:

> cat /etc/exports
/home/nathan/shared -alldirs -ro

I am mounting this from my laptop which runs on arch linux at the moment.
On the linux client machine, this is the relevant line from mount:

192.168.1.4:/home/nathan/shared on /home/nathan/mnt type nfs
(rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.4,mountvers=3,mountport=997,mountproto=udp,local_lock=none,addr=192.168.1.4)

I can copy small files over nfs, but anything large takes way too long.
I've read rsync isn't necessarily the best way to gauge transfer speed, but
rsync shows I'm getting about 38kB/s transfer speed. For comparison, I
tried using sshfs to mount the same directory on the itx to the same
location on the linux system and I get ~1.1MB/s, wow! Even that isn't
great, but I'm the laptop is on wifi and I figure I can get to more tuning
later.

It seems clear I'm not (just) dealing with hardware limitations in this nfs
mount. What else can I do to debug this?

Thanks,
Nathan

Re: NFS exports everything

2019-06-19 Thread Roderick




On Wed, 19 Jun 2019, Brian Brombacher wrote:


I am guessing /home and / are the same filesystem?

See exports(5):


Yes. This must be the explanation. With -alldirs the first field
must be the root of a file system and not some directory as I put
there. Thanks.

Rodrigo

NFS exports everything

2019-06-19 Thread Roderick




I am quite sleepy, perhaps a stupid error, but annoying.

I have in /etc/exports only the following line:

/home/exp/nfs  -alldirs  -ro  -network=10.0.0.0  -mask=255.255.255.0

I start the nfs service either with "rcctl -f start portmap mountd nfsd" 
or with "portmap; mountd; nfsd -u -t -n 4".


Then I can mount *any* directory in the client, for example:

mount -t nfs 10.0.0.14:/etc /mnt

I do not remember that this is normal. Is it??

Rodrigo

Issue with file not showing up in directory mounted over local NFS

2019-05-28 Thread Andreas Kusalananda Kähäri

Hi,

I'm building current ports in a chroot with dpb(1), and I'm keeping the
ports tree in /extra/ports which is mounted over local NFS to both
/usr/ports and /extra/proot/usr/ports (in my chroot).

Recently I've seen this happening:

$ ls -l /extra/ports/packages/amd64/all/wget*
-rw-r--r--  3 _pbuild  _pbuild  1227063 May 28 12:27
/extra/ports/packages/amd64/all/wget-1.20.3p1.tgz
$ ls -l /usr/ports/packages/amd64/all/wget*
ls: /usr/ports/packages/amd64/all/wget-1.20.3p1.tgz: No such file or directory

That is, the name of the file is listed in the directory entry on the
NFS mount, but the actual file does not appear to be there.  It appears
after a few *minutes* though.

$ mount
/dev/sd0a on / type ffs (local, softdep)
/dev/sd0e on /usr type ffs (local, nodev, softdep)
/dev/sd0d on /var type ffs (local, nodev, nosuid, softdep)
/dev/sd1a on /usr/local type ffs (local, nodev, wxallowed,
softdep)
/dev/sd2a on /home type ffs (local, nodev, softdep)
/dev/sd3a on /extra type ffs (NFS exported, local, nosuid, wxallowed,
softdep)
localhost:/extra/ports on /usr/ports type nfs (v3, udp, timeo=100,
retrans=101)
localhost:/extra/ports on /extra/proot/usr/ports type nfs (v3, udp,
timeo=100, retrans=101)

The entries for the mounts in /etc/fstab:

localhost:/extra/ports  /usr/ports  nfs rw
localhost:/extra/ports  /extra/proot/usr/ports  nfs rw

This is on a current amd64 VM.

What is the cause of the delay and is there anything I could do to
trigger the NFS daemon to deliver the actual file a bit quicker?

Regards,

-- 
Kusalananda
Sweden

short receive (0/4) from nfs server log messages

2019-01-04 Thread mabi

Hello,

I have an OpenBSD 6.4 box where I mount via NFS a share from an NFS server and 
I see a few of the following log messages in /var/log/messages (around 10 per 
day).

short receive (0/4) from nfs server nfsserver:/data/files

I was wondering if this is anything to worry about and what does it really mean?

That NFS share is mounted through my /etc/fstab as such:

nfsserver:/data/files /mnt nfs rw,nodev,nosuid,tcp,nordirplus 0 0

Regards,
Mabi

OT: OpenBSD NFS Performance

2018-11-17 Thread Predrag Punosevac

Jordan Geoghegan wrote:
> On 11/17/18 10:53, Predrag Punosevac wrote:
> > On Sat, Nov 17, 2018 at 01:35:05AM +0100, Willi Rauffer wrote:
> >
> >> Hello,
> >>
> >> we want to make one logical volume out of several physical volumes,
> but there is no \
> >> LVM (Logical Volume Manager) in OpenBSD!
> >> Will there be a LVM in OpenBSD in the future?
> >>
> >> Thanks...Willi Rauffer, UNOBank.org
> > P.S. OpenBSD's NFSv3 server and client implementation is pretty slow
> so
> > that begs the question how you are going to access that data pool.
> >
> I have an OpenBSD 6.3 NFS server, and it is able to achieve gigabit line
> 
> speed no problem. I've transferred hundreds of terrabytes through that
> thing and it hasn't let me down once. Most of the NFS clients 
> connected to it are CentOS 7 machines, and after a bit of fiddling, 
> line speed was achieved without issue.

I can believe that as the NFS read performance is primarily
client-driven.

> The OpenBSD NFS client does seem to be a a tad slow though, and much
> fiddling was required to get anywhere close to line speed with it.

As I already said NFS read performance is primarily client-driven.
Setting the read-ahead (for example, mount_nfs -a 4) is the biggest
performance driver for reads. Unsurprisingly OpenBSD defaults to -a 1.

predrag@oko$ more /etc/fstab|grep nfs
192.168.3.2:/data/nfs/hammer nfs rw,noatime,-a=4 0 0

Most of what I know about the topics was initiated by this wonderful
post of Matt Dillon

https://marc.info/?l=openbsd-misc=146130062830832=2

I would be very interested to learn what you have done to get OpenBSD
NFS client speed close to 1 Gigabit (although at work I only use 10
Gigabit or InfiniBand gear so even 1 Gigabit is only of interest for my
home setup).

Cheers,
Predrag

P.S. Just for the record I would much rather see WAPBL ported and fully
functional on OpenBSD than NFS performance improvment or even HAMMER2.
WAPBL would actually make a real difference for my firewall/embedded
OpenBSD deployments. HAMMER2 would be nice to have on my OpenBSD laptop
but I can leave without it.

Firefox requires pledge customization when home is on NFS

2018-10-29 Thread Robert

Posting this here for documentation purposes:

After the 6.4 / Firefox 63.0 upgrade the ublock/umatrix addons in
Firefox stopped working.

After some discussion with landry@ it turned out that the root cause is
that my home folder is on NFS. This causes a pledge violation, as seen
in these log records:
firefox[24601]: pledge "getpw", syscall 33

The fix is to open the Firefox configuration ("about:config") and add
"getpw" to the "security.sandbox.pledge.content" parameter.

/Robert

Re: Problem with OpenBSD as nfs client

2018-04-30 Thread philipper01

Thank you so much Eike

mount_nfs -T works perfectly.

So i added TCP option in my fstab and all my shares are automatically
mounted.

Philippe



--
Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html

Re: Problem with OpenBSD as nfs client

2018-04-30 Thread Rupert Gallagher

> /home/filip/Documents 192.168.1.1238

1238?

Re: Problem with OpenBSD as nfs client

2018-04-30 Thread Eike Lantzsch

On Sunday, April 29, 2018 10:36:22 AM -04 philipper01 wrote:
> I had a cpy/paste mistake
> 
> my exports file is :
> > /home/filip/Documents 192.168.1.128 (rw)
> > /home/filip/Public 192.168.1.128 (rw)

To be sure that I misunderstand you correctly:
192.168.1.128 is the ip of your OpenBSD 6.3 client?

Can you please try with
/home/filip/Documents 192.168.1 rw
/home/filip/Public 192.168.1 rw
no ()

also try mount_nfs -3 ...
or mount_nfs -2 ...
and also with -U xor -T

To see if your client side is correct you might want to install a second OBSD 
virtual machine with nfsd, export something like /home/filip/test and see if 
you can connect. 

Have success!

> and the output of rpcinfo :
> 
> filip@openbsd:~$ rpcinfo -p 192.168.1.85
>program vers proto   port
> 104   tcp111  portmapper
> 103   tcp111  portmapper
> 102   tcp111  portmapper
> 104   udp111  portmapper
> 103   udp111  portmapper
> 102   udp111  portmapper
> 1000241   udp  51927  status
> 1000241   tcp  46983  status
> 151   udp  20048  mountd
> 151   tcp  20048  mountd
> 152   udp  20048  mountd
> 152   tcp  20048  mountd
> 153   udp  20048  mountd
> 153   tcp  20048  mountd
> 133   tcp   2049  nfs
> 134   tcp   2049  nfs
> 1002273   tcp   2049
> 1000211   udp  37969  nlockmgr
> 1000213   udp  37969  nlockmgr
> 1000214   udp  37969  nlockmgr
> 1000211   tcp  45991  nlockmgr
>     1000213   tcp  45991  nlockmgr
> 1000214   tcp  45991  nlockmgr

No te being a real nfs expert (always worked out-of-the-box except for when I 
did some typos in config files), that looks correct to me
-- 
Eike Lantzsch ZP6CGE

Re: Problem with OpenBSD as nfs client

2018-04-30 Thread vandung

Hi Philipper01,

I am no expert in NFS.

Your OpenBSD NFS client looks to call a different IP that the described
Fedora workstation.

Cheers,

Van Dung



--
Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html

Re: Problem with OpenBSD as nfs client

2018-04-30 Thread Stuart Longland

On 29/04/18 19:22, philipper01 wrote:
> First, im new with OpenBSD 6.3 that i run in Virtualbox.
> 
> I try to setup a NFS share :
> server is Fedora workstation 28
>  - exports file looks like this
> /home/filip/Documents 192.168.1.1238 (rw)
> /home/filip/Public 192.168.1.128 (rw)
> Of course NFS is active on the server
> 
> client is Openbsd 6.3 and i have this message when i try to mount a share :
> 
> filip@openbsd:~$ sudo mount -t nfs 192.168.1.85:/home/filip/Documents
> /mnt/nfs_Documents/
> NFS Portmap: RPC: Program not registered
> 
> I will be happy to find a solution after long time on google without succes.
> Thanks for help

This might be a silly question, but have you succeeded in getting *any*
NFS client to talk to your server?  A Fedora-based VM perhaps?

Let's prove the server is working as expected, if it isn't, you might be
able to get assistance from the Fedora side.  I myself can't really help
here as I basically stopped using Red Hat-derived distributions shortly
before Fedora Core 1 was released.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Re: Problem with OpenBSD as nfs client

2018-04-29 Thread philipper01

I had a cpy/paste mistake 

my exports file is :
 
> /home/filip/Documents 192.168.1.128 (rw)
> /home/filip/Public 192.168.1.128 (rw)

and the output of rpcinfo :
 
filip@openbsd:~$ rpcinfo -p 192.168.1.85
   program vers proto   port
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
1000241   udp  51927  status
1000241   tcp  46983  status
151   udp  20048  mountd
151   tcp  20048  mountd
152   udp  20048  mountd
152   tcp  20048  mountd
153   udp  20048  mountd
153   tcp  20048  mountd
133   tcp   2049  nfs
134   tcp   2049  nfs
1002273   tcp   2049
1000211   udp  37969  nlockmgr
1000213   udp  37969  nlockmgr
1000214   udp  37969  nlockmgr
1000211   tcp  45991  nlockmgr
1000213   tcp  45991  nlockmgr
1000214   tcp  45991  nlockmgr




--
Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html

Problem with OpenBSD as nfs client

2018-04-29 Thread philipper01

Hi,

First, im new with OpenBSD 6.3 that i run in Virtualbox.

I try to setup a NFS share :
server is Fedora workstation 28
 - exports file looks like this
/home/filip/Documents 192.168.1.1238 (rw)
/home/filip/Public 192.168.1.128 (rw)
Of course NFS is active on the server

client is Openbsd 6.3 and i have this message when i try to mount a share :

filip@openbsd:~$ sudo mount -t nfs 192.168.1.85:/home/filip/Documents
/mnt/nfs_Documents/
NFS Portmap: RPC: Program not registered

I will be happy to find a solution after long time on google without succes.
Thanks for help
Philippe.



--
Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html

Re: Problem with OpenBSD as nfs client

2018-04-29 Thread Ken M

Best guess the problem is selinux on the fedora side.

Try setting it to permissive and if that solves the problem.

If that does solve the problem you need to analyze what to change in 
selinux not just leave it at permissive. Sorry I forget the exact commands 
but they can be found with a quick google search.

Ken



> On Apr 29, 2018, at 8:48 AM, Eike Lantzsch <zp6...@gmx.net> wrote:
> 
>> On Sunday, April 29, 2018 2:14:23 PM -04 philippe@laposte.net wrote:
>> Hi,
>> 
>> First, im new with OpenBSD 6.3 that i run in Virtualbox.
>> 
>> I try to setup a NFS share :
>> server is Fedora workstation 28
>> - exports file looks like this
>> /home/filip/Documents 192.168.1.1238 (rw)
>> /home/filip/Public 192.168.1.128 (rw)
>> Of course NFS is active on the server
>> 
>> client is Openbsd 6.3 and i have this message when i try to mount a share :
>> 
>> filip@openbsd:~$ sudo mount -t nfs 192.168.1.85:/home/filip/Documents
>> /mnt/nfs_Documents/ NFS Portmap: RPC: Program not registered
>> 
>> I will be happy to find a solution after long time on google without succes.
>> Thanks for help
>> Philippe.
> 
> Sorry Philippe, but I have no knowledge of Fedora but what does your OBSD on 
> Virtualbox say about:
> rpcinfo -p 192.168.1.85
> 
> Which version of nfs is running on Fedora and is the portmapper running?
> The following discussion might be of help:
> https://forums.fedoraforum.org/showthread.php?186999-NFS-mounting-problems-quot-RPC-Error-Program-not-registered-quot
> 
> I wish you success
> Eike
> -- 
> Eike Lantzsch ZP6CGE
> 
> You can’t have your π and eat it.
>

Re: Problem with OpenBSD as nfs client

2018-04-29 Thread Eike Lantzsch

On Sunday, April 29, 2018 2:14:23 PM -04 philippe@laposte.net wrote:
> Hi,
> 
> First, im new with OpenBSD 6.3 that i run in Virtualbox.
> 
> I try to setup a NFS share :
> server is Fedora workstation 28
> - exports file looks like this
> /home/filip/Documents 192.168.1.1238 (rw)
> /home/filip/Public 192.168.1.128 (rw)
> Of course NFS is active on the server
> 
> client is Openbsd 6.3 and i have this message when i try to mount a share :
> 
> filip@openbsd:~$ sudo mount -t nfs 192.168.1.85:/home/filip/Documents
> /mnt/nfs_Documents/ NFS Portmap: RPC: Program not registered
> 
> I will be happy to find a solution after long time on google without succes.
> Thanks for help
> Philippe.

Sorry Philippe, but I have no knowledge of Fedora but what does your OBSD on 
Virtualbox say about:
rpcinfo -p 192.168.1.85

Which version of nfs is running on Fedora and is the portmapper running?
The following discussion might be of help:
https://forums.fedoraforum.org/showthread.php?186999-NFS-mounting-problems-quot-RPC-Error-Program-not-registered-quot

I wish you success
Eike
-- 
Eike Lantzsch ZP6CGE

You can’t have your π and eat it.

Re: Problem with OpenBSD as nfs client

2018-04-29 Thread Solene Rapenne


philippe@laposte.net writes:

> Hi, 
>
> First, im new with OpenBSD 6.3 that i run in Virtualbox. 
>
> I try to setup a NFS share : 
> server is Fedora workstation 28 
> - exports file looks like this 
> /home/filip/Documents 192.168.1.1238 (rw) 
> /home/filip/Public 192.168.1.128 (rw) 
> Of course NFS is active on the server 
>
> client is Openbsd 6.3 and i have this message when i try to mount a share : 
>
> filip@openbsd:~$ sudo mount -t nfs 192.168.1.85:/home/filip/Documents 
> /mnt/nfs_Documents/ 
> NFS Portmap: RPC: Program not registered 
>
> I will be happy to find a solution after long time on google without succes. 
> Thanks for help 
> Philippe. 

Something is wrong on your NFS server

Problem with OpenBSD as nfs client

2018-04-29 Thread philippe . r01

Hi, 

First, im new with OpenBSD 6.3 that i run in Virtualbox. 

I try to setup a NFS share : 
server is Fedora workstation 28 
- exports file looks like this 
/home/filip/Documents 192.168.1.1238 (rw) 
/home/filip/Public 192.168.1.128 (rw) 
Of course NFS is active on the server 

client is Openbsd 6.3 and i have this message when i try to mount a share : 

filip@openbsd:~$ sudo mount -t nfs 192.168.1.85:/home/filip/Documents 
/mnt/nfs_Documents/ 
NFS Portmap: RPC: Program not registered 

I will be happy to find a solution after long time on google without succes. 
Thanks for help 
Philippe.

Re: NFS keeps crashing

2018-04-26 Thread Rupert Gallagher

The following patch from Microsoft seems to restore functionality. Will see in 
the following hours. The denial of service remains as a problem on mountd. Will 
get a spare pc asap and check ktrace.

https://support.microsoft.com/en-us/help/4088776/windows-10-update-kb4088776

Re: NFS keeps crashing

2018-04-22 Thread Roderick



On Sun, 22 Apr 2018, Rupert Gallagher wrote:


Bloatware is a luxury I cannot afford on embedded systems with limited
resources where every KB and CPU cycle is accounted for. I would rather
submit my recipe for a proper samba source configuration and have the
maintainer do the compiling of a flavored version, but I already had
negative feedback. The maintainer is dogmatic on having an obese package
instead of a lean one that delivers the same functionality without the
extra fat.


It would be nice to have meager packages, it is nice not to have to
compile and have everything served as package.

But speacially if you are dealing with embedded systems,
it is better you compile things yourself. You can use the packages
not for installing, but for inspecting the patches.

Respecting NFS: I had long ago compatibility problems between
OpenBSD and FreeBSD: it worked at the beginning, but was not reliable,
it hang when transfering (copying) big files. I do not remember
details anymore, where the server and where the client, configuration.

Rodrigo.

Re: NFS keeps crashing

2018-04-22 Thread Mihai Popescu

For the OP with NFS problems: I think it is better to pay for
consultancy and stop talking to yourself on misc@.

Re: NFS keeps crashing

2018-04-22 Thread lists

Sun, 22 Apr 2018 03:30:50 -0400 Rupert Gallagher <r...@protonmail.com>
> Read again, you will find everything you need to reproduce the problem.

Rupert, YOU have problems reproducing - PEBKAC your end.  NFS works here.

Re: NFS keeps crashing

2018-04-22 Thread Rupert Gallagher

On Sun, Apr 22, 2018 at 08:32, Otto Moerbeek  wrote:

> We have gone through this before. Some packages need some libraries that are 
> distributed as part of the base X install. There is no harm in that. You do 
> not need to install the server part of X of that makes you feel better. -Otto

Bloatware is a luxury I cannot afford on embedded systems with limited 
resources where every KB and CPU cycle is accounted for. I would rather submit 
my recipe for a proper samba source configuration and have the maintainer do 
the compiling of a flavored version, but I already had negative feedback. The 
maintainer is dogmatic on having an obese package instead of a lean one that 
delivers the same functionality without the extra fat.

Re: NFS keeps crashing

2018-04-22 Thread Rupert Gallagher

On Sun, Apr 22, 2018 at 08:17, Otto Moerbeek  wrote:

> In that case ktracing mountd might help (as well as (packet captures) to see 
> what is going on.

Will get back with the results.

Re: NFS keeps crashing

2018-04-22 Thread Rupert Gallagher

On Sun, Apr 22, 2018 at 05:27, <li...@wrant.com> wrote:

>  You seem to have some problems understanding feedback, here is some help. 
> Cut the crap already. How about dmesg first, then proper problem report?  
> @protonmail.com>

@protonmail.com>> Give clear instructions on how to reproduce the problem.

Read again, you will find everything you need to reproduce the problem. Since 
you are a bit slow, here is how to do it.

1. Open up you obsd console.
2. Kill mountd.
3. Run "doas mountd -d"
4. Open up your updated windows 10
5. Mount a NFS share
6. See that mountd -d crashes without warnings or errors

Got it? Now you can do your thing.

Re: NFS keeps crashing

2018-04-22 Thread Otto Moerbeek

On Sat, Apr 21, 2018 at 07:33:06PM -0400, Rupert Gallagher wrote:

> On Sat, Apr 21, 2018 at 17:38, IL Ka <kazakevichi...@gmail.com> wrote:
> 
> > I belive NFS is rarely used nowadays, especially with Windows clients. 
> > People use samba/smb to connect *nix to Windows in most cases. Samba should 
> > be pretty stable because OS X uses it to coexist with MS oses.
> 
> I use it on osx: it is a crippled version of the original that causes endless 
> problems with file permissions. Rock solid for the rest.
> 
> I would use samba on obsd, but its package requires x11, believe it or not. I 
> mentioned the problem in misc@ and received insults by someone occlusive and 
> dogmatic, so I will not raise the problem again. I am compiling a proper 
> version, but it will take days on the given hardware...

We have gone through this before. Some packages need some libraries
that are distributed as part of the base X install.  There is no harm
in that. You do not need to install the server part of X of that makes
you feel better.

-Otto

Re: NFS keeps crashing

2018-04-22 Thread Otto Moerbeek

On Sat, Apr 21, 2018 at 07:20:18PM -0400, Rupert Gallagher wrote:

> On Sat, Apr 21, 2018 at 19:58, Otto Moerbeek <o...@drijf.net> wrote:
> 
> > What do you mean by "the server crashes"? Does the complete OS freeze? Or 
> > is the OS still working apart from NFS? Did one of te NFS related daemons 
> > (nfsd, mountd, portmap) die?
> 
> I mean that the mountd server crashed.
> I had "doas mountd -d" up and was reading its output. When it crashed it just 
> returned the shell prompt. No warning, no errors. I have to debug a server in 
> debug mode that does not bother leaving debug information...

In that case ktracing mountd might help (as well as (packet
captures) to see what is going on.

-Otto

Re: NFS keeps crashing

2018-04-21 Thread lists

Sat, 21 Apr 2018 19:25:13 -0400 Rupert Gallagher 
> Nonsense.

Hi Rupert,

You seem to have some problems understanding feedback, here is some help.
Cut the crap already.  How about dmesg first, then proper problem report?

Kind regards,
Anton Lazarov

Comfortably Dumb (the misc song):
http://www.openbsd.org/lyrics.html#60d

"Relax.
The list needs a dmesg first.
Just the basic facts
Stop whining between your blurts."

OpenBSD Problem Reports:
https://www.openbsd.org/report.html

"Always provide as much information as possible.

Try to pinpoint the exact problem.

Give clear instructions on how to reproduce the problem.

Try to describe it with as much accuracy and non-confusing terminology
as possible, especially if it is not easy to reproduce.

Describing problems by saying "it crashes" or "I get strange interrupt
issues on this one box that I built" are of no use.

Communicate with others (on the mailing lists or any other forum where
knowledgeable users congregate) to confirm that the problem is new and
preferably repeatable.

Please try to make sure it is not a local problem created by using
broken or unsupported hardware, or by using unsupported build options
or software."

OpenBSD Mailing Lists:
https://www.openbsd.org/mail.html

"Stay on topic:
Please keep the subject of the post relevant to users of OpenBSD.

Include important information:
Don't waste everyone's time with a hopelessly incomplete question.

No one other than you has the information needed to resolve your
problem, it is better to provide more information than needed than not
enough detail.

All questions should include at least the version of OpenBSD.

Any hardware-related questions should mention the platform (i386,
amd64, etc.) and provide a full dmesg(8).

Hardware model numbers, unfortunately, don't indicate much about the
actual content of a particular machine or accessory, and are useless to
anyone who doesn't have that exact machine sitting where they can
easily recognize it.

The dmesg(8) output tells us exactly what is IN your machine, not what
stickers are on the outside."

sendbug(1) - report a bug in OpenBSD:
https://man.openbsd.org/sendbug

Re: NFS keeps crashing

2018-04-21 Thread IL Ka

> I use it on osx: it is a crippled version of the original that causes
endless problems with file permissions. Rock solid for the rest.
File permissions are always hard to maintain between Windows and *nix,
because of Windows ACL's and posix permissions differences.

One person on this list mentioned that SMB is slower than NFS. I googled
for that and it seems to be true,
but article was about SMB2. It could be that SMB3 (supported by Win10) is
slightly faster, need to check.
See "SMB3 Multi-Channel"  experimental feature: https://www.samba.org/samba/
history/samba-4.4.0.html

>  but its package requires x11,

I do not see any X11 here, but some dependencies are strange:
xx4$ pkg_info -f samba | grep "@depend"
@depend converters/libiconv:libiconv-*:libiconv-1.14p3
@depend databases/openldap,-main:openldap-client-*:openldap-client-2.4.45p4
@depend databases/tdb:tdb->=1.3.14:tdb-1.3.15
@depend devel/gettext:gettext-*:gettext-0.19.8.1p1
@depend devel/jansson:jansson-*:jansson-2.10
@depend devel/libexecinfo:libexecinfo-*:libexecinfo-0.3p0v0
@depend devel/libtalloc:libtalloc->=2.1.9:libtalloc-2.1.11
@depend net/avahi,-main:avahi-*:avahi-0.7p1
@depend net/py-dnspython:py-dnspython-*:py-dnspython-1.15.0
@depend net/samba,-ldb:ldb->=1.2.3:ldb-1.2.3p0
@depend net/samba,-util:samba-util->=4.7.6:samba-util-4.7.6
@depend print/cups,-libs:cups-libs-*:cups-libs-2.2.6
@depend security/gnutls:gnutls-*:gnutls-3.5.18
@depend security/openpam:openpam-*:openpam-20141014
@depend sysutils/gamin,-main:gamin-*:gamin-0.1.10p23

Why do I need OpenLDAP if I do not have domain?
What for should I use CUPS if I do not use Samba printing server?
Same with avahi which is zeroconf

Samba does not have any FLAVORs, unfortunatelly.

Probably, you could contact port maintainers and ask them for permission
to create several flavors of samba if you have time to create patch.

Re: NFS keeps crashing

On Sat, Apr 21, 2018 at 17:38, IL Ka <kazakevichi...@gmail.com> wrote:

> I belive NFS is rarely used nowadays, especially with Windows clients. People 
> use samba/smb to connect *nix to Windows in most cases. Samba should be 
> pretty stable because OS X uses it to coexist with MS oses.

I use it on osx: it is a crippled version of the original that causes endless 
problems with file permissions. Rock solid for the rest.

I would use samba on obsd, but its package requires x11, believe it or not. I 
mentioned the problem in misc@ and received insults by someone occlusive and 
dogmatic, so I will not raise the problem again. I am compiling a proper 
version, but it will take days on the given hardware...

Re: NFS keeps crashing

On Sat, Apr 21, 2018 at 19:58, Otto Moerbeek <o...@drijf.net> wrote:

> What do you mean by "the server crashes"? Does the complete OS freeze? Or is 
> the OS still working apart from NFS? Did one of te NFS related daemons (nfsd, 
> mountd, portmap) die?

I mean that the mountd server crashed.
I had "doas mountd -d" up and was reading its output. When it crashed it just 
returned the shell prompt. No warning, no errors. I have to debug a server in 
debug mode that does not bother leaving debug information...

Re: NFS keeps crashing

On Sat, Apr 21, 2018 at 18:09,  wrote:

> Hi Ilya, If it was humble you'd keep it to yourself and not bother 
> contemplating, or otherwise using the mailing list to think out loud what 
> need not say. Kind regards, Anton Lazarov

Nonsense. Is a Turing award lecture worth publishing? It certainly is. So read 
this one: "The humble programmer" by Dijksta.

Re: NFS keeps crashing

2018-04-21 Thread Otto Moerbeek

On Sat, Apr 21, 2018 at 10:09:38AM +0100, Stuart Henderson wrote:

> > On Sat, Apr 21, 2018, 1:24 AM Rupert Gallagher <r...@protonmail.com> wrote:
> > 
> > > This is what I observed on a controlled environment of three "windows 10
> > > pro" 1709 clients.
> > >
> > > The obsd nfs server had a single share:
> > >
> > > /path/to/folder -network 192.168.1 -mask 255.255.255.0
> > >
> > > When mounting a share for the first time, Windows allows browsing the
> > > network to find the resource. This is what happens:
> > >
> > > 1. The client asks for the list of nfs resources;
> > > 2. the server shows a stream of accepted mounts, no warnings, no errors;
> > > 3. while 2 happens, the client shows a warning that the server is not
> > > responding;
> > > 4. when eventually the client returns the list of nfs folders, the server
> > > crashes.
> > >
> > > The above occurs systematically. Restarting the server and repeating the
> > > client steps lead to a new server crash. The only way to mount the share 
> > > is
> > > to type in the path, without browsing.
> > >
> > > When the server crashes, the debug shows no warnings and no errors.
> > >
> > > The problem did not occur with W10Pro 1703. However, the server should not
> > > crash, and if it does, it should report useful diagnostics.
> 
> Packet captures from broken and working clients would be a good start
> to figuring out what's going on.

What do you mean by "the server crashes"? Does the complete OS freeze?
Or is the OS still working apart from NFS?  Did one of te NFS related
daemons (nfsd, mountd, portmap) die?

-Otto

Re: NFS keeps crashing

2018-04-21 Thread lists

Sat, 21 Apr 2018 18:38:11 +0300 IL Ka <kazakevichi...@gmail.com>
> >  I mean sponsors who pay for projects and compatibility updates. I also  
> mean broader user base.
> 
> IMHO:
> To increase userbase and attract
> serious sponsors attention, OpenBSD needs to be converted
> to "friendly-for-non-IT-people" OS like Ubuntu.

Hi Ilya,

If it was humble you'd keep it to yourself and not bother contemplating,
or otherwise using the mailing list to think out loud what need not say.

Kind regards,
Anton Lazarov

> Do you want to have polkit and Systemd in base system?:)
> 
> It seems than in obsd you should either investigate issue
> by reading source code and using debugger or trace,
> or write to bugs@ and wait for developer answer.
> 
> I belive NFS is rarely used nowadays, especially with Windows clients.
> People use samba/smb to connect *nix to Windows in most cases.
> Samba should be pretty stable because OS X uses it to coexist with MS oses.

Re: NFS keeps crashing

2018-04-21 Thread Consus

On 18:38 Sat 21 Apr, IL Ka wrote:
> >  I mean sponsors who pay for projects and compatibility updates. I also
> > mean broader user base.
> 
> I belive NFS is rarely used nowadays, especially with Windows clients.
> People use samba/smb to connect *nix to Windows in most cases.
> Samba should be pretty stable because OS X uses it to coexist with MS oses.

Samba is also very very slow if you consider 10G/100G networks. Support
for Multi-Channel is still marked as experimental and may kill your data.

Re: NFS keeps crashing

2018-04-21 Thread IL Ka

>  I mean sponsors who pay for projects and compatibility updates. I also
mean broader user base.

IMHO:
To increase userbase and attract
serious sponsors attention, OpenBSD needs to be converted
to "friendly-for-non-IT-people" OS like Ubuntu.
Do you want to have polkit and Systemd in base system?:)

It seems than in obsd you should either investigate issue
by reading source code and using debugger or trace,
or write to bugs@ and wait for developer answer.

I belive NFS is rarely used nowadays, especially with Windows clients.
People use samba/smb to connect *nix to Windows in most cases.
Samba should be pretty stable because OS X uses it to coexist with MS oses.

Re: NFS keeps crashing

I mean sponsors who pay for projects and compatibility updates. I also mean 
broader user base.

Re: NFS keeps crashing

2018-04-21 Thread Daniel Bolgheroni

On Sat, Apr 21, 2018 at 10:38:48AM +, Rupert Gallagher wrote:
> What I do not like of obsd is the negative energy of its community. We
> all have a sympatic gene and tend to mirror the social environment. We
> should be mindful of it, and try to stay positive. Another thing I do
> not like is the absence of industrial support. I mean, am I the only
> one on obsd nfs with windows 10 clients? It feels too much pioneering
> around here...

On how to report properly, please refer to:

https://www.openbsd.org/report.html

The project website has a list of vendors offering commercial,
"industrial" support.  Please refer to:

https://www.openbsd.org/support.html

-- 
db

Re: NFS keeps crashing

2018-04-21 Thread lists

Sat, 21 Apr 2018 06:31:33 + MB <iam...@gmail.com>
> Why are you using ooenbsd for anything but a firewall.  Even then its
> lagging way behind unless you deploying in a dentist office. Openbsd sucks
> at pretty much everything else.  Sorry I come from corporate real world
> experience not Soho stuff.  Use Linux.

Hi random web-mail person,

You May want to understand there could be different goals and objectives.
You Could show some grace and leave the fellow progress their own thread.
You Should not tell us all what to use.  Relay the comments to your boss.

Kind regards,
Anton Lazarov

> On Sat, Apr 21, 2018, 1:24 AM Rupert Gallagher <r...@protonmail.com> wrote:
> 
> > This is what I observed on a controlled environment of three "windows 10
> > pro" 1709 clients.
> >
> > The obsd nfs server had a single share:
> >
> > /path/to/folder -network 192.168.1 -mask 255.255.255.0
> >
> > When mounting a share for the first time, Windows allows browsing the
> > network to find the resource. This is what happens:
> >
> > 1. The client asks for the list of nfs resources;
> > 2. the server shows a stream of accepted mounts, no warnings, no errors;
> > 3. while 2 happens, the client shows a warning that the server is not
> > responding;
> > 4. when eventually the client returns the list of nfs folders, the server
> > crashes.
> >
> > The above occurs systematically. Restarting the server and repeating the
> > client steps lead to a new server crash. The only way to mount the share is
> > to type in the path, without browsing.
> >
> > When the server crashes, the debug shows no warnings and no errors.
> >
> > The problem did not occur with W10Pro 1703. However, the server should not
> > crash, and if it does, it should report useful diagnostics.
> >
> > R
> >

Re: NFS keeps crashing