ken-ji

Stop the container. Very important. A running container will probably delete all your Dropbox files. Open the terminal to Unraid >_ on the upper right of your screen. run root@tower:~# rm -r /mnt/user/appdata/dropbox /mnt/user/Dropbox this will nuke Dropbox share (which will be regenerated when the container is started up) and the appdata for the Dropbox container When you restart the container, it will run from scratch, so you will need to link it again. Warning, this might cause you to go over the 3 devices limit for Free accounts, so make sure to go your Dropbox account and unlink the previous container. It will be a linux client with a hexadecimal name like abc12458efd

Because Dropbox did a very dick move sometime back and artificially (as far as it seems on the user end) limited the client to run on only the Ext4 FS. This has been slightly amended to include "Mainstream" ones like as I listed previously. So the client refuses to run on a shfs mount ie the /mnt/user location. /mnt/user contains all the disks in your array plus the optional cache drive. So, in your case /mnt/user/appdata/dropbox would probably fall under /mnt/disk1/appdata/dropbox unless some of the disk allocation rules come into effect. I'm thinking your app data folder is partially corrupt, since the error mentions some missing files from the application zip archive, so you can try removing both the appdata and Dropbox mount points in Unraid (so that you really start afresh).

So, since there seems to be a problem with shfs, please change the location of the mounts to /mnt/cache/appdata/dropbox and /mnt/cache/Dropbox (and keep that Dropbox share cache only) - This is the new default as pointed out by the other Community maintainers. I assume the cinereus user name is a user you created in the Unraid Users settings. I also assume this user has access to the Dropbox share? Otherwise I don't see what the problem is. This is my setup, with the Config folder stored in a Unassigned Cache SSD

Could you post a screenshot of your dropbox container mount mappings?

Not picking a fight, but it is discussed on post #2, page #1 of this support thread.

Because at the right most column of the Docker tab/page says LOG, and in basic its a picture of a log file I don't know what you meant by this, since accdg to Docker: https://help.dropbox.com/installs-integrations/desktop/system-requirements#desktop A Dropbox folder on a hard drive or partition formatted with one the following file system types: ext4 zfs (on 64-bit systems only) eCryptFS (back by ext4) xfs (on 64-bit systems only) btrfs What is not supported is the shfs (User Share filesystem) exclusive to Unraid, so you can no longer run the Dropbox container on a user share (/mnt/user/*), but needs to be on either the cache drive (/mnt/cache) , a physical array drive (/mnt/diskX) or an Unassigned Drive (/mnt/disks). As I've discussed above, placing the Dropbox sync folder on a user share was never a good idea due to mover moving files between the cache and the array, effectively making the files disappear from Dropbox's point of view, causing files to be deleted and reuploaded/downloaded

I've built the image with the necessary X11 libraries installed. I've started it up without errors and worked on my local instance

This means you need to revert your dropbox application version which is cache in your appdata to allow the application to update itself this would be /mnt/user/appdata/dropbox/.dropbox-dist (or your equivalent) folder This folder contains your current version of the Dropbox app You can stop the container, then proceed to delete the folder /mnt/user/appdata/dropbox/.dropbox-dist, then restart the container. I am working on fixing the image as it seems fixable (by adding the missing X11 libraries - why a headless app needs X11 libraries is beyond me)

Seems I triggered the automated build on the master branch by mistake. I re uploaded my last working version as the freeze tag and the latest tag. So you can edit the template to use the freeze tag (or just delete the current image and try again) This is what I don't like about the automated docker build system, there's no going back unless you built it into your workflow.

@noski @NKnusperer Did you add the network to the Docker settings? Make sure to have the array stopped and to toggle the Advanced view in the upper right corner.

If you don't want to troubleshoot a lot - stick to the latest stable release 4.4.0.40 HW accelerated transcoding has been there since 4.0.0.0, but its a premium feature ( you need to subscribe ) I'm not too sure about Radeon cards, but Quadros do work , though I am only using Intel iGPU for this as its cheap and more than good enough for me FYI I'm on a Mini-ITX board and have a HBA installed so can't even install a GPU

I've been on the beta since the HW assisted transcoding became a feature. Haven't really had issues like you described

