macOS Big Sur Beta 6 - unRAID 6.8.3 SMB Shares Potentially Broken


xaositek

Recommended Posts

Just now, ghost82 said:

Thank you, I can't see to track down my issue.

I probably need a clean install, I will see tomorrow.

Is the issue you can't see the server or connect to the server? Can you go to the Finder, click on the "Go" menu, then connect to server. Type on "smb://192.168.1.250" (or whatever the IP of your unRAID server is) and see if it connects?

  • Like 1
Link to comment
2 minutes ago, xaositek said:

Is the issue you can't see the server or connect to the server? Can you go to the Finder, click on the "Go" menu, then connect to server. Type on "smb://192.168.1.250" (or whatever the IP of your unRAID server is) and see if it connects?

Yes, I can't see the server in "network" and also can't connect directly as you described.

What is strange is that Catalina works, so the smb server on the host works.

Edited by ghost82
Link to comment
14 minutes ago, ghost82 said:

Yes, I edited my post above, smb server seems to not have issues with my other vm.

 

and strange thing (part 2) is that from big sur terminal "smbutil view //user:[email protected]" returns my shares...

When you connect manually to your server, what error do you get? Can you screenshot and attach? Also open the Console application and see if you can pull any related logs.

Link to comment

Oh my god thanks I'm not alone :P

 

I come to the end that the smb driver is buggy.

I installed a clean version of Big Sur, smb server shows, it connects, for some files (drag and drop) it gives error -8084.

I tried also to zeroes the free space on the disk where the share is, as suggested somewhere, no change.

When I copy from terminal I get a kernel panic, for example:

panic(cpu 5 caller 0xffffff80080bf424): "Zone element 0xffffff9379602a00 was modified after free for zone kext.kalloc.512: " "Expected element to be cleared"@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-7195.50.7/osfmk/kern/zalloc.c:1968
Backtrace (CPU 5), Frame : Return Address
0xffffffc0f0de2b20 : 0xffffff80078bc66d mach_kernel : _handle_debugger_trap + 0x3dd
0xffffffc0f0de2b70 : 0xffffff80079ff073 mach_kernel : _kdp_i386_trap + 0x143
0xffffffc0f0de2bb0 : 0xffffff80079ef6aa mach_kernel : _kernel_trap + 0x55a
0xffffffc0f0de2c00 : 0xffffff800b63a924 as.vit9696.VirtualSMC : __ZN18VirtualSMCProvider10kernelTrapI22x86_saved_state_1010_tEEvPT_Pm + 0x454
0xffffffc0f0de2c80 : 0xffffff8007861a2f mach_kernel : _return_from_trap + 0xff
0xffffffc0f0de2ca0 : 0xffffff80078bbf0d mach_kernel : _DebuggerTrapWithState + 0xad
0xffffffc0f0de2dc0 : 0xffffff80078bc1f8 mach_kernel : _panic_trap_to_debugger + 0x268
0xffffffc0f0de2e30 : 0xffffff80080bee1a mach_kernel : _panic + 0x54
0xffffffc0f0de2ea0 : 0xffffff80080bf424 mach_kernel : _kheap_temp_leak_panic + 0x4fa
0xffffffc0f0de2eb0 : 0xffffff8007917fca mach_kernel : _zone_require + 0x12a
0xffffffc0f0de2ee0 : 0xffffff80079191f2 mach_kernel : _zdestroy + 0x1062
0xffffffc0f0de2f60 : 0xffffff80078cabf4 mach_kernel : _task_get_exception_ports_from_user + 0x554
0xffffffc0f0de2fb0 : 0xffffff8007e44e53 mach_kernel : __MALLOC + 0x33
0xffffffc0f0de2fd0 : 0xffffff7fa7cf92ad com.apple.filesystems.smbfs : _smb2_rq_alloc + 0x32
0xffffffc0f0de3060 : 0xffffff7fa7d02345 com.apple.filesystems.smbfs : _smb2_smb_read_one + 0x71
0xffffffc0f0de3100 : 0xffffff7fa7d034fe com.apple.filesystems.smbfs : _smb2_smb_read_write_fill + 0x10f
0xffffffc0f0de3160 : 0xffffff7fa7d014f9 com.apple.filesystems.smbfs : _smb2_smb_read_write_async + 0x5d9
0xffffffc0f0de3780 : 0xffffff7fa7d00e94 com.apple.filesystems.smbfs : _smb2_smb_read + 0xa1
0xffffffc0f0de37d0 : 0xffffff7fa7d0268b com.apple.filesystems.smbfs : _smb_smb_read + 0x7e
0xffffffc0f0de3810 : 0xffffff7fa7cda514 com.apple.filesystems.smbfs : _smbfs_vnop_strategy + 0x262
0xffffffc0f0de38b0 : 0xffffff8007b2e485 mach_kernel : _cluster_pageout_ext + 0xe65
0xffffffc0f0de39e0 : 0xffffff8007b3673d mach_kernel : _advisory_read_ext + 0x32d
0xffffffc0f0de3aa0 : 0xffffff8007b36a13 mach_kernel : _advisory_read_ext + 0x603
0xffffffc0f0de3b10 : 0xffffff8007b3398f mach_kernel : _cluster_read_ext + 0x71f
0xffffffc0f0de3cd0 : 0xffffff8007b333fa mach_kernel : _cluster_read_ext + 0x18a
0xffffffc0f0de3d30 : 0xffffff7fa7cd57c0 com.apple.filesystems.smbfs : _smbfs_vnop_read + 0x208
0xffffffc0f0de3d90 : 0xffffff8007b6e424 mach_kernel : _utf8_normalizeOptCaseFoldAndMatchSubstring + 0x774
0xffffffc0f0de3e30 : 0xffffff8007e775a8 mach_kernel : _read_nocancel + 0x328
0xffffffc0f0de3ee0 : 0xffffff8007e77335 mach_kernel : _read_nocancel + 0xb5
0xffffffc0f0de3f40 : 0xffffff8007f69ceb mach_kernel : _unix_syscall64 + 0x27b
0xffffffc0f0de3fa0 : 0xffffff80078621f6 mach_kernel : _hndl_unix_scall64 + 0x16
      Kernel Extensions in backtrace:
         as.vit9696.VirtualSMC(1.1.9)[E86C73CD-1B17-351E-94D1-B45456FDA448]@0xffffff800b62b000->0xffffff800b651fff
            dependency: as.vit9696.Lilu(1.5.0)[6C645CAF-FB0C-3253-AD21-63A6659F9EB7]@0xffffff800b5a5000->0xffffff800b628fff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[65A1D60D-F9AF-37E7-B854-4127FBB3172A]@0xffffff8009cd2000->0xffffff8009cd3fff
         com.apple.filesystems.smbfs(3.4.1)[D17D4216-863F-39C0-9276-D10EB67EDC39]@0xffffff7fa7cb5000->0xffffff7fa7d1efff
            dependency: com.apple.kec.corecrypto(1.0)[42140686-EB80-38BB-8CDD-E6CFECB83A5A]@0xffffff800a9fc000->0xffffff800aa88fff
            dependency: com.apple.kext.triggers(1.0)[9FD0EB89-CC8A-3913-8115-21C72665246F]@0xffffff7fa7d23000->0xffffff7fa7d25fff

