Files and or directories keep getting deleted from CENT OS file server [closed]
Clash Royale CLAN TAG#URR8PPP
Im using CENT OS 7 on a file server. On that file server, I have a directory that is used by an application at my company to store files. When that directory is deleted the application is not able to function properly. The issue is also very sporadic. It occurs once every 2-3 months. Could it be an issue with permissions? I have used 2 different permissions schemes and have listed them below. The first one was used and the directories were deleted twice. The second one was used but the directories have not been deleted as of yet, possibly indicating the issue is solved?
The following permissions were added:
chmod 750 /Bac/BacFileStore/directory
chmod -R 0777 /Bac/bacFileStore/directory
linux centos filesystems
closed as too broad by Jeff Schaller, RalfFriedl, Romeo Ninov, Rui F Ribeiro, Fabby Dec 18 at 0:23
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
Im using CENT OS 7 on a file server. On that file server, I have a directory that is used by an application at my company to store files. When that directory is deleted the application is not able to function properly. The issue is also very sporadic. It occurs once every 2-3 months. Could it be an issue with permissions? I have used 2 different permissions schemes and have listed them below. The first one was used and the directories were deleted twice. The second one was used but the directories have not been deleted as of yet, possibly indicating the issue is solved?
The following permissions were added:
chmod 750 /Bac/BacFileStore/directory
chmod -R 0777 /Bac/bacFileStore/directory
linux centos filesystems
closed as too broad by Jeff Schaller, RalfFriedl, Romeo Ninov, Rui F Ribeiro, Fabby Dec 18 at 0:23
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Perhaps you have a backup/archival process that operates on this directory?
– Haxiel
Dec 17 at 13:00
I'll check and see if there are any backup/archival processes. Thank you.
– Bach
Dec 17 at 13:48
So I have never actually viewed the archive files in a Linux machine before. I tried looking for the exact command, but I also realized I'm a bit unsure of where those files are located. Any idea? Thank you.
– Bach
Dec 17 at 14:39
1
That's a bit too broad, to be honest. You should check with your local system administrator. The process would usually involve a script or an external tool. Another server is also usually involved as the target data store.
– Haxiel
Dec 17 at 14:50
add a comment |
Im using CENT OS 7 on a file server. On that file server, I have a directory that is used by an application at my company to store files. When that directory is deleted the application is not able to function properly. The issue is also very sporadic. It occurs once every 2-3 months. Could it be an issue with permissions? I have used 2 different permissions schemes and have listed them below. The first one was used and the directories were deleted twice. The second one was used but the directories have not been deleted as of yet, possibly indicating the issue is solved?
The following permissions were added:
chmod 750 /Bac/BacFileStore/directory
chmod -R 0777 /Bac/bacFileStore/directory
linux centos filesystems
Im using CENT OS 7 on a file server. On that file server, I have a directory that is used by an application at my company to store files. When that directory is deleted the application is not able to function properly. The issue is also very sporadic. It occurs once every 2-3 months. Could it be an issue with permissions? I have used 2 different permissions schemes and have listed them below. The first one was used and the directories were deleted twice. The second one was used but the directories have not been deleted as of yet, possibly indicating the issue is solved?
The following permissions were added:
chmod 750 /Bac/BacFileStore/directory
chmod -R 0777 /Bac/bacFileStore/directory
linux centos filesystems
linux centos filesystems
edited Dec 17 at 22:01
Rui F Ribeiro
38.9k1479129
38.9k1479129
asked Dec 17 at 12:24
Bach
1
1
closed as too broad by Jeff Schaller, RalfFriedl, Romeo Ninov, Rui F Ribeiro, Fabby Dec 18 at 0:23
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as too broad by Jeff Schaller, RalfFriedl, Romeo Ninov, Rui F Ribeiro, Fabby Dec 18 at 0:23
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Perhaps you have a backup/archival process that operates on this directory?
– Haxiel
Dec 17 at 13:00
I'll check and see if there are any backup/archival processes. Thank you.
– Bach
Dec 17 at 13:48
So I have never actually viewed the archive files in a Linux machine before. I tried looking for the exact command, but I also realized I'm a bit unsure of where those files are located. Any idea? Thank you.
– Bach
Dec 17 at 14:39
1
That's a bit too broad, to be honest. You should check with your local system administrator. The process would usually involve a script or an external tool. Another server is also usually involved as the target data store.
– Haxiel
Dec 17 at 14:50
add a comment |
Perhaps you have a backup/archival process that operates on this directory?
– Haxiel
Dec 17 at 13:00
I'll check and see if there are any backup/archival processes. Thank you.
– Bach
Dec 17 at 13:48
So I have never actually viewed the archive files in a Linux machine before. I tried looking for the exact command, but I also realized I'm a bit unsure of where those files are located. Any idea? Thank you.
– Bach
Dec 17 at 14:39
1
That's a bit too broad, to be honest. You should check with your local system administrator. The process would usually involve a script or an external tool. Another server is also usually involved as the target data store.
– Haxiel
Dec 17 at 14:50
Perhaps you have a backup/archival process that operates on this directory?
– Haxiel
Dec 17 at 13:00
Perhaps you have a backup/archival process that operates on this directory?
– Haxiel
Dec 17 at 13:00
I'll check and see if there are any backup/archival processes. Thank you.
– Bach
Dec 17 at 13:48
I'll check and see if there are any backup/archival processes. Thank you.
– Bach
Dec 17 at 13:48
So I have never actually viewed the archive files in a Linux machine before. I tried looking for the exact command, but I also realized I'm a bit unsure of where those files are located. Any idea? Thank you.
– Bach
Dec 17 at 14:39
So I have never actually viewed the archive files in a Linux machine before. I tried looking for the exact command, but I also realized I'm a bit unsure of where those files are located. Any idea? Thank you.
– Bach
Dec 17 at 14:39
1
1
That's a bit too broad, to be honest. You should check with your local system administrator. The process would usually involve a script or an external tool. Another server is also usually involved as the target data store.
– Haxiel
Dec 17 at 14:50
That's a bit too broad, to be honest. You should check with your local system administrator. The process would usually involve a script or an external tool. Another server is also usually involved as the target data store.
– Haxiel
Dec 17 at 14:50
add a comment |
3 Answers
3
active
oldest
votes
Changing permissions on a directory will never be a cause of it getting deleted. Some program or person must delete it explicitly. So the answer to your question is "No", it's no issue with permissions.
Maybe some 'evil' person deleted the directory if it knew the password of the owner of the directory. Even worse: with your new permissions '0777' any person who has access to the file server can delete any file in the /Bac/bacFileStore/directory
directory. You should maybe not keep it like that. '750' or maybe '755' (latter if anyone shall be allowed to access the directory) would be a better choice.
Thank you for the tip! I'll definitely look into that.
– Bach
Dec 17 at 13:47
add a comment |
Centos has Gnu chmod
, so you can use symbolic mode. It is much easier to understand. chmod -R ugo-w /Bac/bacFileStore/directory
(remove write permission for user, group, and other).
Note that the owner and root (and any one with the appropriate capability), can change the mode, and remove.
Note that permission to remove a file, is permission to write to the containing directory (see also stick-bit, if multiple users can write to a directory).
Therefore it may be necessary to change the ownership and permissions, of the files, and the containing directory.
Detecting when files go missing
You can use inotify-wait
to detect when the files go missing. You will need to leave this running, it will wake-up when the files change.
add a comment |
Setting 777 permissions grants r/w to everyone who has access to your file server - including deletions. This may be how you want to set up your file server. However, having your application write here as well can be problematic. Is it simply writing files out to your file server or is there other work the app is doing here? If so, I would suggest you configure the application to use a directory not available to the file server.
If someone deletes a file in use by your application, you will have issues. Also, the file deleted that is in use by your app will not truly be deleted until the process is finished with that file.
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Changing permissions on a directory will never be a cause of it getting deleted. Some program or person must delete it explicitly. So the answer to your question is "No", it's no issue with permissions.
Maybe some 'evil' person deleted the directory if it knew the password of the owner of the directory. Even worse: with your new permissions '0777' any person who has access to the file server can delete any file in the /Bac/bacFileStore/directory
directory. You should maybe not keep it like that. '750' or maybe '755' (latter if anyone shall be allowed to access the directory) would be a better choice.
Thank you for the tip! I'll definitely look into that.
– Bach
Dec 17 at 13:47
add a comment |
Changing permissions on a directory will never be a cause of it getting deleted. Some program or person must delete it explicitly. So the answer to your question is "No", it's no issue with permissions.
Maybe some 'evil' person deleted the directory if it knew the password of the owner of the directory. Even worse: with your new permissions '0777' any person who has access to the file server can delete any file in the /Bac/bacFileStore/directory
directory. You should maybe not keep it like that. '750' or maybe '755' (latter if anyone shall be allowed to access the directory) would be a better choice.
Thank you for the tip! I'll definitely look into that.
– Bach
Dec 17 at 13:47
add a comment |
Changing permissions on a directory will never be a cause of it getting deleted. Some program or person must delete it explicitly. So the answer to your question is "No", it's no issue with permissions.
Maybe some 'evil' person deleted the directory if it knew the password of the owner of the directory. Even worse: with your new permissions '0777' any person who has access to the file server can delete any file in the /Bac/bacFileStore/directory
directory. You should maybe not keep it like that. '750' or maybe '755' (latter if anyone shall be allowed to access the directory) would be a better choice.
Changing permissions on a directory will never be a cause of it getting deleted. Some program or person must delete it explicitly. So the answer to your question is "No", it's no issue with permissions.
Maybe some 'evil' person deleted the directory if it knew the password of the owner of the directory. Even worse: with your new permissions '0777' any person who has access to the file server can delete any file in the /Bac/bacFileStore/directory
directory. You should maybe not keep it like that. '750' or maybe '755' (latter if anyone shall be allowed to access the directory) would be a better choice.
answered Dec 17 at 12:52
Jaleks
1,348422
1,348422
Thank you for the tip! I'll definitely look into that.
– Bach
Dec 17 at 13:47
add a comment |
Thank you for the tip! I'll definitely look into that.
– Bach
Dec 17 at 13:47
Thank you for the tip! I'll definitely look into that.
– Bach
Dec 17 at 13:47
Thank you for the tip! I'll definitely look into that.
– Bach
Dec 17 at 13:47
add a comment |
Centos has Gnu chmod
, so you can use symbolic mode. It is much easier to understand. chmod -R ugo-w /Bac/bacFileStore/directory
(remove write permission for user, group, and other).
Note that the owner and root (and any one with the appropriate capability), can change the mode, and remove.
Note that permission to remove a file, is permission to write to the containing directory (see also stick-bit, if multiple users can write to a directory).
Therefore it may be necessary to change the ownership and permissions, of the files, and the containing directory.
Detecting when files go missing
You can use inotify-wait
to detect when the files go missing. You will need to leave this running, it will wake-up when the files change.
add a comment |
Centos has Gnu chmod
, so you can use symbolic mode. It is much easier to understand. chmod -R ugo-w /Bac/bacFileStore/directory
(remove write permission for user, group, and other).
Note that the owner and root (and any one with the appropriate capability), can change the mode, and remove.
Note that permission to remove a file, is permission to write to the containing directory (see also stick-bit, if multiple users can write to a directory).
Therefore it may be necessary to change the ownership and permissions, of the files, and the containing directory.
Detecting when files go missing
You can use inotify-wait
to detect when the files go missing. You will need to leave this running, it will wake-up when the files change.
add a comment |
Centos has Gnu chmod
, so you can use symbolic mode. It is much easier to understand. chmod -R ugo-w /Bac/bacFileStore/directory
(remove write permission for user, group, and other).
Note that the owner and root (and any one with the appropriate capability), can change the mode, and remove.
Note that permission to remove a file, is permission to write to the containing directory (see also stick-bit, if multiple users can write to a directory).
Therefore it may be necessary to change the ownership and permissions, of the files, and the containing directory.
Detecting when files go missing
You can use inotify-wait
to detect when the files go missing. You will need to leave this running, it will wake-up when the files change.
Centos has Gnu chmod
, so you can use symbolic mode. It is much easier to understand. chmod -R ugo-w /Bac/bacFileStore/directory
(remove write permission for user, group, and other).
Note that the owner and root (and any one with the appropriate capability), can change the mode, and remove.
Note that permission to remove a file, is permission to write to the containing directory (see also stick-bit, if multiple users can write to a directory).
Therefore it may be necessary to change the ownership and permissions, of the files, and the containing directory.
Detecting when files go missing
You can use inotify-wait
to detect when the files go missing. You will need to leave this running, it will wake-up when the files change.
answered Dec 17 at 13:58
ctrl-alt-delor
10.8k41957
10.8k41957
add a comment |
add a comment |
Setting 777 permissions grants r/w to everyone who has access to your file server - including deletions. This may be how you want to set up your file server. However, having your application write here as well can be problematic. Is it simply writing files out to your file server or is there other work the app is doing here? If so, I would suggest you configure the application to use a directory not available to the file server.
If someone deletes a file in use by your application, you will have issues. Also, the file deleted that is in use by your app will not truly be deleted until the process is finished with that file.
add a comment |
Setting 777 permissions grants r/w to everyone who has access to your file server - including deletions. This may be how you want to set up your file server. However, having your application write here as well can be problematic. Is it simply writing files out to your file server or is there other work the app is doing here? If so, I would suggest you configure the application to use a directory not available to the file server.
If someone deletes a file in use by your application, you will have issues. Also, the file deleted that is in use by your app will not truly be deleted until the process is finished with that file.
add a comment |
Setting 777 permissions grants r/w to everyone who has access to your file server - including deletions. This may be how you want to set up your file server. However, having your application write here as well can be problematic. Is it simply writing files out to your file server or is there other work the app is doing here? If so, I would suggest you configure the application to use a directory not available to the file server.
If someone deletes a file in use by your application, you will have issues. Also, the file deleted that is in use by your app will not truly be deleted until the process is finished with that file.
Setting 777 permissions grants r/w to everyone who has access to your file server - including deletions. This may be how you want to set up your file server. However, having your application write here as well can be problematic. Is it simply writing files out to your file server or is there other work the app is doing here? If so, I would suggest you configure the application to use a directory not available to the file server.
If someone deletes a file in use by your application, you will have issues. Also, the file deleted that is in use by your app will not truly be deleted until the process is finished with that file.
answered Dec 17 at 14:33
Solomon
11
11
add a comment |
add a comment |
Perhaps you have a backup/archival process that operates on this directory?
– Haxiel
Dec 17 at 13:00
I'll check and see if there are any backup/archival processes. Thank you.
– Bach
Dec 17 at 13:48
So I have never actually viewed the archive files in a Linux machine before. I tried looking for the exact command, but I also realized I'm a bit unsure of where those files are located. Any idea? Thank you.
– Bach
Dec 17 at 14:39
1
That's a bit too broad, to be honest. You should check with your local system administrator. The process would usually involve a script or an external tool. Another server is also usually involved as the target data store.
– Haxiel
Dec 17 at 14:50