Leaderboard

Any updates on this thread. I am also experiencing this issue. I request to make this thread change from Minor to Urgent. Due to not being able to access the NAS via SMB it is a showstopper in my humble opinion

They just need to push Samba 4.9.5 before 6.7 final. It fixes this bug. https://www.samba.org/samba/history/samba-4.9.5.html @limetech

I think leaving it out is the best bet, thanks for being open to including it though

Thanks for digging into that, then we should forget about the patch for 4.19 kernel?

After doing some more digging from what i can tell libva (ffmpeg, vainfo, intel_gpu_top) all fail to connect to the device, i've tried updating libva (and friends) but it seems something else is missing. Unfortunately it doesn't seem to be as simple as adding the missing chipset id. ☹️

This was the main reason I was originally asking, as well. Currently my i9-9900k is working a a lot harder than it should, with Plex being unable to leverage hardware transcoding.

This is a critical issue for me, a NAS that can't act as a NAS is somewhat pointless. Seems to be a Samba 4.9 issue which 6.7 introduces. https://bugzilla.samba.org/show_bug.cgi?id=13697 As suggested in multiple places (https://lists.samba.org/archive/samba/2018-September/218485.html) running net -s /dev/null groupmap add sid=S-1-5-32-546 unixgroup=nobody type=builtin fixes the problem. I've added this to my /boot/config/go script. However I am not 100% comfortable with this as not clear if this is going to cause other issues and the mapping created doesn't actually match the errors, but will run rc5 like this for now and see if anything crops up.

This is what I went with because it matches the existing style in the file: wait_nginx_status() { for i in {1..10} ; do if ! nginx_status ; then break fi sleep 1 done }

Yes

We can easily add that patch to 4.19, but what do you mean by this?

After applying the patch the i915 driver loads and /dev/dri is created. I’ll manually build the kernel for now until Unraid is using a newer kernel 😀

Thanks, well it does look correct 🙄 Has this ever worked for you? As pointed out by @wgstarks googling the message, this seems to be a common problem. First thing to verify is that nothing is out of the ordinary on the OS X side, check for example: https://discussions.apple.com/thread/8241168 https://architectsecurity.org/2018/01/solved-time-machine-error-17-and-time-machine-backup-does-not-support-required-time-machine-capabilities/ Next, in the Samba vfs_fruit documentation, there is this warning: "Be careful when mixing shares with and without vfs_fruit. OS X clients negotiate SMB2 AAPL protocol extensions on the first tcon, so mixing shares with and without fruit will globally disable AAPL if the first tcon is without fruit." This might happen, for example, if you have existing connections to Unraid SMB shares with the "Enhanced OS X interoperability" set to No, and then change this to Yes.

Yes, sorry, 6.7.0-rc5. Not sure where the rc7 came from.

Are you sure that 2GB (2048MB) is a large enough volume for your backup? Mine is much larger. I use 1TB (1000000MB).

I suppose you mean version 6.7.0-rc5

Reverting to 6.6 and all my shares are accessible again, so there is an issue with 6.7.0-rc7

I also have this issue. A domain un-join and re-join after reboot doesn't rectify this either. This is with rc7 Final lines in syslog, with additional SMB logs enabled are Mar 3 10:20:21 unraid smbd[7310]: check_ntlm_password: authentication for user [userid] -> [userid] -> [DOMAIN\userid] succeeded Mar 3 10:20:21 unraid smbd[7310]: [2019/03/03 10:20:21.011860, 2] ../source3/auth/token_util.c:713(finalize_local_nt_token) Mar 3 10:20:21 unraid smbd[7310]: WARNING: Failed to create BUILTIN\Administrators group! Can Winbind allocate gids? Mar 3 10:20:21 unraid smbd[7310]: [2019/03/03 10:20:21.012217, 2] ../source3/auth/token_util.c:732(finalize_local_nt_token) Mar 3 10:20:21 unraid smbd[7310]: WARNING: Failed to create BUILTIN\Users group! Can Winbind allocate gids? Mar 3 10:20:21 unraid smbd[7310]: [2019/03/03 10:20:21.012569, 2] ../source3/auth/token_util.c:774(finalize_local_nt_token) Mar 3 10:20:21 unraid smbd[7310]: Failed to create BUILTIN\Guests group NT_STATUS_ACCESS_DENIED! Can Winbind allocate gids? So looks like some winbind problem. Note behaviour is identical from Windows and Mac hosts, so this isn't a recent Windows update. Happened when moving to 6.7.0-rc releases. I will probably revert to 6.6 unraid-diagnostics-20190303-0957.zip

Honestly, considering the issues moving to 4.19, looks like Unraid 6.7.0 'stable' will remain on the 4.19 kernel, which btw, is a "long term support" kernel. For Unraid 6.8 we'll probably skip 4.20 and move right to 5.0. I know this is not what you were hoping for, but to continue the -rc series on a new kernel is not something we're looking forward to for 6.7 release.

Easily reproduceable if you take a browser at 1920px and slowly resize it down. At the point where the 3rd column disappears due to space, it actually appears below exactly like the picture. (Reproduced on Black)

Historically Unraid was run ‘headless’ administered from another machine/device. A GPU was then only required if the motherboard demanded it to boot successfully. The option to have the GUI Boot mode was added during v6 development due to popular demand but I think that the ‘headless’ mode is probably still the commonest way Unraid is run. There have been a number of reports that some motherboard/GPU combinations do not seem to run in GUI boot mode at optimum resolution. I know Limetech have been trying to reduce the incidence of this type of problem but it has definitely not been eradicated for everyone.

Right, made a PR.

Where's the button to enable multiple cache drives?!?!?

new dash looks great! only issue I found was my plex docker (plexinc repository) wont start just gets a pop up with "server error"

I've made a correction to rebuild USB controllers. Please retest when new release is available.