Using 2.7, Tried running the benchmarks again, but only got one benchmark run and its still assigned to all the drives. Looking inside the container appdata root@MediaStore:/mnt/disks/SSD/appdata/DiskSpeed/Instances/local/driveinfo# tree hdwn180_gx2m_* hdwn180_gx2m_3942k0gjfavg_8tb ├── SMARTDescList.txt ├── benchmark │ ├── 1583361860341 │ │ ├── 0000000000000000.txt │ │ ├── 0000800155238400.txt │ │ ├── 0001600311787520.txt │ │ ├── 0002400468336640.txt │ │ ├── 0003200624885760.txt │ │ ├── 0004000781434880.txt │ │ ├── 0004800936673280.txt │ │ ├── 0005601093222400.txt │ │ ├── 0006401249771520.txt │ │ ├── 0007201406320640.txt │ │ ├── 8001563222016.txt │ │ ├── DriveLatency.sh │ │ ├── DriveLatency.txt │ │ ├── RandomSeek.sh │ │ ├── RandomSeek.txt │ │ ├── SequentialSeek.sh │ │ ├── SequentialSeek.txt │ │ ├── datestamp.txt │ │ ├── latency.txt │ │ ├── speed.json │ │ ├── valid.txt │ │ └── version.txt │ ├── 1583377616913 │ │ ├── 0000000000000000.txt │ │ ├── 0000800155238400.txt │ │ ├── 0001600311787520.txt │ │ ├── 0002400468336640.txt │ │ ├── 0003200624885760.txt │ │ ├── 0004000781434880.txt │ │ ├── 0004800936673280.txt │ │ ├── 0005601093222400.txt │ │ ├── 0006401249771520.txt │ │ ├── 0007201406320640.txt │ │ ├── 8001563222016.txt │ │ ├── DriveLatency.sh │ │ ├── DriveLatency.txt │ │ ├── RandomSeek.sh │ │ ├── RandomSeek.txt │ │ ├── SequentialSeek.sh │ │ ├── SequentialSeek.txt │ │ ├── datestamp.txt │ │ ├── latency.txt │ │ ├── speed.json │ │ ├── valid.txt │ │ └── version.txt │ ├── 1583378375557 │ │ ├── 0000000000000000.txt │ │ ├── 0000800155238400.txt │ │ ├── 0001600311787520.txt │ │ ├── 0002400468336640.txt │ │ ├── 0003200624885760.txt │ │ ├── 0004000781434880.txt │ │ ├── 0004800936673280.txt │ │ ├── 0005601093222400.txt │ │ ├── 0006401249771520.txt │ │ ├── 0007201406320640.txt │ │ ├── 8001563222016.txt │ │ ├── DriveLatency.sh │ │ ├── DriveLatency.txt │ │ ├── RandomSeek.sh │ │ ├── RandomSeek.txt │ │ ├── SequentialSeek.sh │ │ ├── SequentialSeek.txt │ │ ├── datestamp.txt │ │ ├── latency.txt │ │ ├── speed.json │ │ ├── valid.txt │ │ └── version.txt │ ├── 1583411489259 │ │ ├── 0000000000000000.txt │ │ ├── 0000800155238400.txt │ │ ├── 0001600311787520.txt │ │ ├── 0002400468336640.txt │ │ ├── 0003200624885760.txt │ │ ├── 0004000781434880.txt │ │ ├── 0004800936673280.txt │ │ ├── 0005601093222400.txt │ │ ├── 0006401249771520.txt │ │ ├── 0007201406320640.txt │ │ ├── 8001563222016.txt │ │ ├── DriveLatency.sh │ │ ├── DriveLatency.txt │ │ ├── RandomSeek.sh │ │ ├── RandomSeek.txt │ │ ├── SequentialSeek.sh │ │ ├── SequentialSeek.txt │ │ ├── datestamp.txt │ │ ├── latency.txt │ │ ├── speed.json │ │ ├── valid.txt │ │ └── version.txt │ ├── 1583412489111 │ │ ├── 0000000000000000.txt │ │ ├── 0000800155238400.txt │ │ ├── 0001600311787520.txt │ │ ├── 0002400468336640.txt │ │ ├── 0003200624885760.txt │ │ ├── 0004000781434880.txt │ │ ├── 0004800936673280.txt │ │ ├── 0005601093222400.txt │ │ ├── 0006401249771520.txt │ │ ├── 0007201406320640.txt │ │ ├── 8001563222016.txt │ │ ├── DriveLatency.sh │ │ ├── DriveLatency.txt │ │ ├── RandomSeek.sh │ │ ├── RandomSeek.txt │ │ ├── SequentialSeek.sh │ │ ├── SequentialSeek.txt │ │ ├── datestamp.txt │ │ ├── latency.txt │ │ ├── speed.json │ │ ├── valid.txt │ │ └── version.txt │ ├── 1584049865832 │ │ ├── 0000000000000000.txt │ │ ├── 0000800155238400.txt │ │ ├── 0001600311787520.txt │ │ ├── 0002400468336640.txt │ │ ├── 0003200624885760.txt │ │ ├── 0004000781434880.txt │ │ ├── 0004800936673280.txt │ │ ├── 0005601093222400.txt │ │ ├── 0006401249771520.txt │ │ ├── 0007201406320640.txt │ │ ├── 8001563222016.txt │ │ ├── DriveLatency.sh │ │ ├── DriveLatency.txt │ │ ├── RandomSeek.sh │ │ ├── RandomSeek.txt │ │ ├── SequentialSeek.sh │ │ ├── SequentialSeek.txt │ │ ├── datestamp.txt │ │ ├── latency.txt │ │ ├── nosubmit.txt │ │ ├── speed.json │ │ ├── valid.txt │ │ └── version.txt │ ├── BenchInfo.wddx │ ├── allspeed.json │ └── avgspeed.json ├── config.json ├── image.png └── smartreport.wddx hdwn180_gx2m_3992k0nqfavg_8tb ├── config.json └── image.png hdwn180_gx2m_399fk0g3favg_8tb ├── config.json └── image.png hdwn180_gx2m_79iuk0vufavg_8tb ├── config.json └── image.png 7 directories, 146 files