Process name corresponding to current thread: cp
Boot args: -v keepsyms=1 debug=0x100 chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:
20B29

Kernel version:
Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:11 PDT 2020; root:xnu-7195.50.7~2/RELEASE_X86_64
Kernel UUID: 84C6DC45-6B02-335F-9439-5D2A9BC385A4
KernelCache slide: 0x0000000007600000
KernelCache base:  0xffffff8007800000
Kernel slide:      0x0000000007610000
Kernel text base:  0xffffff8007810000
__HIB  text base: 0xffffff8007700000
System model name: iMacPro1,1 (Mac-7BA5B2D9E42DDD94)
System shutdown begun: NO
Panic diags file available: YES (0x0)
Hibernation exit count: 0

System uptime in nanoseconds: 806174743035
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x000000bbb3c25d83
  Sleep   : 0x0000000000000000 0x0000000000000000 0x0000000000000000
  Wake    : 0x0000000000000000 0x0000119c9a02fd18 0x0000000000000000

 

In particular:

"Zone element 0xffffff9379602a00 was modified after free for zone kext.kalloc.512: "

suggests a crap driver...

Link to comment
  • 1 month later...

I can report the same problem.

 

More in detail :

Unraid 6.9.0-beta35

VM pc-q35-5.1 BigSur 11.1 / OpenCore 0.6.4

e1000-82545em

 

Copying a 9Gb file from my MacBook Pro (Catalina) connected over wifi works fine (at least the few times I tested) . Copying the same file from the same Macbook connect over ethernet 1Gb/s leads to a halt after exactly 134,2Mo and then error -8084

Copying file directly from Unraid shares leads to kernel panic.

 

The difference on copying over wifi or ethernet would be the speed (and even more copying from unraid shares).

 

From what I understand from the discussions above, there is nothing much to do on our side, right ?

  • Like 1
Link to comment
20 minutes ago, bjornatic said:

From what I understand from the discussions above, there is nothing much to do on our side, right ?

True..and we don't know if it's a problem of the smb kext, or the e1000 driver, or whatever...The only solution should be to contact directly apple and speak at the phone with an expert so that he can see exactly what happens (screen sharing): however, we know what apple thinks about mac os on virtual machines, you can find valuable people willing to help and prepared to solve the issues or others that simply request the log files generated from the apple app, and once they see that mac os runs in an unsupported machine they simply don't bother to solve the issue.

It happened to me when I was trying to solve the facetime/imessage login issue (related to apple servers), only at the second phone call the expert solved the issue in less than 30 seconds..but this is a different story..

 

