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

Toomas Soome tsoome at me.com
Mon Aug 7 08:54:40 UTC 2023



> 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_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