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