"/mnt/.user-shares/admin" library folder path added when using directory picker on TS-877

Server Version#: latest
Player Version#: any

When picking the library path, Plex adds /mnt/.user-shares/admin which doesn’t even exist!

See screenshot where the first is the changed path it updated on it’s own, while the bottom path is the path I entered for comparison. I think have to delete the one on top and things are back to normal for a while.

That’s not Plex.

You can thank:

  1. The Multimedia share.
  2. Codex Pack

This is a LONG established incompatibility.

It is stated (warned) in the QNAP FAQ)

QNAP is now working to resolve it but for now:

  • Directly reference each actual share where you store your media. (/share/CACHEDEV1_DATA/movies, etc)
  • Uninstall the Codex Pack

Weird. I have always used the direct paths as I dont trust the alias or media paths. I have all the media features disabled on the NAS that I know of and don’t use any of the quirky stuff QNAP provides. I store all my media for photos, music, videos, etc all in manually created shares so even default media QNAPware wouldn’t be able to see them if they were enabled. Multimedia folders from QNAP are all empty.

But still the mystery remains how it was changed from /share/CACHEDEV1_DATA to /mnt/.user-shares. I’d never even heard of .user-shares until it showed up in my library path here in Plex, so I know I didn’t enter it… :thinking:

Thanks for the hint on Codex, but seems like there isn’t any CodexPack on the NAS that I can tell. Google search brought this comment to grep for it.

[/mnt/HDA_ROOT/.config] # echo “CodexPack: $(getcfg -f /etc/config/qpkg.conf CodexPack version)”
CodexPack:

Ahh, i see a qpkg in the QNAP app catalog called CodexPack now. Yep, that’s never been installed and i’ve never used it on any of my NAS devices. Thanks for the tip Chuck.

Are you using FileStation or another package to mount media across the LAN on this QNAP?

No, don’t use filestation at all. Maybe I need to just watch and see if it does it again. Would another app be able to change preferences and settings inside the plex-server database anyway? This NAS doesn’t have much installed on it at all, and nothing has been added for several months now. This has happened twice in the last couple weeks and I haven’t been able to peg down what could cause it. Apps below.

PlexPy doesn’t permit you to remote-admin the server AFAIK …

BUT

If you have remote access enabled in PlexPy AND the default password (or an easy one), you’re vulnerable.

Plex.py is just for internal usage and stats as its not available outside the firewall. It’s essentially a log viewer. None of the admin or allow guest stuff is enabled. I can’t think of anything else that would connect to Plex.

To change the member directory paths of a library section requires:

  1. Section Name
  2. Section ID
  3. Section Type
  4. Agent info
  5. Full list of all the other locations.

The first 4 are used to identify it
Section ID and path names are required to update.
If the server is secured, the Token must also be used.
This is no small undertaking.

It is easier to rename existing referenced directories because Plex has them identified by inode. When it displays for Plex/web, it does a ‘getpathbyinode()’ call to reverse the direction and get the true path.

What on the NAS could be renaming the directory/ies ?

I think I figured this out… Plex for some reason thinks /mnt/.user-shares is a symlink by default. Is this really hardcoded into Plex as a possible path? It shouldn’t be. I don’t have that on my device anywhere, not even in a symlink. It just doesn’t exist.

Blockquote
[/] # ls -l /share/Movies
lrwxrwxrwx 1 admin administrators 21 2020-05-09 21:48 /share/Movies → CACHEDEV1_DATA/Movies/

So if I pick the above path in the Add Folder picker for a library, it gives me:

Capture

But if I pick the direct path via the device and not the QNAP symlinked path listed above, then I get:

Capture2

The point is, the path Plex is making up when using the symlink path doesn’t exist. There seems to be some error in the directory picker logic here… I would prefer to use the Symlinked path as device ID will cause problems if moving devices. For example, a TS-569L the path is “/share/MD0/Movies” with a symlink to “/share/Movies”. On my TS-877 it is “/share/CACHEDEV1_DATA/Movies” as shown above. But on both systems the symlink of /share/Movies works on both device which is where I would point Plex. This is why QNAP uses this logic of obscuring the device ID.

So where is plex getting this /mnt/.user-shares ??

BTW - I can manually type the path “/share/Movies” and it will respect me forcing the path, but just know this is not available in the picker mode because it adds /mnt/.user-shares

It’s how QNAP makes the entries in /share

I just worked through it.

I have NFSv4 enabled.

Readlink resolution, because they used hard links, it finds the first name.
In my case, NFSv=4 subdir is found first because NFS was started first

This is a QNAP problem. It’s always been weird this way.

Maybe something can be done but I don’t think so because it would impact every Linux system supported. (common binaries)

I would expect what you show in your pic, but nowhere in our systems is there a /mnt/.user-shares that Plex is suggesting to use. That’s the weird part. So essentially the Plex provided path picker doesn’t work unless you use the device name.

Crashplan as an example has a directory picker to select directories to backup, and nowhere in that app does it suggest a /mnt/.user-shares hidded directory.

Where do YOU have that directory from?

I have never seen it before.

Nobody has complained about such a directory either.

Do you have shares mounted via the QNAP proprietary mount mechanism?

I think the challenge here is to find out who/what is creating the .user-shares directory.

From the Plex app, exactly as stated above… See for yourself. :wink:

https://drive.google.com/file/d/1fYDE4rE07NNbditKgGnsVuT3w6Ae38U9/view?usp=sharing