Btw, this seems to not be an issue related to unsupported machines, I think it was introduced in beta 7 (beta 6 broke smb, beta 1 - 5 were working good), and your issue is exactly the same as mine (stuck at 67,1 or 134,2 mb and then error -8084, or sometimes kernel panic), but this issue as I wrote doesn't apply to all files (it applies only to some files and the transfer always fails for that files) and I think it's independent on the size of the files, in fact I'm able to transfer 3-4gb files, but hangs for a 500mb file..

 

You also will probably notice that browsing folders/files and transfers are somewhat sluggish compared to Catalina.

Edited by ghost82
  • Like 1
Link to comment

Put me down as +1 this problem.  (Actually +2 as the problem is actually exactly the same after my wife upgraded to BigSur).  Previously, I was able to easily access my large volume ReadyNAS (v6.10.4) shares via SMB until the BigSur upgrade.  I am desperate for a fix.

 

One forum indicated that SMB3 - Required needed to be set on the ReadyNAS system.  That has been verified. 

-----------------

Global ReadyNAS setting are:

- (Checked) Enable SMB

- (Checked) Legacy Windows Discovery 

- (Checked) Enhance MacOS

Workgroup: VOLUME

 

SMB3 Transport Encryption:

(                ) Configure per share

(SELECTED) Configured globally [REQUIRED] (versus Enabled, Disabled, Desired)

---------------

 

Also (I just discovered) that TimeMachine to the ReadyNAS backup has not worked since December 4th.  That may or may not be the day that I upgraded to BigSur...  Not sure.

 

Any and all help is respectfully appreciated.    

Link to comment
16 hours ago, weaverita said:

I am desperate for a fix

I would suggest to switch off smb and turn on nfs which your readynas supports (at least till we/they find a fix). Nfs is quite stable for me and faster.

You will not see the server in the finder, as it happens with smb, finder doesn't scan for nfs shares on the network (even with the avahi daemon on the nfs server), so you have to manually connect to the server: right click on finder in the dock, connect to server, input nfs://serverIP/nameOfTheShare

 

For example:
nfs://192.168.2.1/media/VM

 

In the nfs server in linux the shares are defined in a file "exports", I don't know how readynas works.

This is an example of a share export:
/media/VM 192.168.2.0/24(rw,sync,no_subtree_check,no_root_squash,insecure)

 

/media/VM is the share to export from the server

192.168.2.0/24 the share can be accessed only from 192.168.2.0/24 network

insecure ---> make sure to use this, to use lower ports (<1023) otherwise macos will not connect; the name "insecure" doesn't reflect that option, security doesn't have anything to do with it

 

I don't use time machine, but a lot changed with big sur, and there are tons of users reporting issues: you may think about an alternate method to backup things...

Edited by ghost82
Link to comment

My current settings with 6.9RC2 and macOS Big Sur 11.2 Beta (20D5029f)

Enable SMB: Yes (Workgroup)

Hide "dot" files: No

Enhanced macOS interoperability: Yes

Enable NetBIOS: Yes

Enable WSD: Yes

 

Workgroup: WORKGROUP

Local master: Yes

 

With these settings I can confidently say I have been reliably copying multi-megabyte and gigabyte files to the server without issue through the Finder. 

Link to comment
  • 2 weeks later...
2 hours ago, bjornatic said:

Sadly it makes no (visible) change for me.

I added the line in the "Samba extra configuration" field, but the copy of a large file from an Unraid share still hangs at 134.2Mo and after a while error -8084.

 

(Big Sur 11.1 (20C69))

Did you restarted the server after new config or stopped/started array?

Edited by ghost82
Link to comment
  • 2 weeks later...

Soooo... I moved to 11.2 beta 2 (20D5042d) with big hopes and faith it would be fixed so I can go on with my life.

 

But no. Every single big file copy from my Unraid shares stops at 134,2Mo. Hangs and then error -8084

 

With or without ghost82 proposed solution.

 

Trying to make a full Time Machine backup lead to a complete system crash.

 

I could make my first complete Time Machine backup without carshing. So there is a bright side to this update.

Edited by bjornatic
Link to comment
  • 1 month later...

I still can't figure out why it is not working for me and it's starting to be problematic.

 

I switched to vmxnet3 for a while and local network worked okayish (I could transfert data from the server and I could do TimeMachine backups), but the upload rate to the www was close to non existant. So I'm back on e1000-82545em.

 

And as I'm not getting any progress on my own here are my settings :

 

<interface type='bridge'>
      <mac address='xx:xx:xx:xx:xx:xx'/>
      <source bridge='br0'/>
      <target dev='vnet0'/>
      <model type='e1000-82545em'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>

 

My network settings :

736541134_Networksettings.thumb.png.610fb24425a39aa3a39b2c578f3c10a4.png

 

And SMB settings :

84292078_SMBsettings.thumb.png.98c437afcd7a14a0554aa489ed95a540.png

 

If some of you can see somthing wrong, that would be helpfull as I still do not understand why the solution proposed by Ghost82 is working for some and not for me.

Edited by bjornatic
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.