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

Michelle michelle at msknight.com
Mon Aug 7 08:38:00 UTC 2023 

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
Aug  7 09:30:10 main-desktop kernel: [2945189.248788] CIFS: VFS: Push
locks rc = -22
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_mode=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,noforc
> > > > euid
> > > > ,gid
> > > > =0,noforcegid,addr=192.168.0.2,file_mode=0777,dir_mode=0777,sof
> > > > t,no
> > > > unix
> > > > ,mapposix,rsize=65536,wsize=65536,bsize=1048576,echo_interval=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
> > 
>

More information about the openindiana-discuss mailing list