[OpenIndiana-discuss] SMB NFS not sure where to go
Toomas Soome
tsoome at me.com
Sun Sep 24 20:10:18 UTC 2023
Could you paste: 'sharectl get smb’. The ‘unknown response type 0xfe’ is hinting that your client is expecting 0xFF there, and you probably need to set server to default to older SMB version.
rgds,
toomas
> On 24. Sep 2023, at 22:37, Toomas Soome via openindiana-discuss <openindiana-discuss at openindiana.org> wrote:
>
>>
>> On 24. Sep 2023, at 22:34, Michelle <michelle at msknight.com <mailto:michelle at msknight.com>> wrote:
>>
>> I just updated all packages and tested again...
>>
>> Sep 24 20:31:37 mich-desktop kernel: [311047.112078] CIFS: VFS:
>> \\192.168.0.2 RFC 1002 unknown response type 0xfe
>> Sep 24 20:31:37 mich-desktop kernel: [311047.112114] CIFS: VFS: Push
>> locks rc = -22
>>
>> I'm at the end. Nowhere else to go.
>>
>> Michelle.
>
> on OI, what you get from 'pkg update -nv’ ?
>
> rgds,
> toomas
>
>>
>> On Sun, 2023-09-24 at 20:45 +0300, Toomas Soome via openindiana-discuss
>> wrote:
>>> Ou that is sad that hear. Btw, what is the oi build you are using on
>>> that server?
>>>
>>> Sent from my iPhone
>>>
>>>> On 24. Sep 2023, at 17:34, Michelle <michelle at msknight.com> wrote:
>>>>
>>>> I would like to give my thanks to all who have run and maintained
>>>> OpenIndiana for the many years it has been available.
>>>>
>>>> I have been using it since big red took the reins of Sun and
>>>> changed
>>>> the license of Open Solaris, as it gave me access to ZFS; a product
>>>> that has made a big difference in my personal computing life.
>>>>
>>>> The community has been welcoming and patient with me despite my
>>>> novice
>>>> questions. I just wish I had the skills and time to be able to
>>>> contribute to the project but my job, my caring duties and looking
>>>> after a home have left me with little personal time... especially
>>>> in
>>>> this last few years.
>>>>
>>>> Unfortunately this latest issue with CIFS/SMB has been quite a
>>>> disruption and with little way to make progress, I’ve determined
>>>> that
>>>> as the problems have persisted despite changing the client from
>>>> Mint to
>>>> Ubuntu Cinnamon, I now have to change server platform. I’ll be
>>>> replacing my OI servers with Debian over the coming weeks.
>>>>
>>>> Thank you all for your patience and help over the years.
>>>>
>>>> Michelle.
>>>>
>>>>> On Tue, 2023-09-19 at 20:54 +0100, Michelle wrote:
>>>>> OK, I've now upgraded the client to Ubuntu Cinnamon 22.04
>>>>>
>>>>> Accessing the text file on the OI share via BlueFish this time,
>>>>> and
>>>>> making changes and saving, I get (in syslog)...
>>>>>
>>>>> Sep 19 20:49:47 mich-desktop kernel: [13839.060593] CIFS: VFS:
>>>>> \\192.168.0.2 RFC 1002 unknown response type 0xfe
>>>>> Sep 19 20:49:47 mich-desktop kernel: [13839.060714] CIFS: VFS:
>>>>> Push
>>>>> locks rc = -22
>>>>>
>>>>> Same behaviour as before when using xed on Mint. If I delete and
>>>>> then
>>>>> save, it works. And if I attempt to rename a file that's in use
>>>>> (eg.
>>>>> a
>>>>> video) then I get resource unavailable.
>>>>>
>>>>> I have no realistic option now other than to conclude that it's
>>>>> the
>>>>> OpenIndiana side of things.
>>>>>
>>>>> I'd be grateful for guidance on whatever I need to file a bug
>>>>> report
>>>>> please.
>>>>>
>>>>>
>>>>>
>>>>>> On Mon, 2023-08-07 at 22:54 +0100, Michelle wrote:
>>>>>> Apparmor is, indeed running, so I created a profile and put it
>>>>>> to
>>>>>> complain mode... noting that Libre Office is also in complain
>>>>>> mode
>>>>>> already.
>>>>>>
>>>>>> However, xed still fails with the same issue. It is,
>>>>>> apparently,
>>>>>> writing a temporary file and presumably failing... the same way
>>>>>> that
>>>>>> copying a file from the local machine to the share is
>>>>>> failing...
>>>>>>
>>>>>> ... copying the file to a temporary .gooutputstream file but
>>>>>> then
>>>>>> somehow failing to delete the file that is about to be
>>>>>> replaced.
>>>>>>
>>>>>> Michelle.
>>>>>>
>>>>>> On Mon, 2023-08-07 at 22:24 +0100, Michelle wrote:
>>>>>>> I'm starting to believe that upgrading Linux has installed
>>>>>>> apparmor
>>>>>>> ...
>>>>>>> and it's likely that apparmor is now getting in the way of
>>>>>>> various
>>>>>>> applications.
>>>>>>>
>>>>>>> I hate apparmor. I mean, I understand why it's there and the
>>>>>>> theory
>>>>>>> of
>>>>>>> what it does, but I've never had much luck controlling it.
>>>>>>>
>>>>>>> I need to read up and find how to tell apparmor to stop
>>>>>>> controlling
>>>>>>> xed
>>>>>>> and nemo, and see if that works.
>>>>>>>
>>>>>>> Michelle.
>>>>>>>
>>>>>>> On Mon, 2023-08-07 at 22:20 +0100, Michelle wrote:
>>>>>>>> I've translated up to the same cifs-utils version up to
>>>>>>>> Mint
>>>>>>>> 21.2
>>>>>>>> Victoria kernel 6.2.0-26 which is as far as I can go. I
>>>>>>>> have
>>>>>>>> also
>>>>>>>> turned on nbmand on, on the servers.
>>>>>>>>
>>>>>>>> Oddly enough, Libre Office Writer can open and save the
>>>>>>>> file on
>>>>>>>> the
>>>>>>>> share. "Text Editor" otherwise known as xed 3.4.3 ...
>>>>>>>> can't. It
>>>>>>>> reports
>>>>>>>> the resource unavailable error.
>>>>>>>>
>>>>>>>> Copying a file from network share to local machine using
>>>>>>>> Nemo
>>>>>>>> 5.8.4
>>>>>>>> successfully copies the file, but the progress bar stops at
>>>>>>>> 50%.
>>>>>>>> I've
>>>>>>>> still got the reports of the push locks and ...
>>>>>>>> Aug 7 22:14:23 main-desktop kernel: [ 5181.959778] CIFS:
>>>>>>>> VFS:
>>>>>>>> \\192.168.0.4 RFC 1002 unknown response type 0xfe
>>>>>>>> Aug 7 22:14:23 main-desktop kernel: [ 5181.959819] CIFS:
>>>>>>>> VFS:
>>>>>>>> Push
>>>>>>>> locks rc = -22
>>>>>>>> ... on the client.
>>>>>>>>
>>>>>>>> Copying from the client to the server using the same
>>>>>>>> version of
>>>>>>>> Nemo,
>>>>>>>> results in failure to overwrite the file with...
>>>>>>>> Aug 7 22:17:09 main-desktop kernel: [ 5348.165575] CIFS:
>>>>>>>> VFS:
>>>>>>>> \\192.168.0.2 RFC 1002 unknown response type 0xfe
>>>>>>>> Aug 7 22:17:09 main-desktop kernel: [ 5348.165613] CIFS:
>>>>>>>> VFS:
>>>>>>>> Push
>>>>>>>> locks rc = -22
>>>>>>>> ... although deleting the file and then copying it up to
>>>>>>>> the
>>>>>>>> share,
>>>>>>>> works. Again, it looks like there's a problem deleting the
>>>>>>>> original
>>>>>>>> file in order to rename the temporary file to the target
>>>>>>>> file
>>>>>>>> name.
>>>>>>>>
>>>>>>>> Michelle.
>>>>>>>>
>>>>>>>> On Mon, 2023-08-07 at 19:35 +0300, Toomas Soome via
>>>>>>>> openindiana-
>>>>>>>> discuss
>>>>>>>> wrote:
>>>>>>>>> hi!
>>>>>>>>>
>>>>>>>>> I just did test with ubuntu 22.04.01, cifs-utils:
>>>>>>>>> 2:6.14-1ubuntu0.1
>>>>>>>>>
>>>>>>>>> And seems to behave as expected. My share has nbmand=on,
>>>>>>>>> however.
>>>>>>>>>
>>>>>>>>> rgds,
>>>>>>>>> toomas
>>>>>>>>>
>>>>>>>>>> On 7. Aug 2023, at 19:07, Michelle
>>>>>>>>>> <michelle at msknight.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> =0
>>>>>>>>>>>>>>>>> 77
>>>>>>>>>>>>>>>>> 7,
>>>>>>>>>>>>>>>>> di
>>>>>>>>>>>>>>>>> r_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
>>>>>>>>>>>>>>>>> =mic
>>>>>>>>>>>>>>>>> he
>>>>>>>>>>>>>>>>> ll
>>>>>>>>>>>>>>>>> e,
>>>>>>>>>>>>>>>>> ui
>>>>>>>>>>>>>>>>> d=0,
>>>>>>>>>>>>>>>>> no
>>>>>>>>>>>>>>>>> forc
>>>>>>>>>>>>>>>>> euid
>>>>>>>>>>>>>>>>> ,gid
>>>>>>>>>>>>>>>>> =0,noforcegid,addr=192.168.0.2,file_mode=
>>>>>>>>>>>>>>>>> 0777
>>>>>>>>>>>>>>>>> ,d
>>>>>>>>>>>>>>>>> ir
>>>>>>>>>>>>>>>>> _m
>>>>>>>>>>>>>>>>> od
>>>>>>>>>>>>>>>>> e=07
>>>>>>>>>>>>>>>>> 77
>>>>>>>>>>>>>>>>> ,sof
>>>>>>>>>>>>>>>>> t,no
>>>>>>>>>>>>>>>>> unix
>>>>>>>>>>>>>>>>> ,mapposix,rsize=65536,wsize=65536,bsize=1
>>>>>>>>>>>>>>>>> 0485
>>>>>>>>>>>>>>>>> 76
>>>>>>>>>>>>>>>>> ,e
>>>>>>>>>>>>>>>>> ch
>>>>>>>>>>>>>>>>> o_
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> openindiana-discuss mailing list
> openindiana-discuss at openindiana.org <mailto:openindiana-discuss at openindiana.org>
> https://openindiana.org/mailman/listinfo/openindiana-discuss
More information about the openindiana-discuss
mailing list