[OpenIndiana-discuss] SMB NFS not sure where to go

Michelle michelle at msknight.com
Mon Aug 7 16:07:14 UTC 2023


After that updating, I now have a problem copying files to and from the
share and the client.

Firstly... using command line to go onto the share and use Nano to edit
a text file... no problem.

Using Nano to browse to the mounted share, open in Text Editor, edit
and then save... it gives "resource unavailable."

When using Nemo to copy from the share to the local Linux machine, it
copies the small test file successfully, but hangs on the "progress
bar" which never closes. I have to kill Nemo.

When using Nemo to copy from the local Linux machine to the server
share, it copies up the file using the temp name, but can't actually
replace the file.

If I manually delete the file from the server, and then copy the file
up to the share... it works.

All the time, this...
Aug  7 16:54:16 main-desktop kernel: [  772.668870] CIFS: VFS:
\\192.168.0.2 RFC 1002 unknown response type 0xfe
Aug  7 16:54:16 main-desktop kernel: [  772.668915] CIFS: VFS: Push
locks rc = -22
... is prevalent in the client side syslog when this is happening.

There was a previous post in mid 2022 about a bug on Linux and that the
workaround was to force vers=2.0 but I've tried that and there's no
change in the behaviour.

>From what I've read, my nbmand property is best set to off, which is
what it is. Or do I have that wrong?

I'm now at a loss as to where to continue looking.

OpenIndiana Hipster 2023.05 (powered by illumos)

Distributor ID:	Linuxmint
Description:	Linux Mint 21
Release:	21
Codename:	vanessa

mount from util-linux 2.37.2 (libmount 2.37.2: selinux, smack, btrfs,
verity, namespaces, assert, debug)



