Jump to content

eschultz

Administrators
  • Content Count

    496
  • Joined

  • Last visited

  • Days Won

    7

Posts posted by eschultz


  1. The SMBus most likely is the culprit and has a driver assigned, preventing you from passing through the audio controller (both in the IOMMU group 9).

     

    To get around this, you'll need to prevent Unraid from assigning the SMBus driver upon boot by adding "modprobe.blacklist=i2c_i801,i2c_smbus" to your Syslinux configuration append line.  

     

    Just navigate to this page:
    https://cronos/Main/Flash?name=flash

     

    And modify the green block's append line:

    Screen Shot 2020-08-30 at 8.30.48 PM.png

     

    Then hit Apply and reboot the Unraid server.  Your Windows VM should be able to start after that.


  2. If you're using just HTTP (and not HTTPS) then adding 'Secure' to the cookie will just prevent it from sending over HTTP.

     

    What I think you really need, when your using just HTTP, is:

    SameSite=Lax

     

    You can test this temporarily by running this command in your Unraid terminal:

    sed -i 's/samesite=strict/samesite=lax/g' /usr/local/emhttp/plugins/dynamix/include/local_prepend.php

    and then Logout and Log back in to the Unraid web UI to refresh the cookie with the new samesite=lax settings.

     

     


  3. Are there hidden files or folders that live on the Synology share?  I think macOS will update a separate hidden file to hold that metadata if it can't add xattr on the file directly.  (I don't have a Synology box here unfortunately)


  4. When I add macOS "labels/tags" on a file or directory from a Unraid share via samba protocol it adds EA data:

    root@Tower:/mnt/user/testshare# getfattr test_folder/
    # file: test_folder/
    user.DOSATTRIB
    user.DosStream.com.apple.metadata:_kMDItemUserTags:$DATA
    user.org.netatalk.Metadata

    Additionally, 'getfattr' will show the values, along with the keys above, with the -d argument.

     

    I did another test involving a cache pool setup:

    1. Created another share named 'cache-first' with Cache mode set to 'only.'
    2. Browsed to the 'cache-first' share from a mac, created a new folder, and then applied macOS "tags" to it.
    3. Verified those EAs were present using 'getfattr folder-name'.
    4. Change 'cache-first' Share's Cache mode to 'yes'.
    5. Run the mover
    6. Verified 'cache-first' share exists on the array now, and the EAs are still present. My mac again shows the correct "tags" I added previously.

    I can also copy/move files or folders between my mac and Unraid, in either direction, and the "tags" persist.

     

    macOS version 10.14.6

    Unraid version 6.8.3

    Two BTRFS formatted SSDs in my Cache Pool

    Array disks all XFS-luks

     

    If you're working from a terminal, using 'cp,' 'rsync,' or 'scp' for example, ensure you provide any arguments you may need to preserve xattr.

     


  5. 48 minutes ago, gzilla said:

    omg good timing.. I've just built a new PC and really needed the thunderbolt support as I couldn't find it anywhere.. Now all I need is boltctl to add devices on it onto IOMMU and I'm ready to roll!

    Which motherboard or add-on card are you using that has thunderbolt?


  6. 3 minutes ago, eybox said:

    Thank you for this lead!

     

    I do have 4 NICs. And I use only one of them - eth0, with br0 attached to everything - Dockers and VMs. I tested eth1 a lot of time ago if it worked or not, but never used br1.

     

    What is the resolution to this? Removing everything eth1 and br1 related from network.cfg perhaps?

    Yeah, get rid of the following from network.cfg:

    IFNAME[1]="br1"
    BRNAME[1]="br1"
    BRNICS[1]="eth1"
    BRSTP[1]="no"
    BRFD[1]="0"
    DESCRIPTION[1]="VMs connections"
    PROTOCOL[1]="ipv4"
    USE_DHCP[1]="no"
    IPADDR[1]="192.168.86.125"
    NETMASK[1]="255.255.255.0"
    GATEWAY[1]="192.168.85.1"
    METRIC[1]="2"

    Also change SYSNICS="2" to SYSNICS="1" at the end.  Then reboot server.

    • Like 1

  7. 6 hours ago, eybox said:

    Looks like in 6.7 the default route is being set incorrectly to br1 instead of br0.  Are you using br1 for anything?  It looks like eth1, the link for br1, is disconnected anyways...

    • Like 1

  8. On 4/23/2019 at 10:44 PM, uldise said:

    to not open new topic, i will post it here - topic name is missing under "Next unread Topic", see pic. attached. until yesterday it was in place.

    Unfortunately IPS (our forum software) removed that in version 4.4.x:

    "Removed the name of the content (e.g. topic) from the “Next Unread” link which could consume significant server resources on large communities."


  9. 29 minutes ago, clowrym said:

    Just upgraded to 6.7.0-rc1, for some reason I can't start my plugin anymore, the following is all the entries I see in the Logs

     

    
    Jan 22 11:19:01 Test ool www[18957]: /usr/local/emhttp/plugins/openvpnserver/scripts/rc.openvpnserver 'start'
    Jan 22 11:19:01 Test sudo: root : TTY=unknown ; PWD=/usr/local/emhttp ; USER=root ; COMMAND=/usr/sbin/openvpn --writepid /var/run/openvpnserver/openvpnserver.pid --config /mnt/cache/appdata/OpenVPN/openvpnserver.ovpn --script-security 2 --daemon

    Also found:

    
    openvpn: error while loading shared libraries: libcrypto.so.l: cannot open shared object file: No such file or directory

     

    This plugin will need to upgrade to using the openvpn-2.4.6-x86_64-2 package since it is compiled to work with the newer versions of openssl.  The legacy version of openssl (libcrypto.so) was removed in 6.7.0-rc1.