New Samba Shares cannot be accessed from Android/Zidoo media server

1. offizieller Beitrag

    Hello,


    I setup OMV samba shares with OMV3 or 4 and upgraded to OMV5. In OMV5 I added two new smb shares in OMV. In the meanwhile, I'm on OMV 6.


    The smb shares were accessible with OMV3 / 4 with my Zidoo Z9X android media player. The strange thing is, since upgrading to OMV 5, I can access the already configured smb shares with my Zidoo, but I cannot add the new and I cannot newly add one of the earlier existing smb shares. The message is always, that the server is unavailable.


    With e.g. Kodi or directly from Windows, using "\\my-server" in Windows Explorer or in the Network Devices section of the Windows Explorer, I can still access them.


    The problem is, I don't see any logs. The only info I could find is, that Windows 10 seems to use SMB3_11, but the Zidoo seems to use the SMB2_02.



    I now followed again the instructions here https://wiki.omv-extras.org/do…etting_up_a_shared_folder and the following chapter, but that's, what I already have.


    Is there any possibility to activate the smb logs on OMV? So I see, if the Zidoo can at least contact the server and is rejected? I didn't find any log files on the Zidoo side.


    Thanks and kind regards,


    FeBo

    • Offizieller Beitrag

    That is solved by downgrading the version of samba. You can do it on the line for custom samba share options.

    I don't remember the exact command, you'll have to look it up on the forum or on google.

    Keep in mind that if you downgrade the version you are also lowering your security.

    Hello chente,


    thanks a lot! I'll look it up in the forum to hopefully find the exact command and the version I have to downgrade to. Stupid question: Is there a possibility to make this work with a newer version again in the future or will this always be the work around?


    Lowering security is hopefully not such a big issue, since I only have holiday videos on the shares and they are only accessile from the LAN.


    Thanks and kind regars!

    • Offizieller Beitrag
    Zitat von FeBo2

    Is there a possibility to make this work with a newer version again in the future or will this always be the work around?

    This depends on what your client accepts, in this case Zidoo Z9X.

    If it is an old device and it no longer receives firmware updates it will continue to use old software.

    Zitat von macom

    Try



    Code
    ntlm auth = yes
