For me? …perfectly, thanks!
Now all I need is confirmation a Nvidia GPU card works.
We grabbed a build and made a formal run in the CI.
These packages are properly signed. The version number is slightly different than what was released to PlexPass. There are only minor changes.
Our goal is to verify everything is ok now and can continue the release process to make this official in 1.20.0 / 1.20.1 (most likely 1.20.1)
ARMv7 - Hardware Floating Point
https://artifacts.plex.tv/plex-media-server-experimental/1.20.0.3110-a4c56707d/qnap/PlexMediaServer-1.20.0.3110-a4c56707d-armv7hf_neon.qpkg
ARMv7 - Software Floating Point
https://artifacts.plex.tv/plex-media-server-experimental/1.20.0.3110-a4c56707d/qnap/PlexMediaServer-1.20.0.3110-a4c56707d-armv7sf.qpkg
To demonstrate how this works, which is now as I intended.
- The share is created when PMS is installed and when started.
- If you have no need of it, it is harmless (just like the Multimedia share)
- Should you wish to export it for SMB or to use it by any QTS user, you grant them access in the Shared Folder permissions.
- Until the user has access, “admin” is a user, the user does not see it.
- Once access is granted, FileStation immediately updates (to add or remove) to reflect the change.
A. No access by default
B. Grant access (add) the desired users.
C. Apply changes and observe the changes immediately visible.
The same holds true for SMB access.
Due to how QNAP impliements AFP and NFS, these two protocols will not work.
They do not resolve links server-side in the same way SMB does.
I did my best but I cannot effect that type change in QTS at this level.
1 Like
It worked!
My kit was:
- TS-453Bmini, QTS 4.4.3.1354
- MacOS, 10.15.6
- Access over SMB
My sequence was:
- Stopped PMS
1.20.3125 - Removed PlexData share
- Installed
1.20.3112(a lower number) - PlexData was recreated with no access.
- I gave myself access to PlexData
- I logged off/on my Mac
- Plex media Server was visible as a directory within PlexData
Note: It’s not a problem as I have changed to SMB (from AFP) as per your recommendation, but for info: Plex media Server was visible to me within the Plex share generated by PMSLibShare over AFP.
1 Like
The “Plex Media Server” will be visible over NFS as well as AFP.
The difficult is how links are resolved.
Neither AFP nor NFS resolve them server side.
I’ve asked QNAP about how this might be changed (if within the spec) and if possible
Hi there! I’ve followed all instructions, and updated to the latest version, and it’s messy as hell…the new version even installed the plex data without any issues, and the common error that could not access it. Now the problem I have is when I open the plex app, it does not find my server, or if I even try to use the qnapip:32400/web it’s says I do not have access to the server (No Soup for you)…
Can you confirm that you mean 1.20.0.3110 as per the links that @ChuckPa provided above (not the latest on the Plex website)?
all…first was the 1.19…, than tried the 1.20 version of the website and the latest the one @ChuckPa mentioned…
Good Morning. (if one can call it that) 
-
Defaulting to “No Access” of the PlexData share in FileStation or over LAN is by design. This does not impact Plex operation in any way. Plex still runs as user
rooton the QNAP just as it always has. -
Granting
admin, or other users, access to the share via Shared Folders is how it needs to work because of QNAP – and – because it is impossible for me to know what everyone’s site-specific usage is. -
Resolving “No Soup” or other problems.
To determine why “No Soup” exists here now,
- Grant File Station access in Shared Folders (this is the only extra step)
- Navigate in File Station into the PlexData share until “Logs” directory is seen,
- Right-Click and create “Logs.zip” or “Logs.tar.gz”,
- Download the logs via FileStation, and attach them in a post for examination.
thanks @ChuckPa Logs.zip (111.3 KB)
just to give some details why I say its a mess…
-
it started with the update to the version 1.19. After the update I could no longer access my content through my android box (on my local network), nor even on my android phone. (local network and external network);
-
At that time I still could see the server, also could test and see remote access was live.
-
Troubleshouting starts, I’ve restarted both QNAP NAS and PlexServer, updated the NAS firmware, Updated libraries…still same issue accessing content on external devices…
-
updated to version 1.20 from the website…still the same…uninstalled PlexServer …install again…still the same… removed my libraries, and added them again…still same issue…
-
removed libraries, server , uninstalled PlexServer for a clean install later…installed version 1.20 from the website…no soup error was born…
-
uninstalled 1.20 website version, installed 1.20 from Chuck…still no soup error…
Thanks
Just to report that I got this error to after the latest update:
Severity Level Date Time Users Source IP Application Category Content
Error 2020/07/28 19:15:14 System 127.0.0.1 --- --- ERROR: Could not create PlexData share. Further assistance is available in our Support Forums. Continuing without.
After this I am unable to access Plex server anymore completely…
Tried installing 1.20 from website, same thing…
EDIT:
Update again and then reboot solved the main issue and server is now running.
Error is still there whenever I start/stop server or reboot.
Tried removing share and rebooting and a couple of other things, but no luck there.
Btw. when I remove share it reappears all on itself.
I don’t fail installation if it can’t generate it – hence “Continuing without”.
The error only occurs when QTS itself is “sideways” -OR- attempting to install from NON-admin privileges.
QNAP / QTS is getting very touchy / picky with permissions for some reason.
Also , everyone needs to be aware of QSNATCH malware out there. It will cause the craziest of problems
PlexData has nothing to do with normal PMS operation.
By design, I create the share when startup is attempted by QPKG (which is ‘root’ and does have privilege to do so) if it does not exist.
Does this problem resolve IF:
- Stop Plex
- Remove the share
- Reboot the NAS
- Start Plex
As an alternative, install PMSLibShare
I use the exact same technique as Dane22 (co-author of the PlexData share) did in PMSLibShare.
The only difference is:
a. He creates a one-time static share definition to PMS
b. I now create a static share, named PlexData, which plex.sh looks for an utilizes to create the Plex Media Server link in . (He previously integrated that path into the share definition).
1 Like
You have a non-RFC 1918 address. You have a typing error.
plex-4.34.4-7d609a3.js is 3477363 (of total: 3477363).
Jul 28, 2020 11:54:10.608 [0x72311450] DEBUG - Completed: [192.169.1.248:51070] 200 GET /web/js/chunk-5-3ee08078895dfbdf0b07-plex-4.34.4-7d609a3.js (4 live) GZIP 120ms 998957 bytes (pipelined: 1)
Jul 28, 2020 11:54:10.750 [0x72311450] DEBUG - Completed: [192.169.1.248:51067] 200 GET /web/chunk-3-a6f6c5f066aa0f84a841-plex-4.34.4-7d609a3.css (4 live) GZIP 266ms 1017499 bytes (pipelined: 2)
Jul 28, 2020 11:54:11.072 [0x72311450] DEBUG - Completed: [192.169.1.248:51071] 200 GET /web/js/chunk-3-a6f6c5f066aa0f84a841-plex-4.34.4-7d609a3.js (4 live) GZIP 584ms 3477363 bytes (pipelined: 1)
Jul 28, 2020 11:54:11.568 [0x72311450] DEBUG - Request came in with unrecognized domain / IP '192.169.1.186' in header Host; treating as non-local
Jul 28, 2020 11:54:11.568 [0x72311450] DEBUG - Request came in with unrecognized domain / IP '192.169.1.186' in header Host; treating as non-local
Jul 28, 2020 11:54:11.569 [0x70659450] DEBUG - Request: [192.169.1.248:51071 (Subnet)] GET /web/common/img/backgrounds/preset-dark2.24cb7f1a5e2d0102f05f3e59dfad9086.png (4 live) GZIP
Jul 28, 2020 11:54:11.569 [0x70659450] DEBUG - Final path: "/share/CACHEDEV1_DATA/.qpkg/PlexMediaServer/Resources/Plug-ins-a4c56707d/WebClient.bundle/Contents/Resources/common/img/backgrounds/preset-dark2.24cb7f1a5e2d0102f05f3e59dfad9086.png"
You have 192.169.1.186
You need your LAN to be in the 192.168.x.x range.
DHCP server configuration error?
Hey @ChuckPa thanks. I will try. But it was working before. I did setup the LAN Range on my ASUS router 192.169.x.x, so it wouldn’t conflict with modem…But I can try setting the LAN again…Why do I need to be in 192.168?
thanks @dane22. But still do not understand how it was working before…
ARMv7 - Hardware Floating Point
https://artifacts.plex.tv/plex-media-server-experimental/1.20.0.3110-a4c56707d/qnap/PlexMediaServer-1.20.0.3110-a4c56707d-armv7hf_neon.qpkg
Resolved the problem for me.
TS-431P2
Thank you.
If it was claimed a long, as in very long time ago, then that would explain it, since PMS now req. what is known as Private Address Space during initial claim
So it’s clear as to why:
192.169.0.0 through 192.169.1.255 belongs to someone else.
192.169.x.x is “Publicly Routable”. You cannot use them inside your router and expect Plex to work.
[chuck@lizum netplan.518]$ whois 192.169.0.0
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2020, American Registry for Internet Numbers, Ltd.
#
NetRange: 192.169.0.0 - 192.169.1.255
CIDR: 192.169.0.0/23
NetName: PSG169
NetHandle: NET-192-169-0-0-1
Parent: NET192 (NET-192-0-0-0-0)
NetType: Direct Assignment
OriginAS:
Organization: RGnet, LLC (RGNETI-1)
RegDate: 2005-04-12
Updated: 2017-04-18
Ref: https://rdap.arin.net/registry/ip/192.169.0.0
OrgName: RGnet, LLC
OrgId: RGNETI-1
Address: 5147 Crystal Spring
City: Bainbridge Island
StateProv: WA
PostalCode: 98110
Country: US
RegDate: 1990-10-01
Updated: 2019-03-16
Ref: https://rdap.arin.net/registry/entity/RGNETI-1
OrgAbuseHandle: RB366-ARIN
OrgAbuseName: Bush, Randy
OrgAbusePhone: +1-206-780-0431
OrgAbuseEmail: randy@psg.com
OrgAbuseRef: https://rdap.arin.net/registry/entity/RB366-ARIN
OrgTechHandle: RB366-ARIN
OrgTechName: Bush, Randy
OrgTechPhone: +1-206-780-0431
OrgTechEmail: randy@psg.com
OrgTechRef: https://rdap.arin.net/registry/entity/RB366-ARIN
RTechHandle: RB366-ARIN
RTechName: Bush, Randy
RTechPhone: +1-206-780-0431
RTechEmail: randy@psg.com
RTechRef: https://rdap.arin.net/registry/entity/RB366-ARIN
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2020, American Registry for Internet Numbers, Ltd.
#
[chuck@lizum netplan.519]$
To all:
The minor tweaks I made to 1.20.0.3110 have been released to production and will be part of all QNAP releases.
While there might be some systems which still have problems, they will be the exception and any errors will be indicative of extreme configurations or other QTS problems.
1 Like