@jbartlett Any idea why my 4 Toshiba N300s get mapped together as far as benchmarks go? My 4 Segate Archive Drives didn't get lumped together in the benchmarks Each of the Seagate get their own benchmark speed graph Each N300 gets all of the N300 benchmarks together in the graph (there's one extra because I got confused as to which one had been benched)

Click on the container icon and select >_ Console This will open a terminal inside the container, then run the following commands first su - nobody cd Dropbox then you can run the dropbox.py command for the various commands to see the sync status

Sorry for not answering your PM, but the container does have the dropbox.py script which can be used to check the status of the sync

in 6.8 series, the USB drive is now mounted with execute permissions. So when you copy scripts from the USB, the scripts need to be marked executable with chmod a+x /usr/local/emhttpd/webGui/event/starting/fetch_key chmod a+x /usr/local/emhttpd/webGui/event/started/delete_key

AFAIK, you don't / can't impose vm isolation with just a virtual switch - you'll need additional software on the vswitch (which is not part of Unraid) however, creating a vswitch for the vm alone then using iptables to restrict access to it should work. you should also try to impose guest level restrictions as well.

@Dav3 Would hep if you outline your network config and what exactly you want to do here Looks to me like you want to define a bridge interface in Unraid "private0" which should be NATd against br1, using outgoing ports 500-1000 and assigning the internal IP of 192.168.1.202/24 to the bridge . I'll definitely say first that I haven't messed with the network config of VMs for quite a while now as I have no need for complex networking with Unraid VMs. I'm only using bridged VMs on the primary interface br0 as I don't need to make other complicated setups - docker and a Mikrotik router has is currently enough for my needs.

@CyberMew Hey, I don't have dropbox for business and have never tried the container with such an account. I will say the error logs seems like your container seems to be failing in connecting to the Dropbox servers. Diud you try starting the container against a new and empty appdata folder as well as the Dropbox folder?

The dropbox client here is headless, and on startup if it decides you are not logged in, it will print a link in the container logs. This link should be opened in any browser, which will then proceed to have you login to Dropbox via passwords, tokens, 2FA and whatever. Upon successful login, the client will then proceed to sync.

This is NFS, and your question indicates you are not quite familiar about how it works: So, in a nutshell, NFS works under the assumption that the underlying POSIX user ids in both the server the client are matched, so that root is root and a named user ie bob has uid 1000 on both; similarly for group ids. (There are special rules for root mapping and anonymous user access) When a share is mounted on the client, for bob (uid 1000 and gid 100) to be able to read and write on the client, the following must be true: the NFS directory and files are either owned by a user with uid 1000, or gid 100 or the underlying filesystem ACLs allow other uid to read and write. so ie. # ls -al Strike\ the\ Blood drwxrws--- 1 nobody users 1228 Sep 18 19:53 ./ drwxrws--- 1 nobody users 134750 Jan 19 08:02 ../ drwxrws--- 1 nobody users 648 Aug 5 17:40 BD\ menu/ -rw-rw---- 1 nobody users 1352685938 Aug 5 17:41 [Beatrice-Raws]\ Strike\ the\ Blood\ OVA\ -\ 01\ [BDRip\ 1920x1080\ HEVC\ FLAC].mkv In this case, my /etc/exports contains: "/mnt/user/Downloads" -async,no_subtree_check,fsid=117 192.168.2.0/24(sec=sys,rw,no_root_squash,insecure) *(sec=sys,ro,insecure,anongid=100,anonuid=99,all_squash) and my Shares setting is So this means, my NFS client can map the /mnt/user/Downloads directory and do file operations as root, or the nobody user. Other clients in different subnets, are all forced to the nobody user, which still has correct access to files. (I've done some changes to my Samba config to force all the access as the nobody user but still require authentication) Hope this helps.

Uneventful update from 6.8.0. Keep up the good work!

@dweb emhttp is not meant to be restarted AFAIK. You might want to just move the the emhttp startup at the very end, while doing a loop - waiting for the keyfile before starting emhttp. This is untested and might have a nasty side effect of disabling the unRAID GUI until you've provided the keyfile. while [ ! -f /root/keyfile ]; do sleep 60 done Maybe the others know the CLI command for stopping and starting the array - so you can restart it instead.

Tried upgrading a really old system - running 6.7.2 and SATA Silicon Image port multipliers The whole system bombs out with read and write "errors" on the port multipliers until a disk is disabled. Rolled back with out issues other than a eventless disk rebuild. I guess its time to try upgrading this system Posting the diagnostics for reference. tower-diagnostics-20191229-0353.zip <- 6.7.2 tower-diagnostics-20191228-1024.zip <- 6.8.0