client min protocol = SMB2


    in the extra options of smb

    I added it and it looks like this:

    Is this correct? Sadly it didn't work. :(

    Zitat von chente

    This depends on what your client accepts, in this case Zidoo Z9X.

    If it is an old device and it no longer receives firmware updates it will continue to use old software.

    Thanks a lot. I still gets firmware updates, so I'm looking forward that it will work again in the future. ;)

    • Offizieller Beitrag
    Zitat von FeBo2

    Sadly it didn't work.

    Maybe an older version will work.

    client min protocol = SMB1

    Thanks to both of you. What I tested after I read the topic mentioned above was


    Code
    server min protocol=NT1

    It didn't work. But when you say the right syntax is

    Code
    min protocol = NT1

    I'll try this tomorrow. Otherwise I'll try to find out which version Zidoo Z9X exactly has and which conditions the service has to fulfill, Zidoo shall connect to. At least the manufacturer should be able to answer this.


    Thanks and kind regards!

    FeBo2 I'm puzzled because the screenshot in your first post appears to show Zidoo Z9X connecting to some SMB/CIFS shares on OMV6 using SMB2. If so, why would changing protocols in the share configs make a difference to shares you cannot connect to from Zidoo? You've not said what if any error messages show up on the Zidoo for failed connections, e.g. access denied, permission denied .


    I'd concentrate on comparing the overall config of shares you can connect to those you cannot on OMV, ie compare shared folder permissions, any privileges, other share settings like share type - guests allowed or name/passwrd needed - etc. On the Zidoo itself I can only guess to connect to a share you'd need "server ip" , "share name" and either "guest" or a "user name" and user password" and that would be saved for later selection when making a connection. So worth double checking everything connection related is correct on the Zidoo itself.


    If you know how to use the terminal on OMV, you could use this command "testparm -s" as root which shows the share configs and post the output here.

    Thanks a lot for your response.


    Zitat von Krisbee

    I'm puzzled because the screenshot in your first post appears to show Zidoo Z9X connecting to some SMB/CIFS shares on OMV6 using SMB2.

    You are absolutely right. Therefore I wrote

    Zitat von FeBo2

    The strange thing is, since upgrading to OMV 5, I can access the already configured smb shares with my Zidoo, but I cannot add the new and I cannot newly add one of the earlier existing smb shares. The message is always, that the server is unavailable.

    Perhaps it's not clear enough: I create let's say 6 smb shares in OMV 3, that were auto-detected by Zidoo and everything worked as expected. Then I upgraded OMV to OMV 6. Since I needed a new hard disk, I added two new shares on the new hard disk created in OMV 6. Since I was not sure which settings to use I oriented on the existing shares.


    When I tried to connect from Zidoo to the new Shares, I scanned on Zidoo side for SMB shares, but none were found, so I added the IP of my OMV server manually, also access credentials (same as for the old shares) for the new shares and got the message "Server couldn't be reached". In Zidoo I then opened one of the already connected old shares and they were reachable, listed the content of the shares, played videos.


    I tried again and again and again with the new shares and compared their configs against the old shares. I also allowed guests to connect to them, so I could ensure I didn't enter a wrong password or some other errors. Nevertheless, it didn't work. Next I got the idea "when the new shares are not recognized (neither automatically, nor manually) I try to connect to an already connected SMB share again. So I typed in the information and got the same error "Server couldn't be reached". I hope, it is clearer now. The old shares can be accessed from Zidoo with already setup connections, but not with new one.

    Zitat von Krisbee

    If so, why would changing protocols in the share configs make a difference to shares you cannot connect to from Zidoo? You've not said what if any error messages show up on the Zidoo for failed connections, e.g. access denied, permission denied .

    Except the message I told you I couldn't see one, but I also mainly searched for the problem on OMV side. I had the feeling, that new shares are now created in another way then old ones or perhaps old ones get some kind of flag "created with SMB 1 or 2". Something like that, so that OMV allows still established connections, but new one only with e.g. SMB 3. It's only guessing, as I don't see any logs on OMV side, that tell me: Did the try to login reach OMV at all? If so, for which reason it wasn't able, etc.

    Zitat von Krisbee

    I'd concentrate on comparing the overall config of shares you can connect to those you cannot on OMV, ie compare shared folder permissions, any privileges, other share settings like share type - guests allowed or name/passwrd needed - etc. On the Zidoo itself I can only guess to connect to a share you'd need "server ip" , "share name" and either "guest" or a "user name" and user password" and that would be saved for later selection when making a connection. So worth double checking everything connection related is correct on the Zidoo itself.


    If you know how to use the terminal on OMV, you could use this command "testparm -s" as root which shows the share configs and post the output here.

    From my point of view I compared all the shares multiple times and set the permissions trialwise to "guests allowed", as written above, to prevent username/password misspelling, e.g. But that didn't work.


    Currently I'm at work, but at home I run the command testparm -s from the Shell (or if it doesn't work I check, if there's a separate terminal as part of OMV - I'll see) and post the results here.


    Thanks and kind regards!

    • Offizieller Beitrag

    These problems only occur with the Zidoo client? Is this behavior repeated in other clients?

    Thanks for your responses.


    The testparam -s command output the following (I only add the general part, Videos 2 - smb share that works on Zidoo, and Videos 3 and 4 which both don't work):


    Videos 3 has guest access granted and therefore no "valid users = KODI @KODI", except that, all three are equal?! No clue what the general section says, if there are any misconfigurations.

    Zitat von chente

    These problems only occur with the Zidoo client? Is this behavior repeated in other clients?

    Right. I additionally tested KODI on a Raspberry Pi with LibreElec (that's, why the user is named KODI, even if it works on the Zidoo MediaCenter) and Windows in Windows Explorer. Both work without any problems.


    I found a way to generate logs recommended by Zidoo support in the Z9X, but therefore I have to install an android app. Installing it works, but I don't find it on the Zidoo to start logging. I have to continue searching and let you know, as soon as I see any logs there.


    Thanks, kind regards and enjoy your weekend!

    FeBo2 The share that works is using the old "disk-by-label" style path. I would check/compare the permissions on the "path" of each share. Why are both "inherit acls" & "inherit permissions" options in use on your shares. Are you actually using access control list on your shared folders?

    Thanks for your response.

    Zitat von Krisbee

    The share that works is using the old "disk-by-label" style path. I would check/compare the permissions on the "path" of each share. Why are both "inherit acls" & "inherit permissions" options in use on your shares. Are you actually using access control list on your shared folders?

    I compared the permissions from the srv folder to the final folders containing the videos and they look the same for the uuid-... folder name and the disk-by-label folders.


    The content of the srv folder:


    The content of the srv/dev-disk-by-uuid-b263...d31 folder


    The content of the srv/dev-disk-by-uuid-b263...d31/videos folder (permissions are mixed a little, but that's also the case in the other shared video folders.


    I checked the inerit permissions and acls checkboxes, because I wanted new folders in the shared folders to get the same permissions, as their parent folder. I'm not using any access control lists. The only access control is, that currently only the KODI user is allowed to access the shares with password. Should I uncheck both checkboxes?


    Thanks and kind regards!

    • Offizieller Beitrag

    Okay. So this looks like a permissions issue.


    If you don't have nested shared folders.


    This is the ideal situation. Follow these steps:


    1.Reset all the permissions of your folders. For that you can use openmediavault-resetperms. Here's a guide. [How-to] Use the openmediavault-resetperms plugin Repeat the operation for each of your shared folders. Make sure to select the Administrator - read/write, Users - read/write, Others - read-only option. If you have questions, ask here.


    2.Once this is done, check the permissions of your users in the shared folders, make sure that each user has read permission (or the one that interests you) in each shared folder. In the GUI go to Storage>Shared Folders> Select a shared folder. Click on the Privileges button. and choose the permissions for each user. DO NOT use ACL permissions, you do not need them (DO NOT use the Access control list button).


    3.Then go to Services>Samba> and check the configuration of each share. Select a share. Click the Edit button. By default, only the Browsable and Hide files button should be active dot."." If you have any more make sure it doesn't interfere. And just in case, look at the Extra options line, it should be empty but maybe at some point you added something (remove the samba version settings we said before)


    Now check if the files are accessible from zidoo. If it still doesn't work, it's not a permissions issue.


    If you have nested folders.


    In this case the configuration is more difficult, not impossible, but you probably need ACL permissions. If you need to do this for some reason, follow the omv-extras permissions guide https://wiki.omv-extras.org/do…misc_docs:nas_permissions

    I can't help you with that because configuring that from a chat seems difficult to me. My advice though is still not to nest shared folders with samba unless you really know what you're doing and really need to.


    ____________________________________________________________________________________


    Side note: As a general idea, permissions are more restrictive on each layer. The first layer is at the file (or folder) level. The second layer is at the user level. The third layer is at the service level (samba in this case).


    As much as we try to give permissions to a resource in samba (third layer), if the file level permissions are restricted samba will not be able to do anything with it.

    Thanks a lot! At first, I cannot test it right now, since my nieces and nephews are here for a visit. I'll do this tomorrow, when it's quiet again and I can concentrate.


    Only one question how to determine nested and not nested folders:

    My structure is e.g.

    srv/dev-disk-by-uuid-b263...d31/videos -> videos is a shared folder

    srv/dev-disk-by-uuid-b263...d31/photos -> photos is a shared folder

    srv/dev-disk-by-uuid-b263...d31/cutting -> cutting is a shared folder

    srv/dev-disk-by-uuid-b263...d31/raw_data -> raw_data is a shared folder


    Are they nested, because one drive has multiple shared folders or are they not nested, because one shared folder doesn't contain another shared folder.

    Is a nested share

    srv/dev-disk-by-uuid-b263...d31/videos -> is a shared folder

    srv/dev-disk-by-uuid-b263...d31/videos/video_trip_to_egypt -> video_trip_to_egypt is a shared folder

    ?


    Thanks and kind regards!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden