[OpenIndiana-discuss] SMB NFS not sure where to go
Toomas Soome
tsoome at me.com
Sun Sep 24 17:45:59 UTC 2023
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=10485
>>>>>>>>>>>>>> 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
More information about the openindiana-discuss
mailing list