On Mon, 2023-08-07 at 10:08 +0100, Michelle wrote:
> nbmand is off on both servers.
> 
> Michelle.
> 
> On Mon, 2023-08-07 at 11:54 +0300, Toomas Soome wrote:
> > 
> > 
> > > On 7. Aug 2023, at 11:38, Michelle <michelle at msknight.com> wrote:
> > > 
> > > I did a quick test after updating and rebooting both servers.
> > > 
> > > Copying files from one of the servers (panther - 0.4) to another
> > > server
> > > (jaguar - 0.2) via the Linux client ... resulted in the following
> > > in
> > > the log on the client, however, there was nothing in the syslog
> > > on
> > > either of the servers.
> > > 
> > > There does seem to be a mention of a patch in Linux SMB as of
> > > late
> > > June
> > > this year, but having said that, there seem to be a number of
> > > patches
> > > throughout the years regarding this, but I'm unable to get a grip
> > > with
> > > it.
> > > 
> > > Aug  7 09:28:35 main-desktop systemd[1109]: Starting GNOME
> > > Terminal
> > > Server...
> > > Aug  7 09:28:35 main-desktop dbus-daemon[1136]: [session uid=1101
> > > pid=1136] Successfully activated service 'org.gnome.Terminal'
> > > Aug  7 09:28:35 main-desktop systemd[1109]: Started GNOME
> > > Terminal
> > > Server.
> > > Aug  7 09:28:35 main-desktop systemd[1109]: Started VTE child
> > > process
> > > 1644922 launched by gnome-terminal-server process 1644897.
> > > Aug  7 09:30:01 main-desktop CRON[1645001]: (root) CMD ([ -x
> > > /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then
> > > /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
> > > Aug  7 09:30:10 main-desktop kernel: [2945189.248744] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > 
> > I’m not really sure where is this coming from, probably want to
> > check
> > netowk packet with tshark/wireshark.
> > 
> > > Aug  7 09:30:10 main-desktop kernel: [2945189.248788] CIFS: VFS:
> > > Push
> > > locks rc = -22
> > 
> > Do you have zfs nbmand property set on?
> > 
> > rgds,
> > toomas
> > 
> > > Aug  7 09:30:20 main-desktop kernel: [2945198.711222] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:30:25 main-desktop kernel: [2945204.406488] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:30:28 main-desktop kernel: [2945206.802407] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:30:30 main-desktop kernel: [2945208.649958] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:30:32 main-desktop kernel: [2945210.907929] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:30:33 main-desktop kernel: [2945212.056828] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:30:36 main-desktop kernel: [2945214.981583] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:30:37 main-desktop kernel: [2945216.163547] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:30:37 main-desktop systemd[1109]: Started VTE child
> > > process
> > > 1645538 launched by gnome-terminal-server process 1644897.
> > > Aug  7 09:30:39 main-desktop kernel: [2945218.019954] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:30:41 main-desktop kernel: [2945219.860681] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:30:41 main-desktop kernel: [2945220.282600] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:30:41 main-desktop kernel: [2945220.282649] CIFS: VFS:
> > > Push
> > > locks rc = -22
> > > Aug  7 09:30:44 main-desktop kernel: [2945222.937137] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:30:44 main-desktop kernel: [2945222.937168] CIFS: VFS:
> > > Push
> > > locks rc = -22
> > > Aug  7 09:30:48 main-desktop kernel: [2945227.269625] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:30:54 main-desktop kernel: [2945233.354499] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:30:57 main-desktop kernel: [2945235.676076] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:31:02 main-desktop kernel: [2945241.140574] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:31:06 main-desktop kernel: [2945244.760306] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:31:06 main-desktop systemd[1]: Started Run anacron
> > > jobs.
> > > Aug  7 09:31:06 main-desktop anacron[1645804]: Anacron 2.3
> > > started
> > > on
> > > 2023-08-07
> > > Aug  7 09:31:06 main-desktop anacron[1645804]: Normal exit (0
> > > jobs
> > > run)
> > > Aug  7 09:31:06 main-desktop systemd[1]: anacron.service:
> > > Deactivated
> > > successfully.
> > > Aug  7 09:31:08 main-desktop kernel: [2945247.431492] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:31:14 main-desktop kernel: [2945253.154480] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > Aug  7 09:31:14 main-desktop kernel: [2945253.255401] CIFS: VFS:
> > > \\192.168.0.4 RFC 1002 unknown response type 0xfe
> > > e
> > > 
> > > 
> > > On Mon, 2023-08-07 at 11:16 +0300, Toomas Soome wrote:
> > > > 
> > > > 
> > > > > On 7. Aug 2023, at 11:12, Michelle <michelle at msknight.com>
> > > > > wrote:
> > > > > 
> > > > > Hi Toomas,
> > > > > 
> > > > > Thanks for the feedback.
> > > > > 
> > > > > I'll update both servers and run more tests.
> > > > > 
> > > > > Michelle.
> > > > 
> > > > For SMB, uid/gid sync is not important, you will access the
> > > > share
> > > > with authenticated user (or guest).
> > > > 
> > > > With NFS auth sys mechanism, the usernames and uid/gid need to
> > > > match,
> > > > and your nfsv4_domain should match with client system  setting
> > > > (or
> > > > your access will be mapped to user ’nobody’).
> > > > 
> > > > rgds,
> > > > toomas
> > > > 
> > > > > 
> > > > > On Mon, 2023-08-07 at 10:56 +0300, Toomas Soome via
> > > > > openindiana-
> > > > > discuss
> > > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > > On 7. Aug 2023, at 09:21, Michelle
> > > > > > > <michelle at msknight.com>
> > > > > > > wrote:
> > > > > > > 
> > > > > > > OI server is at...
> > > > > > >             OpenIndiana Hipster 2022.10 (powered by
> > > > > > > illumos)
> > > > > > 
> > > > > > 
> > > > > > Please run ‘pkg update’. We have had many updates since
> > > > > > 2022.
> > > > > > 
> > > > > > > 
> > > > > > > Client is Linux Mint...
> > > > > > > Distributor ID: Linuxmint
> > > > > > > Description:    Linux Mint 21
> > > > > > > Release:        21
> > > > > > > Codename:       vanessa
> > > > > > > 
> > > > > > > I'm continuing to have problems with SMB shares. Even
> > > > > > > mounting
> > > > > > > with
> > > > > > > no
> > > > > > > cache...
> > > > > > > sudo mount //192.168.0.2/jaguar /mnt/jaguar -o
> > > > > > > username=michelle,password=password,file_mode=0777,dir_mo
> > > > > > > de
> > > > > > > =077
> > > > > > > 7,ca
> > > > > > > che=
> > > > > > > none
> > > > > > > ...
> > > > > > > //192.168.0.2/jaguar on /mnt/jaguar type cifs
> > > > > > > (rw,relatime,vers=3.0,cache=none,username=michelle,uid=0,
> > > > > > > no
> > > > > > > forc
> > > > > > > euid
> > > > > > > ,gid
> > > > > > > =0,noforcegid,addr=192.168.0.2,file_mode=0777,dir_mode=07
> > > > > > > 77
> > > > > > > ,sof
> > > > > > > t,no
> > > > > > > unix
> > > > > > > ,mapposix,rsize=65536,wsize=65536,bsize=1048576,echo_inte
> > > > > > > rv
> > > > > > > al=6
> > > > > > > 0,ac
> > > > > > > time
> > > > > > > o=1)
> > > > > > > 
> > > > > > > (for info, the UID of michelle is the same on client and
> > > > > > > server)
> > > > > > > ...I'm getting, "resource unavailable," on various read-
> > > > > > > write/rename
> > > > > > > operations including deleting files. Say, sixty files,
> > > > > > > three
> > > > > > > will
> > > > > > > fail
> > > > > > > to delete giving "resource unavailable" and then I have
> > > > > > > to
> > > > > > > delete
> > > > > > > them
> > > > > > > again, and they'll go.
> > > > > > > 
> > > > > > > When the Linux client hits resource unavaialble, there's
> > > > > > > nothing in
> > > > > > > the
> > > > > > > Linux messages and nothing in the OI /var/adm/messages
> > > > > > > either,
> > > > > > > that
> > > > > > > gives a hint of what's going on.
> > > > > > > 
> > > > > > > Having hit a brick wall with CIFS, I'm trying to
> > > > > > > configure
> > > > > > > an
> > > > > > > NFS
> > > > > > > share
> > > > > > > against user rather than machine IP, but I'm getting
> > > > > > > nowhere.
> > > > > > > 
> > > > > > > zfs set sharenfs='rw=.:michelle' panther
> > > > > > 
> > > > > > access list used with rw does not allow to set per user
> > > > > > access,
> > > > > > see
> > > > > > share_nfs(8). It should interpret michelle as hostname, but
> > > > > > I’m
> > > > > > not
> > > > > > sure why it will complain about invalid option below.
> > > > > > 
> > > > > > > cannot set property for 'panther': 'sharenfs' cannot be
> > > > > > > set
> > > > > > > to
> > > > > > > invalid
> > > > > > > options
> > > > > > > 
> > > > > > > I'm tying myself in knots because it seems that there's
> > > > > > > "legacy"
> > > > > > > NFS,
> > > > > > > ZFS NFS with different options/restrictions and I'm not
> > > > > > > sure
> > > > > > > where
> > > > > > > to
> > > > > > > go. If I read correctly, only ZFS NFS is installed by
> > > > > > > "default"
> > > > > > > on
> > > > > > > a
> > > > > > > new OI installation, but I'm not about to start going
> > > > > > > installing
> > > > > > > stuff
> > > > > > > until I have a better idea what I'm doing.
> > > > > > > 
> > > > > > > One reason I set some shares against user permissions is
> > > > > > > to
> > > > > > > protect
> > > > > > > against ransomware. I unmount and re-mount rw when I want
> > > > > > > to
> > > > > > > write
> > > > > > > to
> > > > > > > them, hence pure hostip is a problem for me.
> > > > > > > 
> > > > > > > I don't know where I'm looking for either option.
> > > > > > > 
> > > > > > > Hence the decision to look to NFS (which I've never
> > > > > > > really
> > > > > > > had
> > > > > > > to
> > > > > > > handle before) and I'm hitting trouble there.
> > > > > > > 
> > > > > > > Grateful for thoughts and advice.
> > > > > > > 
> > > > > > > Michelle.
> > > > > > > 
> > > > > > 
> > > > > > zfs sharenfs is just one possible way to implement sharing,
> > > > > > it is
> > > > > > more useful when you are switching pools between different
> > > > > > machines -
> > > > > > so you would get sharing options with pool and do not have
> > > > > > to
> > > > > > transfer /etc/dfs/dfstab between the systems.
> > > > > > 
> > > > > > For debugging, I suggest to test with command ’share’ first
> > > > > > -
> > > > > > make
> > > > > > sure your svc:/network/nfs/server:default is online, then
> > > > > > use
> > > > > > share
> > > > > > command to test the options for specific share. Once happy,
> > > > > > you
> > > > > > can
> > > > > > use either /etc/dfs/dfstab or zfs sharenfs (if you still do
> > > > > > get
> > > > > > the
> > > > > > error, please report the bug in
> > > > > > https://www.illumos.org/issues/
> > > > > > 
> > > > > > And please do keep the system up to date, so we know what
> > > > > > to
> > > > > > expect -
> > > > > > we only do rolling updates and we are not patching old
> > > > > > versions.
> > > > > > 
> > > > > > rgds,
> > > > > > toomas
> > > > > > 
> > > > > > _______________________________________________
> > > > > > openindiana-discuss mailing list
> > > > > > openindiana-discuss at openindiana.org
> > > > > > https://openindiana.org/mailman/listinfo/openindiana-discuss
> > > > > 
> > > > 
> > > 
> > 
> 
> 
> _______________________________________________
> openindiana-discuss mailing list
> openindiana-discuss at openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss




More information about the openindiana-discuss mailing list