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 <miche...@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 <miche...@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 >>>>>>>>>> <miche...@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 >>>>>>>>>>>> <miche...@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 >>>>>>>>>>>>>> <miche...@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@openindiana.org >>>>>>>>>>>>> https://openindiana.org/mailman/listinfo/openindiana-discuss >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> openindiana-discuss mailing list >>>>>>>> openindiana-discuss@openindiana.org >>>>>>>> https://openindiana.org/mailman/listinfo/openindiana-discuss >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> openindiana-discuss mailing list >>>>>>> openindiana-discuss@openindiana.org >>>>>>> https://openindiana.org/mailman/listinfo/openindiana-discuss >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> openindiana-discuss mailing list >>>>>> openindiana-discuss@openindiana.org >>>>>> https://openindiana.org/mailman/listinfo/openindiana-discuss >>>>> >>>> >>>> >>>> _______________________________________________ >>>> openindiana-discuss mailing list >>>> openindiana-discuss@openindiana.org >>>> https://openindiana.org/mailman/listinfo/openindiana-discuss >>> >>> >>> _______________________________________________ >>> openindiana-discuss mailing list >>> openindiana-discuss@openindiana.org >>> https://openindiana.org/mailman/listinfo/openindiana-discuss >> >> >> _______________________________________________ >> openindiana-discuss mailing list >> openindiana-discuss@openindiana.org >> https://openindiana.org/mailman/listinfo/openindiana-discuss > > > _______________________________________________ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > https://openindiana.org/mailman/listinfo/openindiana-discuss _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss