Well, fsck. Updated my Plex Media Server to the newest TXZ version, rebooted, configured, etc... until I noticed that /mnt/user wasn't mounted to shfs. Uh-oh. No idea what to do with this one, or where to find the right logs to post. Halp?

No need to panic. Try stopping then starting the array via the management console (emhttp). Usually that will restart the user-space shfs process.

That gives an endless stream of "Retry unmounting user share(s)...", which can only be stopped by running "rm -rf /mnt/user" (df shows it's not mounted, so it doesn't kill actual files). Should I do that, or something else?

I figured out the rm -rf bit after reading these (repeated) syslog lines in unMENU:

Jun  5 17:38:45 NAS logger: umount: /mnt/user: not mounted

Jun  5 17:38:45 NAS emhttp: _shcmd: shcmd (130): exit status: 1 (Other emhttp)

Jun  5 17:38:45 NAS emhttp: shcmd (131): rmdir /mnt/user |$stuff$ logger (Other emhttp)

Jun  5 17:38:45 NAS logger: rmdir: failed to remove `/mnt/user': Directory not empty (Minor Issues)

Jun  5 17:38:45 NAS emhttp: shcmd (132): crontab -c /etc/cron.d -d $stuff$> /dev/null (Other emhttp)

Jun  5 17:38:45 NAS emhttp: Retry unmounting user share(s)... (Other emhttp)

Need system log.

ahh, unMenu has a very nice way to download the whole thing. Here we are! http://pastebin.com/CV3MfZ8b

Some process/application has an open file descriptor on one of the user shares.  For example, if you open a telnet session and then 'cd /mnt/user/somesharename', and try to Stop array, you will get these messages because the OS will not be able to unmount the share.  So this is either an issue with a plugin, or some other application you have running.

`lsof | grep mnt` gives me nothing.

`lsof | grep mnt` gives me nothing.

 

Is it possible you have a file which is located on a user share mounted as a loopback device?

Probably not, since I didn't know what those were until I googled it just now. Is there a way to check?

Ok, you have a "race condition" happening.  In your system log we see:

 

Jun  5 17:19:40 NAS transmission-daemon[10184]: Saved "/mnt/user/torrents/install/conf/settings.json" (bencode.c:1721)

 

And then after that,

 

Jun  5 17:20:52 NAS emhttp_event: disks_mounted

 

What's happening is 'transmission-daemon' (or something before it) is creating '/mnt/user/...' paths before the user share file system is actually mounted.  When the code gets around to mounting the user share file system, if the mount point already exists, it exits instead of continuing the mount (this is one of those "never supposed to happen" things).

 

NOTE: the reason I asked about a loopback-mounted file is that this does not show up in 'lsof' for some reason.

you need to use the unRAID event system to WAIT until after the file-systems are in place before starting any add-ons.

 

 

so I should move the line:

cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c

from /boot/config/go to the disks_mounted event handler?

so I should move the line:

cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c

from /boot/config/go to the disks_mounted event handler?

all of the packages I created would not care...  however...

 

If you installed any of the .plg packages, those are NOT invoked by the .auto_install files created by the unMENU package installer.

I suspect you may have those installed.  They are installed by emhttp simply because they exist in /boot/extras and expect to only INSTALL, not start.  They should start with the array-started event (or one of the events that indicates services may be started)  If they start before the array has been started, they are BROKEN  and their author needs to be notified so they can be fixed.

 

If you have any unMENU packages that are starting before the array is online, then they are BROKEN and their author needs to be notified so they can be fixed.  Those are the only ones using the .auto_install files in the /boot/packages directory.    None that I created access the disks until they are online.  (In most cases, it is ok to install the packages, but not ok to access disks and directories in the user-share file system until AFTER they are in  started.

 

Joe L.

 

The package in question is Transmission_unraid-2.42-i486-1kh.txz, which is configured to install to /mnt/users/torrents/install. I had it set up that way so it could keep settings, dht.dat, the blocklist file, and torrent metadata between reboots. It worked fine up until I upgraded Plex; my guess is that Plex installation used to take long enough to delay Transmission installation until after the disks were mounted. Any ideas?

the patch for Plex is already committed. then there should be no problem from this side....

 

it will be released as soon as possible.

Could this get moved to general support/user customisations or marked as (closed) as it is obviously not an issue related to rc3 when no additional plugins/packages/scripts are involved?

 

We will never get to 5.0-Final if Tom spends all his time fixing issues that aren't related to the RC.

Yeah, makes more sense in General->UC. Transmission still needs a fix for this.

new plex media server is out: http://www.plexapp.com/linux/linux-pms-download.php