Posts by BernH

most of the folder are owned by root as you can see. if you are not logged in as root, you will not see anything.

additionally all data drives in omv are mounte underthe srv directory, with each filesystem mounted as subdirectory. That is where you need to look for your data, not the root filesystem like your picture.

here is an example of the 3 filesystems on my server:

root@nas:/srv# ls -la
total 20
drwxr-xr-x  8 Bern users 4096 Apr 24 20:52 .
drwxr-xr-x 24 root root  4096 Aug 11 21:29 ..
drwxr-sr-x  5 root users   85 Aug 14 05:30 dev-disk-by-uuid-0e13d684-5e3e-41e0-a4fa-d1be722413dd
drwxr-sr-x 15 root root   308 Aug 14 03:58 dev-disk-by-uuid-4d26adbd-029a-4d74-a81f-c69bf193a099
drwxr-sr-x 11 root root   137 Jan  3  2026 dev-disk-by-uuid-d69073e2-e8f5-4605-aaa2-eb2c662b20b4
drwxr-xr-x  3 root root  4096 Aug  6 20:55 pillar
drwxrwxrwx  2 root root  4096 Dec 29  2023 remotemount
drwxr-xr-x  6 root root  4096 Aug  6 20:55 salt

each one if the dev-disk-by-uuid entries is a different filesystems that is used for different purposes.

Your data will be in these, so you need to cd into them and recheck the ls -la and directory contents to see if the data is actually there. The path to these are the same as the ones you picked in the shared folder section of the omv UI

no worries. we all have to start somewhere.

ACLs are ok when implemented correctly to restrict access to nested directories under a single share, but it is very easy to make a configuration change that will behave completely different than you expect. Standard linux permissions can produce the same type of restriction by uusing nested shares.

For example, if you have have something like this:

- Root Directory

|-- Sub-directory 1

|-- Sub-sirectory 2

ACL can be set to have one share for the Root director and then restrictions set so the person logging in either can or can't see it and/or the sub-directories.

You could have it set that you as the admin has R/W access to each shared folder, but the other shared folders can be changed per user.

With a standard permissions approach, instead of a single share and login, point, you create a shared folser and samba share for each directory and set the basic R/W permission for each share and used combination. This is done without stepping into the ACL page of the shareed folder screen

The difference in operations is really that the restricted user will not be able to access a folder that have been set as no access without entering an additional login instead of it just not being visible. I use this configuration all the time as it is much easier to configure and maintain. ACL is visually simple because there is one share, but much more difficult to get configured right.

ACL can be more secure because there is no additional login prompt, but for the vast majority of NAS configurations this is not really a big issue.

This is worth a read as a quick point form of the pros and cons.

Thread

Read this before using ACLs!

While Access Control Lists (ACLs) can be useful in certain scenarios, there are also reasons why you might choose not to use them in openmediavault (OMV). Here are some considerations:

1. Simplicity:
   • Using traditional Unix permissions (chmod and chown) is simpler and may be sufficient for many use cases. If your file and folder access requirements can be adequately managed with basic permissions, introducing ACLs might add unnecessary complexity.
2. Compatibility:
   • Some applications or services may not

…

ryecoaaron

Jan 5th 2024

what is the filesystem?

are there actually files there? look on omv, not accessing it from another system. (once again ls -la)

If files are actually there when looking on the server then there is no recovery needed.

are you using ACLs? if using ACL's it is very easy to mess up permissions by adding an often un-needed layer of complexity.

Is there a reason you are using LVM? it adds another layer of complexity that that is often not needed.

Quote from pegasuspc

did they change something because it has worked before

I am wondering if it is something with jellyfin because emby has no issues at all, Not sure

---

did they change something because it has worked before

I am wondering if it is something with jellyfin because emby has no issues at all, Not sure

Thread

Why you should not use non-linux filesystems, such as ntfs, exfat, fat32, hfs+, apfs, etc.

I have become tired of constantly writing this information in replies on the forum, so I am hoping that this can serve as an easily findable rationale in the guides section of the forum. Perhaps the moderators can even pin it to the top of the list so it does not get lost as people submit how to guides.

Filesystems that are not linux native are problematic and always will be if you use them as permanent data drives. This basically means that any filesystem that you can not create in the omv…

BernH

Mar 3rd 2026

Quote from ryecoaaron

Arcane still suffers from the same major problem portainer does - it is a docker container meaning it won't do anything for you if docker is having problems.

Agreed there. I just prefer the UI more and was only throwing it out there as another option for those that may feel the same. I'm not trying to fight about it and don't want to re-hash the conversations that you and I have already had about it.

