Probably 192.168.1.1 is your router/gateway I'm guessing. Use the IP for the pi??
I thought I would share some additional output firewall rules that will work for a stock install of OMV 3.X ... I believe. Generally you don't reject outgoing traffic but it's better to be paranoid.
I do not use SNMP or FTP on my network but from my understanding these should be covered under OUPUT ALLOWed to 192.168.0.0/24 (or whatever your private network range happens to be).
Any OMV/OMV-Extras.org plugins are not covered, and as a final note you MUST allow:
-port 25 TCP and UDP OUT, preferably constrained to either your relay server or just 0.0.0.0, for SMTP to work (mail)
-ports 80,443/TCP OUT to any IP as well as 53 TCP and UDP (DNS sometimes use TCP for IPv6 & DNSSEC) for apt to work (updates). 53 is necessary for resolving ip addresses from domains (DNS)
-port 123/UDP OUT to any IP for NTP... do not hardcode NTP service IPs, they are subject to change.
-port 5353/UDP OUT to any IP (maybe just subnet?) for Avahi/Zeroconf (I guess because it's broadcasting to nobody in particular?)
Those rules are all pictured, but I thought I'd point out if you miss them you'll have issues right off the bat.
Otherwise if you follow the picture below you should be able to REJECT all OUTPUT, again, on a stock install. If you have troubles or need help let me know. If you accidentally lock yourself out you an just get a tty session (you'll need to connect a screen to your NAS) and sudo iptables -F OUTPUT which should fix any issues you're having. Just be sure to go clear out the rules from the firewall in the web UI after flushing the iptables OUTPUT chain from tty.
You could try that, I would just as soon hook up a monitor to the box to see what's going on. You might see something informative, or might not. Sorry I couldn't be more help!
Seems silly but often times with a headless server I find there will be some kind of task running at boot that you can't see. How long have you actually waited before deciding the machine isn't booting? Or it legitimately doesn't boot up (LEDs, etc).
For reference if you want a static ip I believe the line should read iface wlan0 inet static, but like I said, I find it much simpler to configure all my boxes to use DHCP, and then issue leases from my DHCP server to maintain a "static" ip on the local network. In this way, if I need to make changes I don't have to ssh into each box individually, I can just make changes to the DHCP lease table.
I think that iface wlan0 inet manual is the option for allowing users to configure their own connection via GUI or command line. Hence why your Raspberry Pi didn't obtain an IP on the local network.
And don't be afraid to use the command line too! Often times it's as simple as googling "distribution name" + "issue you're having" + "cli" !
whats the content of /etc/network/interfaces...?
You would have to add wlan to the list of interfaces in the webui and set it to use DHCP, for what it's worth I believe it's easier to just issue a DHCP reservation on your router than to bother configuring a static ip on your nas
Basically: did you bother to configure wlan at all? You need wpa supplicant info etc. If I recall it's not difficult to set up via the command line.
What UPS do you have? A workaround is to just install their software for linux, usually it's not too difficult to configure via the command line.
I'd like to suggest to anyone running OMV on a raspberry pi for a home nas to use wifi instead of ethernet, as the wifi is on its own interface and therefore you should not have issues sharing bandwidth between the ethernet port and your storage.
Just in case this was non-obvious, I noticed many tutorials online say to connect the RPi via ethernet and really this is a pretty poor idea if you're intending to r/w alot of data from anything other than the root partition.
Don't you have to reboot to complete some updates? For instance kernel etc.?
As I know in other spaces there are commercial products people pay for to keep from having to reboot servers, I do believe it is necessary. It's also very dangerous as a a machine gets older and older- if you have a precious old server I guess the chances are greater that it won't survive a reboot. But that's probably older than most peoples NAS here.
See about kernelcare here.
So changing the cpu governor from conservative/ondemand to performance seems to have helped greatly. I didn't realize this cpu steps from 500mhz to the advertised 1.4ghz, making it essentially an RPI/3 with 3 less cores.
Hi, you need to create a shared folder in the 'Shared Folders page' and give access to your ftp user in the permissions.
Then, you will need to add this shared folder to your FTP shares in the 'FTP' page under services. You need to add shares for each service, ie. SMB/CIFS
did you check the owner of the share ? If you ssh into your omv box you can ls -la "/path/to/shared/folder" to see the chmod and user/group ownership.
Double check the permissions of your user, ensure the shared folder is not set to "read only" (you can lock everyone out from writing with this option, it's on shared folders page not the users page)
That's fair, but it's not the "proper" use per se of rc local.
Because it's basically an application, it would be better to write a systemd init script for such uses.
If he only starts the app on each multiuser runlevel (ie. rc local), if it failed for some reason he'd have to ssh into the box to restart it. For this reason alone it makes much more sense to write an init script.
It's not terribly difficult to write a simple init script-- the one linked in this thread however will probably not work without modification as it's looks like it is for calibre itself and not the homebrew app the original poster is using- though I could be mistaken.
From your link:
"rc.local is being deprecated"
Best not to rely on it then. In this case it's a bit of a kludge
Rc.local is deprecated in debian 9 no? Better to fool around with an init script.
when you install the omv iso, i believe postfix is installed and configured. You'd have to write some kind of script to download the attachments- for what it's worth this is a pretty awful idea from a security perspective.
Most of the time you will be discouraged from administrating your own email server by people who do such things for a living. It's much too easy to misconfigure postfix etc and leave a big gaping hole to exploit in your server.
I'm not sure how using FTP could overcome the attachment limitation...
The biggest issue is that if whatever email you're using this for gets out people can drop whatever they'd like onto your NAS. It's not tremendously likely but it would be my biggest concern. I usually set the firewall on my nas to drop any incoming connection outside of my local lan...
Just checking, you did install no-ip DUC on your RPi/1 correct?
I was curious to get some input, as I'm sure most of us here have sizeable media collections (think TV, movies, music).
I'm pretty obsessive-compulsive when it comes to "tagging"- all my MP3s have full ID3 info from musicbrainz etc., I use filebot: amc script or do by hand all my movies/TV etc and I always collect full albums, series, movie set, trilogy, whatever.
It really bugs me for things not to be tagged properly the way I like them.
So, I have an anthology of a particular producer on BBC, Adam Curtis, which contains pieces he's produced for the BBC spanning the last 30+ years. Many of the entries in the anthology would comprise a single episode in a series of short documentaries or opinion pieces presented by the BBC. The full series' either do not interest me or are far too obscure to bother finding.
So I'm curious to know how you'd organize these files. Normally I'd put them through filebot: amc or similar, but doing this will leave me with about a dozen superflous entries in my "tv shows" library which only contain a single episode.... My thought was to just place them all into a folder and create a playlist called "Adam Curtis Anthology" or similar.
However, I thought maybe there is another option I may have missed. How would you organize these files??
Thank in advance. My htpc is just an rpi/3 running libreelec.
I'm curious to know why bother to use DLNA instead of a read only nfs share or even smb/cifs?
if you are looking to reduce the complexity of your setup, omv might not be the best option as you seem to have some requirements above and beyond the functionality provided even by community supported addons. You'd find you'll need to get your hands pretty dirty to integrate any of these "above and beyond" requirements into the omv web ui unfortunately...
You could run omv in a vm as your nas solution and have a second vm for your gaming/"above and beyond" stuff, which while it should be easier than administrating that part of your setup through ssh you'll still have to learn a bit about omv to get things set up how you like.
Pretty sure OMV has a plex mediaserver plugin. So you're covered there.
I don't think "cloud accounts" are necessarily going to be easier to implement, if you're talking about accessing from the world wide web your NAS, you'll need to research installing OMV alongside something like owncloud or be stuck with FTP and some kind of dynamic dns solution. My cursory reading doesn't lead me to believe the first process (owncloud) is straightforward.
Best of luck in your research! Always an option to just install in a virtual machine and give it a spin, see if it'll work for you.