Yep, same as you… Straight outta the box QNAP share.

Blockquote
[/] # ls -l /share
total 12
lrwxrwxrwx 1 admin administrators 20 2020-05-09 21:48 Alien → CACHEDEV1_DATA/Alien/
lrwxrwxrwx 1 admin administrators 19 2020-05-09 21:48 Apps → CACHEDEV1_DATA/Apps/
lrwxrwxrwx 1 admin administrators 30 2020-05-09 21:48 Browser Station → CACHEDEV1_DATA/Browser Station/
drwxrwxrwx 68 admin administrators 4096 2020-05-09 21:52 CACHEDEV1_DATA/
drwxrwxrwx 3 admin administrators 4096 2020-01-02 22:31 CACHEDEV2_DATA/
drwxrwxrwx 5 admin administrators 4096 2020-04-08 08:21 CACHEDEV3_DATA/
lrwxrwxrwx 1 admin administrators 24 2020-05-09 21:48 Container → CACHEDEV1_DATA/Container/
lrwxrwxrwx 1 admin administrators 21 2020-05-09 21:48 docker → CACHEDEV1_DATA/docker/
lrwxrwxrwx 1 admin administrators 23 2020-05-09 21:48 Download → CACHEDEV1_DATA/Download/
lrwxrwxrwx 1 admin administrators 34 2020-05-09 21:48 Hosted.site.backups → CACHEDEV1_DATA/Hosted.site.backups/
lrwxrwxrwx 1 admin administrators 21 2020-05-09 21:48 htdocs → CACHEDEV1_DATA/htdocs/
lrwxrwxrwx 1 admin administrators 21 2020-05-09 21:48 Movies → CACHEDEV1_DATA/Movies/
lrwxrwxrwx 1 admin administrators 25 2020-05-09 21:48 Multimedia → CACHEDEV1_DATA/Multimedia/
lrwxrwxrwx 1 admin administrators 20 2020-05-09 21:48 Music → CACHEDEV1_DATA/Music/
lrwxrwxrwx 1 admin administrators 26 2020-05-09 21:48 Music.HiRes → CACHEDEV1_DATA/Music.HiRes/
drwxrwxrwt 3 admin administrators 60 2020-05-09 21:51 NFSv=4/
lrwxrwxrwx 1 admin administrators 23 2020-05-09 21:48 Pictures → CACHEDEV1_DATA/Pictures/
lrwxrwxrwx 1 admin administrators 27 2020-05-09 21:48 Pictures.new → CACHEDEV1_DATA/Pictures.new/
lrwxrwxrwx 1 admin administrators 21 2020-05-09 21:48 Public → CACHEDEV1_DATA/Public/
lrwxrwxrwx 1 admin administrators 22 2020-05-09 21:48 Scratch → CACHEDEV1_DATA/Scratch/
lrwxrwxrwx 1 admin administrators 18 2020-05-09 21:48 SSD → CACHEDEV1_DATA/SSD/
lrwxrwxrwx 1 admin administrators 29 2020-05-09 21:48 Video.Projects → CACHEDEV1_DATA/Video.Projects/
lrwxrwxrwx 1 admin administrators 21 2020-05-09 21:48 Videos → CACHEDEV1_DATA/Videos/
lrwxrwxrwx 1 admin administrators 25 2020-05-09 21:48 Virtualbox → CACHEDEV1_DATA/Virtualbox/
lrwxrwxrwx 1 admin administrators 29 2020-05-09 21:48 Virtualization → CACHEDEV1_DATA/Virtualization/

This isn’t the end of the world if you know about it, but it likely won’t create a great user experience for someone less technical using the picker to find their path to their media files.

But as I mentioned, that path doesn’t exist in any manner on the device at all, which is why i got the failure in the OP. It tricked me! as I was in a hurry to pick my path and didn’t pay attention to the actual path the picker populated. So I updated the thread title, as Plex didn’t change it, I just didn’t pay attention to the modified path vs what I thought I picked.

My point is this:

  1. NFSv=4 is known. It’s a QNAP’ism
  2. I have never seen what you show here.
  3. If this is a QNAP thing, we can deal with it just like we dealt with CodexPack and the MultiMedia share.

So far, and please do correct me if I’m missing something, but this is confined to your use?

Yes, this Plex Server is only for my use.

I did a test on a TS-569L and it doesn’t show the additional folders in the picker like the TS-877 does. The only option for picking on the 569L is to use the “/share/CACHEDEV1_DATA/Movies”. The directory structure is however the exact same on both devices where “/share/Movies” works as well if you manually type it in (due to the QNAP symlinks).

Also,

[/] # ls -la /share

doesn’t show any hidden directories on the TS-877 either.

[/] # locate .user-share

Doesn’t show any files, symlinks, or paths using this name on the entire system which is indexed in mlocate.

As mentioned earlier, I’ve never seen that path show up on anything outside of Plex, but obviously it’s getting it from somewhere on the TS-877. Perhaps another service or something specific to the TS-877. I’d be curious if anyone else with TS-877 sees the same thing. Please let us know if you do!

-sker

I will let you know but until such time as I can find something , there’s nothing I can do.

If I can’t touch it, I can’t fix it.

Sorry

I would make this your very last priority until we see if anyone else sees this on their device. After looking more closely, this has turned into mostly just a heads-up FYI for other users searching if they see it.