Your mounts are not correct.

Docker mounts are structured like this:

    volumes:
      - /path/on/host/filesystem:/path/inside/container

You are missing the :/path/inside/container side of the mount.

The structure allows the container to overlay the host filesystem to a directory inside the container so the application can access the files.

Quote from ChargerHarry

Hello,

thank you for the info.

How probable is it that a mountet smb-folder is not available?

What is the command to check it and what is the command to repair it (so that omv also can work with the remote mount)?

Many thanks in advance for your assistance.

Best regards

Hartmut

Display More

A mounted share can disappear for several reasons, such as a reboot of the remote system, a mount attempt before the remote system is up and sharing, a network glitch, a samba update, a bad ethernet cable, etc. All of these can happen more than you would think.

As for a command to check the mount, I usually place a dotted file on the remote filesystem like .filesystem-available and write a little routine in the script that checks for the file, mounts if the file is not visible and then runs a command. You will have to design the script to your needs of course, but here is a sample that I just got gemini to write that you can use as a conceptual starting point.

#!/bin/bash

# --- CONFIGURATION ---
# Local and remote directory paths
LOCAL_SRC="/path/to/local/source/"
MOUNT_POINT="/mnt/remotesamba"
REMOTE_DEST="${MOUNT_POINT}/destination_dir/"

# Samba connection details
SMB_SHARE="//server-ip-or-host/sharename"
SMB_USER="your_username"
SMB_PASS="your_password"

# The anchor file used to confirm the share is truly mounted and accessible
ANCHOR_FILE="${MOUNT_POINT}/.mount_anchor"

# --- STEP 1: CHECK ANCHOR FILE & MOUNT IF MISSING ---
if [ ! -f "$ANCHOR_FILE" ]; then
    echo "Anchor file not found. Attempting to mount Samba share..."
    
    # Ensure the mount point directory exists
    mkdir -p "$MOUNT_POINT"
    
    # Mount the Samba share using cifs
    sudo mount -t cifs "$SMB_SHARE" "$MOUNT_POINT" -o username="$SMB_USER",password="$SMB_PASS",uid=$(id -u),gid=$(id -g)
    
    # Re-verify the anchor file after attempting to mount
    if [ ! -f "$ANCHOR_FILE" ]; then
        echo "Error: Failed to mount Samba share or anchor file is still missing." >&2
        exit 1
    fi
    echo "Samba share mounted successfully."
else
    echo "Samba share is already mounted and accessible."
fi

# --- STEP 2: RUN RSYNC TRANSFER ---
echo "Starting rsync file transfer..."

# Flags: -a (archive), -v (verbose), -h (human-readable), --progress (show progress)
# Note: Samba filesystems (NTFS/FAT) may not support Linux permissions properly.
# We use --modify-window=1 to ignore minor timestamp shifts common to Samba/Windows shares.
rsync -avh --progress --modify-window=1 "$LOCAL_SRC" "$REMOTE_DEST"

# Check if rsync completed successfully
if [ $? -eq 0 ]; then
    echo "Backup completed successfully!"
else
    echo "Error: Rsync transfer failed." >&2
    exit 1
fi

There is a bit of an issue if you are trying to write directly to a samba mount or rsync to it. Linux mounts drives and shares in directories on the os drive. If that mount gets dropped. The backup or rsync will still still write to the directory, but it will not be the remote share.

The best way to tackle that is to use a script that will check to see if the remote mount is valid and mount it if it isn't before running the backup or rsync. Personally, I would save the backup locally and then rsync it to the remote mounted share. This way you are not relying on one machine to be able to get at the backup.

You can create this script and save it on the system then run it via the scheduled jobs plugin or as a potentially more user friendly option use the scripts plugin.

Are the drives connected directly to the motherboard, a card, or some kind of external enclosure?

I have no experience with jfs. It is generally considered a legacy filesystem that is rarely used anymore.

Look in the syslogs to see if there are any unmount/mount errors around the times it happens.

It sounds like your filesystem is perhaps unmounting and re-mounting read only.

What are you using for storage and how is it formatted/configured?

what does ls -la reveal from terminal/cli?

Check the shared folder privileges (not the samba share settings).

I recently updated an omv system I was using for timemachine along with several macs that were using it.

When the macs updated past sonoma, timemachine broke. The fix for me was this:

Timemachine fix:

Remove timemachine disk from the mac configuration

delete existing backups from the shared directory on OMV

remove the serverMarkers.plist from the mac using terminal

sudo rm /private/var/root/Library/Group\ Containers/group.com.apple.NetworkAuthorization.ServerMarkers/serverMarkers.plist

re-add disk to the mac

