Hello George,

i've replayed your situation on my Test-Windows running in a VM, and here my results : 

- if you run your Ubooquity-Server under a(ny?) Windows-OS, you have to re-declare/re-set all your share-settings (comics,ebooks and RAW-Files) after activating/deactivate the security setting - all my share-settings before are lost.

After re-set the share(s), you have to re-scan your libraries - once again ..  

- if you directly edit the JSON-File, be sure to declare the UNC-Path-Settings correct appending to Java-Language: 

a Backslash under Windows must be doubled in order to read it correctly under JAVA - for example  

   - under WIN "\\Server\Dir" is in Java "\\\\Server\\Dir"

And again, after re-set your share-settings in the JSON-File, you have to re-scan your libraries - once again again ..  

After altering my settings according yours, i can confirm a running Ubooquity-Server with UNC-Paths and different User-Permissions, but be shure to set the "Do not remove data from unreachable folders" after your first scan with your new security settings - otherwise next time re-scanning your DB an your UNC-Share isnt responding/running you may lost your entire db...(and you have to re-scan your libraries - once again again again .. )

Functional "adding UNC-Paths withhin a dialog window" under Java isnt so easy to put it like a rabbtit from the hat - i've try to developed it a long time ago in Java and give it up, because UNC-Shares on Win-OS sometimes likes to irrationally act/respond according to JAVA (what cames historically from SUN/UNIX) ..  

Hi Matthieu,

the "lack of settings migration" refreshes sometimes "lost memories" on IT basics :-) 

my comic servers runs 1 day with this "side effect", but running it without any working 

differential security rules keep my mind restless - here with me are some younger 

user/reader who should not read my aduld horror comics like "Echoes "or "From Hell"...

Hi Daniel, 

if you set any user security permissions in ubooquity , be sure to set the comic/book path settings without any symlinks -

for example : 

wrong  -  /share/download (it's a symlink generatet by qnap itself)

correct:   /share/CACHEDEV_01/download (this is the "absolute" path on my system, your's may differ, and the above path is the symlink target)

I'vo got the same "problem/bug" on my TS453mini as you, but after changing the path settings to absolute paths & 

rescan the entire database (incl deleting the "old/wrong" informations before the new scan!) all works fine  ..

in my humble opinion the java runtime cannot use or do his job false on symlinks, but using absolute paths is basically safer..

best regards from munich !

TierparkToni