mounts wrong/not available after update and reboot

  • I might need some help to get me out of this situation. At the moment I don't even know good search terms to google.


    But from the start:
    I recently set up a OMV-based NAS which worked for a few months now in a kind of extended beta phase quite flawlessly.
    But (apt) updates kept on coming and I for some reason never bothered to actually reboot the machine.


    Now I did and what I feared has happened: after rebooting nothing works anymore. (Of course I did several reboots during installations with no problems.)


    I'm using 2 4TB HDDs in an RAID10 configuration and a SSD as system drive + an USB stick as installation media.
    The HDD-Raid is encrypted with LUKS and then made available via LVM. (Both RAID configuration and LVM setup are overkill atm and were made in case I need to add more storage later.)
    Up until now there were 4 shared folders defined on that drive.


    The nginx of this NAS additionally serves a GitLab and a NextCloud installation. NextCloud adds one of the shared folders as 'external storage' to access media files.


    Now after reboot (and input of the LUKS password in the OMV webgui to unlock the encryption), Nextcloud reports the external storage as empty and with no access rights.
    The OMV webgui shows

    • disks: HDDs as /dev/sda & /dev/sdb, SSD as /dev/sdc
    • raid: /dev/md0 out of /dev/sda and /dev/sdb
    • encryption: /dev/mapper/md0-crypt made from /dev/md0 (unlocked: yes, referenced: no)
    • lvm:

      • physical /dev/dm-0 with Volume Group 'Data'
      • volume group 'Data' with physical volume /dev/wrapper/md0-crypt
      • logical volume 'data' from volume group 'Data'
    • file systems:

      • ext4 on /dev/dm-1 (mounted: yes, referenced: yes)
      • vfat on /dev/sdc1 (mounted: yes, referenced: no)
      • ext4 on /dev/sdc2 (mounted: yes, referenced: yes)
    • shared folders: 4 folders (e.g. 'Multimedia') on device 'data' (all referenced: yes)


    on the terminal, 'mount' says
    [...]
    /dev/sdc2 on / type ext4 (rw,noatime,nodiratime,errors=remount-ro)
    /dev/sdc1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
    /dev/mapper/Data-data on /srv/dev-disk-by-label-data type ext4 (rw,noexec,relatime,stripe=128,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)


    /etc/fstab reads:
    [...]
    UUID=533dfffd-ebd1-4be6-8e7b-55489f1ffece / ext4 noatime,nodiratime,errors=remount-ro 0 1
    UUID=EAFD-673A /boot/efi vfat umask=0077 0 1
    /dev/disk/by-label/data /srv/dev-disk-by-label-data ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2


    in /etc/systemd/system/ I can find a .mount file for each shared folder with contents like


    systemctl status sharedfolders-Multimedia.mount gives


    /sharedfolders/ contains only empty folder names.
    /srv/dev-disk-by-label-data/ contains the full data partition and is writable by root, but only readable by normal users.
    NextClouds external drive points to /sharedfolders/Multimedia, but has no data. Changing that to /srv/dev-disk-by-label-data/Multimedia makes the data re-appear, but no even the admin account has write permissions.


    I see a lot of inconsistencies in the naming in the omv config. The chain disk->raid->encryption->lvm physical->lvm volume group->lvm volume->shared folders does not have consistent input/output device names. Is the setup still ok? Is something wrong or unused?
    Why don't the shared folders mount? What is the 'dependency' that systemctl complains about? Is it run only at startup, when the RAID is not yet decrypted? How can it be re-tried once LUKS unlocks the drive?


    Where are access rights defined for those mounts?
    How much can I dismantle the whole configuration to re-build it without actually using data?


    Any help welcome!

  • systemctl start sharedfolders-Multimedia.mount will actually mount the folder, but it's still read-only
    in Nextcloud. Even if I mount it as a normal user and not root and even if I log into Nextcloud as Admin.



    Update: I've done chown root:users and chmod 775 to the shared folder (while it was mounted).
    At least after this, but possible all along (I didn't check) it seems only the top folder is read only, but all sub-folders within that share are now accessible from Nextcloud.


    Question remains: how to fix this so it's persistent across the next reboot?

  • I found the following logs



    Code
    Nov 01 18:51:03 Datenschleuder2 systemd[1]: dev-disk-by\x2dlabel-data.device: Job dev-disk-by\x2dlabel-data.device/start timed out.
    Nov 01 18:51:03 Datenschleuder2 systemd[1]: Timed out waiting for device dev-disk-by\x2dlabel-data.device.
    Nov 01 18:51:03 Datenschleuder2 systemd[1]: Dependency failed for File System Check on /dev/disk/by-label/data.
    Nov 01 18:51:03 Datenschleuder2 systemd[1]: Dependency failed for /srv/dev-disk-by-label-data.
    Nov 01 18:51:03 Datenschleuder2 systemd[1]: Dependency failed for Mount shared folder Multimedia to /sharedfolders/Multimedia.
    Nov 01 18:51:03 Datenschleuder2 systemd[1]: sharedfolders-Multimedia.mount: Job sharedfolders-Multimedia.mount/start failed with result 'dependency'.
    Nov 01 18:51:03 Datenschleuder2 systemd[1]: srv-dev\x2ddisk\x2dby\x2dlabel\x2ddata.mount: Job srv-dev\x2ddisk\x2dby\x2dlabel\x2ddata.mount/start failed with result 'dependency'.
    Nov 01 18:51:03 Datenschleuder2 systemd[1]: systemd-fsck@dev-disk-by\x2dlabel-data.service: Job systemd-fsck@dev-disk-by\x2dlabel-data.service/start failed with result 'dependency'.
    Nov 01 18:51:03 Datenschleuder2 systemd[1]: dev-disk-by\x2dlabel-data.device: Job dev-disk-by\x2dlabel-data.device/start failed with result 'timeout'.

    Which indicate that the automatic mounting of the shared folder fails because mounting of the data partition is configured as a dependency, but this one fails due to not being decrypted yet on boot. The whole mount chain is then not re-triggered on manual decryption later.


    There are bugs filed against the LUKS plugin dealing with similar matters which I commented on here. As those bugs are 2 years old and not fixed or even commented on, I don't have high hopes. I try to find a solution myself and will post it here for others to find.

  • Sadly, I found no solution even 4 months later. And even more sadly, I didn't even get one reply here.


    I'm trying to put all the re-mount commands into a script to help me after reboot.
    But I haven't found a fix for the access permission problems of the root folder of the shares.


    Can anybody tell me, on a normal, non-encrypted system, what are the permissions of the mount points, the top level shares and which user actually performs the mount on a normal system startup?


    Thanks

Jetzt mitmachen!

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