I recently upgraded another system that was sending the hated daily MD email. The post I made above that reassembles the RAID witht he new version of MD did not fix the issue. as it was not the root cause in this case.

A little further digging resulted in this fix that seems to have done it for this system.

This fix when taken literally as outlined below, assumes that there is only one RAID on the system and it is md0. You may have to change the md number to match your system.

Step-by-Step Fix:

Open the 99-openmediavault-md-raid.rules file in nano (or your terminal text editor of choice):

sudo nano /etc/udev/rules.d/99-openmediavault-md-raid.rules

Change the second block to include , SYMLINK+="md/md0" at the very end.

Look at the bottom area that has no # comments at the start of the lines, your edited file should look like this, with that , SYMLINK+="md/md0" added on the last line:

ACTION=="add|change", \
  SUBSYSTEM=="block", KERNEL=="md*", TEST=="md/stripe_cache_size", \
  ENV{OMV_MD_STRIPE_CACHE_SIZE}="8192"


ACTION=="add|change", \
  SUBSYSTEM=="block", KERNEL=="md*", TEST=="md/stripe_cache_size", \
  IMPORT{program}="import_env /etc/default/openmediavault", \
  ATTR{md/stripe_cache_size}="$env{OMV_MD_STRIPE_CACHE_SIZE}", SYMLINK+="md/md0"

Save and exit the editor (Ctrl+O, Enter, then Ctrl+X).

Force the system to apply the new rule immediately:

sudo udevadm control --reload-rules && sudo udevadm trigger

I know this was was posted early in this thread, but I wanted to repost it with a little more of a step by step instruction for those that are not too comfortable editing files, along with the command to reload the rules without a reboot. This also shows that there appears to be 2 potential issues that were causing these md error notifications. The raid re-assembly I encountered on one system and the udev rules on this one.

I use watchtower as well. I do like that it cleans up right after the update instead of waiting for a scheduled prune.

I will throw out another option as well. The docker container Arcane is a docker manager that does the same job as the compose plugin, giving a ui for docker management, but it has the ability to set per container automatic update options and scheduled pruning.

I personally like it's layout better than the compose plugin without adding the complexity of portainer (which I used to use), but I prefer watchtower for the automatic updates. Arcane does not have the rather good backup functions of the compose plugin, but I have custom backup scripts that I designed before the compose plugin existed, so I don't really miss the backup functions of the compose plugin.

Adding #BACKUP to docker bind mounts is expected behavior.

Have a look at the documentation

omv8:omv8_plugins:docker_compose [omv-extras.org]

Quote from giaguaro

Yes I know but I have more fun with the oldest hardware 😊

I love re-purposing older stuff too. One I get enough old stuff gathered to put together a system, I will often cobble something together and give it to someone that is in need. Usually it is a desktop system for someone that doesn't have one, but it can also be an omv nas made from desktop hardware for someone that may already have a laptop or cheap desktop, but has nowhere to safely store their personal files that is not "in the cloud"

I'd rather do that with old hardware that still has life left in it than send it to e-waste recycling.

Quote from Grayfox

How are the movies named

To add to this point too, if the files were named on a Mac, it is very likely that they have illegal character or leading/trailing spaces that will cause problems.

mac will let you use any character in a name, but every other OS has a bunch on characters that are not allowed because they have special meaning to the OS, and a Mac also allows for leading and trailing spaces which will keep the files from being detected correctly.

Rule of thumb... avoid characters that are not letters or numbers and avoid leading or trailing spaces.

Quote from Stephan-P

Issue self resolved, BUT...

Is it alright for NPM to fall over like this if one of its Proxy Host forwarding addresses is unavailable?

I noticed similar behavior recently with NPM. I don't recall it happening with older versions, but I may be wrong and was just lucky enough to not have an active host defined that was not actually available, or it may indeed be a behavior change.

Since it was a fairly easy fix, I dodn't go looking through the NPM github issues to see if it has been reported.

Quote from omvbonn

The fault seems to be

# mdadm --assemble /dev/md/0 /dev/sd[abc]

instead of

# mdadm --assemble /dev/md/md0 /dev/sd[abc]

in my case, because the device was named /dev/md/md0 previously.

Display More

yep, you can't change the original structure. The re-assemble, export, and salt lines create correct entries for the new mdadm config and re-write the mdadm config files with the correct entries for the new version of mdadm. My RAID was created on an older omv install and moved to a new install when I went from V5 to V6. mdadm starts numbering up from 0 when you are creating a new RAID and counts down from 127 when you are mounting a pre-existing one. Thats why I stated "or whatever your RAID is identified as" in step 1